- Inkscape Devel - Inkscape Mailman

Spray tool shorcut
by Nicolas Dufour 11 Jun '10

11 Jun '10

Hi all, All tools are bound to key shortcuts, except one: the spray tool. "s" is already used by the selector, and thus I suggest that we use "a' (airbrush) or, if we want to use a F key, Shift+F3, Shift+F5 or Shift+F8 (the only free Shift+F keys). What do you think? Regards, -- Nicolas

1 0

Re: [Inkscape-devel] gnome or X test framework
by Vangelis Katsikaros 11 Jun '10

11 Jun '10

William Swanson wrote: > On Thu, Jun 10, 2010 at 12:27 AM, Vangelis Katsikaros > <vkatsikaros@...1244...> wrote: >> For example I could write a script: >> when program opens click this menu, click this button, drag that object, >> press these keyboard keys, roll the mouse wheel etc. > > This tool seems similar to what you are describing: > > http://groups.csail.mit.edu/uid/sikuli/ yep it is exactly that :) A friend suggested this too some hours ago, and I 've playing with it all this time. It does work as advertised and it's excellent for testing. I've been able to make inkscape run and do several GUI driven things. Drawbacks: - not so portable (a theme change can render it unusable not to mention switching OS). - when putting inkscape under pressure, careful timing must be used to make sure the simulation performs what you want and when you want. __________________________________________________ ×ñçóéìïðïéåßôå Yahoo!; ÂáñåèÞêáôå ôá åíï÷ëçôéêÜ ìçíýìáôá (spam); Ôï Yahoo! Mail äéáèÝôåé ôçí êáëýôåñç äõíáôÞ ðñïóôáóßá êáôÜ ôùí åíï÷ëçôéêþí ìçíõìÜôùí http://mail.yahoo.gr

2 2

gnome or X test framework
by Vangelis Katsikaros 11 Jun '10

11 Jun '10

Hello I would like to ask if there is a gnome or X testing suite that could either in a controlled or monkey/fuzzy way, simulate user actions on a GTK or X in general program. For example I could write a script: when program opens click this menu, click this button, drag that object, press these keyboard keys, roll the mouse wheel etc. I want to use it to reproduce some test cases several times and then compare some profiling data. Of course, the same thing could have been used for bug hunting and regression testing, so since I haven't seen anything like that used around, I am not positive that sth like that exists. I have searched around for this, but couldn't find something (maybe I am using the wrong keywords...) except Squish for KDE (which I haven't used or know its current status). Regards Vangelis __________________________________________________ ×ñçóéìïðïéåßôå Yahoo!; ÂáñåèÞêáôå ôá åíï÷ëçôéêÜ ìçíýìáôá (spam); Ôï Yahoo! Mail äéáèÝôåé ôçí êáëýôåñç äõíáôÞ ðñïóôáóßá êáôÜ ôùí åíï÷ëçôéêþí ìçíõìÜôùí http://mail.yahoo.gr

2 3

Normal/preview screen mode!
by Jmx 09 Jun '10

09 Jun '10

In Indesign you have two screen modes: 1. Normal with objects visible outside the document borders. 2. Preview mode where you only see things inside the document borders. It's often very nice to be able to switch between those modes when designing. Anyone know if something like that is planned in the future? Have a great day =) -- View this message in context: http://old.nabble.com/Normal-preview-screen-mode%21-tp28733051p28733051.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 2

Changing font family, and -inkscape-font-specification
by Chris Lilley 09 Jun '10

09 Jun '10

Hello, I came across this in a file that someone sent me. It was generated by Inkscape 0.47 r22583. The font-family property is set on a text element, while child tspan elements have -inkscape-font-specification set to the full font name, but the font-family has not been set even though it has changed. Inkscape should have written font-family: Bitstream Charter. SVG viewers are therefore (correctly) not applying Bitstream Charter, in this example. And the content creator thinks that SVG viewers have 'font issues' as they don't display what was designed. Is this a known bug? SVG snippet: <text xml:space="preserve" style="font-size:40px;font-style:normal;font-weight:normal;text-align:center;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans" x="437" y="202" id="text3695"><tspan sodipodi:role="line" id="tspan3697" x="437" y="202" style="font-size:28px;font-weight:bold;-inkscape-font-specification:Bitstream Charter Bold">Semantic</tspan><tspan sodipodi:role="line" x="437" y="237" id="tspan3699" style="font-size:28px;font-weight:bold;-inkscape-font-specification:Bitstream Charter Bold">Web</tspan><tspan sodipodi:role="line" x="437" y="272" id="tspan3701" style="font-size:28px;font-weight:bold;-inkscape-font-specification:Bitstream Charter Bold">Technologies</tspan></text> -- Chris Lilley mailto:chris@...157... Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG

2 1

SVG Vector Effects in Inkscape
by Ivan Louette 09 Jun '10

09 Jun '10

Was anyone at this Chris Lilley's talk last year at SVG Open ? http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.h… Should be of course implemented in Inkscape ! It could also render obsolete some BoolOps LPE while beeing perhaps much lighter. ivan

6 10

Screenshots 0.48
by unknown＠example.com 09 Jun '10

09 Jun '10

Hi all, Don't we have any screenshots of 0.48? http://inkscape.org/screenshots/index.php?lang=en I forgot where to add screenshots... Ciao, Johan

2 1

Feature & String Freezes
by Joshua A. Andler 08 Jun '10

08 Jun '10

Hey all, Just wanted to let everyone know that Feature & String Freezes are now in effect. Only behind by a day right now, so that's pretty good. :) Translators please do your magic with the confidence that we won't be changing strings. :) Cheers, Josh

1 0

Re: [Inkscape-devel] New anti aliasing techniques for 2d rendering
by Michal Suchanek 08 Jun '10

08 Jun '10

On 5 June 2010 18:06, Juan Vuletich <juan@...2357...> wrote: > Hi Michal, > > Michal Suchanek wrote: >> >> On 3 June 2010 18:45, Juan Vuletich <juan@...2357...> wrote: >> >> >>> >>> Ok. Did it. Take a look at >>> http://www.jvuletich.org/Morphic3/tigerWholePixel.png . I think it is >>> closer to the subpixel rendered version than to Inkscape. >>> >>> But I did something else. I opened the web page on several displays. >>> Tried it in 3 LCD screens, with both DVI and VGA interfaces, and at >>> native resolution and at lower resolution. In all cases the subpixel >>> rendered version shows less pixellation and less color artifacts. Then I >>> tried on 2 15" CRT screens, one Trinitron and the other regular, at >>> 1024x768 and at 800x600. The whole pixel version looks consistently >>> better than the Inkscape rendering, although both show some colored >>> shadows that are due to the misalignment between logical pixels, the >>> display's color mask and the actual colored phosphor on the screen. The >>> subpixel version looks less pixellated and also with a slight colored >>> shadow, but in different places. Overall, I find the subpixel version to >>> also look better in these 2 CRT displays! Finally, I tried on an OLPC >>> XO, both in color and b/w modes. There, all alternatives look equally >>> good and it is hard to declare a winner. >>> >>> So I say that given that the majority of displays sold and in use are >>> RGB LCDs, given that it makes sense to obtain the highest possible >>> quality from the best and most used displays, and given that the >>> subpixel version looks better even in CRTs and doesn't hurt in the XO; >>> it is advisable to use the subpixel version on any display, at least as >>> a default. >>> >> >> I beg to differ. >> >> I use a rotated screen and the subpixel rendered images look odd and >> the color shadows make examining the images quite hard on the eyes, >> even more than the pixelation present in the Inkscape images. This is >> the reason I don't use subpixel rendering. No sftware I know can do >> vertical subpixel rendering or even switch the subpixel direction as >> the window is moved to a different screen or the screen is rotated >> differently. >> >> Thanks >> >> Michal > > I see you answered just to me, so I'll do the same. Anyway, it is ok for me > to have any of these discussions in public, as others might have things to > say... Sorry, I meant to reply to the list and as the list does not provide reply-to headers and my mail client is not capable of processing list headers the message went only to you. > > I see your points, they are valid issues. However, to me, avoiding subpixel > rendering is perfectly ok as a personal choice to live with an unfortunate > state of affairs, but there are better options for thechnology to evolve. I > mean: > > - WRT rotated screens and nonstandard subpixel geometries, ideally the > software should be able to query the hardware, do adjust the rendering as > appropriate. My code can do vertical subpixel, as well as adapt to BGR or > OLPC XO with just a few parameter tweaks. Yes, that would be nice option to have. Actually the geometry is known (for most LCDs it is RGB) and the direction can be determined by examining xrandr and window position. It's just not done, and cannot be done for prerendered images. > > - WRT to examining the images, I guess new tools are needed. The image zoom > software considers images as made of pixel as having the R, G and B I intentionally did not use zooming for the comparison, only displayed the page as-is on two screens, one with the expected RGB direction and one rotated. The reason for crude zooming in bitmap viewers is speed I guess, few people want to wait tens of seconds for their image to show in the viewer. Also without additional information you cannot know how the image was rendered and how it should be scaled or resampled for different subpixel positions and different resolutions. > components on the same point. My claim is that this is not true. Thinking > about it like digital audio, we have "the real thing", a continuous image > not made of pixels, and sampled as appropriate for the current target > device. So the idea of images made of rgb pixels is dead. And for examining > and editing images, no music producer works with individual samples, > although in the > old times all of them did work cutting and gluing magnetic tape. The same Working with pixels directly makes sense for very small low resolution images which are more akin to ASCII-art than actual pictures. As the resolution of display devices increases and images are getting more realistic the need for such low-level manipulation decreases as well. Still the low-res images strike back in the form of font glyphs and icons for pocket devices. Actually there is real a problem of converting fonts from vector outlines to some bitmap form which can be used for simple drawing operations (in this particular case for use in a bootloader which should not be concerned with rendering vector graphics). The current method freetype uses fails miserably for conversion to b&w (not grayscale) bitmaps but maybe there is no way how that can be done reasonably. Grayscale is the next thing on the list of things to try but I have not seen the results yet. If your software can render some CJK/Indic/whatever TrueType/OpenType/whatever font glyphs that would be another thing where good antialiasing could be useful. Rendering of Latin or such is also of use but there drawing all the bitmaps by hand is less of an issue and many bitmap fonts already exist. Thanks Michal

3 7

gsoc blogs
by Alexandre Prokoudine 07 Jun '10

07 Jun '10

Hi, There is a tradition to add blogs of "graphics" GSoC students to graphicsplanet.org every year. If your students blog on their projects, please let me know URLs/RSSs and I'll add them. Thanks, Alexandre Prokoudine http://libregraphicsworld.org

1 0