June 2010 - Inkscape Devel - Inkscape Mailman

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

Emergency save could need testing
by Jasper van de Gronde 05 Jun '10

05 Jun '10

I took the liberty of fixing a bug that would cause pretty much any autosave of a document that has already been saved before to fail: https://bugs.launchpad.net/inkscape/+bug/283769 I have tested with multiple files, new documents, existing documents and existing documents which were the result of an emergency save. Given that the release is slowly nearing I would love at least some confirmation that it also works on Linux(/Mac), as I've only tested on Windows. The attached file demonstrates some changes I used to add a Crash menu item to the file menu, as I didn't know of any other way to make Inkscape crash fast and reliably :) Also, if anyone can give the code a quick review that would be great as well (see revision #9470 and/or inkscape.cpp in trunk). (To ensure that I'm not abusing Document::base for example.) === modified file 'src/menus-skeleton.h' --- src/menus-skeleton.h 2010-04-11 08:51:39 +0000 +++ src/menus-skeleton.h 2010-06-02 12:18:02 +0000 @@ -18,6 +18,7 @@ " <verb verb-id=\"FileNew\" />\n" " <template-list/>\n" " </submenu>\n" +" <verb verb-id=\"FileCrash\" />\n" " <verb verb-id=\"FileOpen\" />\n" " <recent-file-list/>\n" " <verb verb-id=\"FileRevert\" />\n" === modified file 'src/verbs.cpp' --- src/verbs.cpp 2010-04-11 08:51:39 +0000 +++ src/verbs.cpp 2010-06-02 09:23:40 +0000 @@ -768,6 +768,12 @@ g_assert(parent != NULL); switch (reinterpret_cast<std::size_t>(data)) { + case SP_VERB_FILE_CRASH: + { + void (*func)() = 0; + func(); + } + break; case SP_VERB_FILE_NEW: sp_file_new_default(); break; @@ -2192,6 +2198,7 @@ new Verb(SP_VERB_NONE, "None", N_("None"), N_("Does nothing"), NULL), /* File */ + new FileVerb(SP_VERB_FILE_CRASH, "FileCrash", "Crash", "Crash", NULL ), new FileVerb(SP_VERB_FILE_NEW, "FileNew", N_("Default"), N_("Create new document from the default template"), GTK_STOCK_NEW ), new FileVerb(SP_VERB_FILE_OPEN, "FileOpen", N_("_Open..."), === modified file 'src/verbs.h' --- src/verbs.h 2010-04-11 08:51:39 +0000 +++ src/verbs.h 2010-06-02 09:24:18 +0000 @@ -33,6 +33,7 @@ SP_VERB_INVALID, /**< A dummy verb to represent doing something wrong. */ SP_VERB_NONE, /**< A dummy verb to represent not having a verb. */ /* File */ + SP_VERB_FILE_CRASH, SP_VERB_FILE_NEW, /**< A new file in a new window. */ SP_VERB_FILE_OPEN, /**< Open a file. */ SP_VERB_FILE_REVERT, /**< Revert this file to its original state. */

5 9

Gradient with beziercurves....
by Axel Richter 04 Jun '10

04 Jun '10

Hi Devs, i think, the gradientool are great and useful, but this could be more advanced. Nice function are the points on the gradientline, but the line should be handle in the second mode like a curve or bezier. every point should the graident tagential to the line or curve. the other option could be possible to convert the bezier-tool into a gradienttool. please all devs help me or take me the way to great this funktion. i like inkscape and i think this is the number one of vector-tools.

3 2

FW: SVG Open 2010 conference - Last Call for anInkscape contribution
by unknown＠example.com 04 Jun '10

04 Jun '10

Hi all, I think the mail below on the user maillist is more suited for the devel maillist :-) Ciao, Johan > -----Original Message----- > From: Andreas Neumann [mailto:a.neumann@...1944...] > Sent: Friday, June 04, 2010 07:02 > To: Inkscape User Community > Subject: [Inkscape-user] SVG Open 2010 conference - Last Call > for anInkscape contribution > > Hi all, > > As every year we are organizing the SVG Open conference > (http://www.svgopen.org/2010/). This year it takes place from > August 30 to September 1 in Paris. Inkscape was always > present in the past couple of years through presentations of > Jon Cruz, one time also a keynote. His contribution was > always one of the highlights of the conference. > Inkscape is the most powerful SVG editor we have at hand. It > would be very nice if the Inkscape project would be > represented at the conference. I am sure there are plenty > interesting aspects in Inkscape that would be worth being > presented at the conference. > > If you live close by and have time and interest in presenting > Inkscape, both from a developer, but also from a > designer/user point of view, you are still welcome to submit > a short abstract until June 9. The official abstract > submission deadline is over, but we are still accepting late > interesting submissions. If you are interested, please submit > an abstract at > https://www.svgopen.org/2010/registration.shtml (you first > have to preregister) or ask me questions, if any. > > I would hope that the Inkscape project could be present at > the conference. > > Thanks, > Andreas

1 0

mingw, freebsd cross build patches
by Jan Nieuwenhuizen 03 Jun '10

03 Jun '10

Hi, Last year I added Inkscape to our GUB cross build tool so that it creates installers for windows and some Linux/FreeBSD flavours. Inspired by the grand LGM event, today I've updated the patches to latest trunk, for mingw: inkscape-mingw.patch inkscape-wstring.patch for freebsd: inkscape-isfinite.patch inkscape-round-2.patch inkscape-wstring.patch In order to enable cross building, you also need to fix the hard setting of the PKG_CONFIG variable in configure.ac, the GUB builds scripts now have self.file_sub ([('AC_PATH_PROG\(PKG_CONFIG,', 'AC_PATH_PROG(ARE_YOU_FREAKING_MAD__OVERRIDING_PKG_CONFIG,')], '%(srcdir)s/configure.ac') as PKG_CONFIG is set to something like 'PKG_CONFIG': '''pkg-config \ --define-variable prefix=%(system_prefix)s \ --define-variable includedir=%(system_prefix)s/include \ --define-variable libdir=%(system_prefix)s/lib \ ''', Greetings, Jan. -- Jan Nieuwenhuizen <janneke@...570...> | GNU LilyPond http://lilypond.org Freelance IT http://JoyOfSource.com | Avatar® http://AvatarAcademy.nl

1 0