- Inkscape Devel - Inkscape Mailman

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

About shapes with translucent borders
by Juan Vuletich 06 Jun '10

06 Jun '10

Hi Folks, Inkscape and other SVG renderes draw shapes by drawing first the fill, and then drawing the border on top. As Ivan noted recently (in ""), at http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.h… and http://www.w3.org/TR/SVGTiny12/render.html#PaintingShapesAndText , it is clear that the standard requests to do that. I didn't know that, and took the time to render this svg: http://www.jvuletich.org/Morphic3/rects.svg like this: http://www.jvuletich.org/Morphic3/rectsInM3.png . It is a bit more complicated, but I feel it is better. What do you think? Should I simplify my code and just draw one over the other? Or should the standard be changed, and Inkscape and other renderers do what I did? Thanks, Juan Vuletich

4 7

Feature Freeze
by Joshua A. Andler 05 Jun '10

05 Jun '10

Hi all, We're ready to move into Feature Freeze. No further feature work is permitted at this point. Any remaining tasks regarding documentation needs to be wrapped up ASAP, as we will be moving to string freeze soon. Feature Freeze entails: No further development work. Disable features that aren't finished Post additional inkscape-0.48-pre*.tar.gz releases Focus on critical bug fixing. Finalize all tutorials, docs, etc. Finalize all extensions Finalize about screen Translators create translations. Inkscape must pass 'make distcheck' Establish the Stable Branch for release Disable features that won't be turned on in the release Post inkscape-0.48-beta.tar.gz ----- Here's a tentative release schedule (please, lets try to stick to this): Today (6/1) is Feature Freeze Monday (6/7) will be String Freeze Monday (6/21) will be Hard Freeze Monday (6/28) will be Release ----- To stick to this we need to address the following. @Felipe: It appears that either your device-cmyk work needs to get disabled at this time, which was suggested by Jon in the previous thread. Will you be able to address this soon? Please let us know. Bug 542346 @Jon: Please get the "UX" selector in that toolbar sorted ASAP. Are the "Auto" swatches initially editable in the F&S dialog yet? If not, it's looking like they'll need to be disabled again for this release. @Johan: I see you think you've fixed the LPE issue that bulia reported, thank you! @Tavmjong: Awesome work on the Text Tool! Is there anything else that is a "must" to get in/fixed? If so, is it looking feasible to get done in time with your schedule? Also, it appears that bug 583593 is assigned to you, any progress? If there are any other issues that have been overlooked please let me know. Thanks to everyone for all of your hard work! Cheers, Josh

5 7