February 2008 - Inkscape Devel

Filter General Settings
by Alexandre Prokoudine 21 Feb '08

21 Feb '08

Hi, "Filter General Settings" now allows setting "coordinates" and "dimensions". However, it's not quite clear what the unit again is. Percents? Should we probably make those less cryptic by adding help messages popping up on hovering mouse above widgets? P.S. Are we adding such help messages to filter primitive options? Alexandre

2 2

Security report that requires attention
by john cliff 21 Feb '08

21 Feb '08

Hi Guys, Thought this needed bringing to peoples attention. http://www.inkscapeforum.com/viewtopic.php?f=22&t=594 Cheers Sim

3 2

Problems with translations - N_() and Q_()
by Marcin Floryan 20 Feb '08

20 Feb '08

Hi! I wanted to bring your attention to some internationalization issues I came across when fixing various bugs. I hope some clarification can be made so that we can avoid further problems. 1.) Using the N_ macro The N_ macro is used to mark strings as being translatable but does not translate them. It has to be used when strings can't be directly translated (most common in the string array initializers). So whenever N_ is added in the code - it needs another call to _() later in the code to actually perform the translation. There have been some circumstances before where this second call was missing and I will try and track if there are any more. Please note that I don't think the N_ macro cannot be simply substituted with, say Q_ (vide: rev. 17415 and panel.cpp) 2.) Using the Q_ macro I have a feeling there is some slight misconception of how this macro is supposed to work. The idea is that the original string is turned into "prefix|string" to make it unique and a call to _() is replaced with a call to Q_(). The Q_() macro itself will call _() (ie. gettext()). The Q_macro will also make sure, that where no translation is available the prefix will be strip from the untranslated text. Please note the attached patch for illustration where this would work OK but an extra call to _() can be avoided. Please correct me if I'm wrong. Hope this helps. Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]

1 1

Missing files
by Ted Gould 20 Feb '08

20 Feb '08

Hey all, These files are in the source tree but not part of the distribution. I'll delete them unless someone objects (they'll still be in the SVN history) src/extension/internal/bitmap/convolve.cpp src/live_effects/lpe-skeleton.cpp src/ui/dialog/session-player.cpp src/ui/dialog/whiteboard-connect.cpp src/ui/dialog/whiteboard-sharewithchat.cpp src/ui/dialog/whiteboard-sharewithuser.cpp --Ted

5 4

Patch to issue warning when attempting to set or get a non-existent preference
by Tom Davidson 20 Feb '08

20 Feb '08

Hi all, Currently when you try to access the value of a preference setting within Inkscape, no warning is issued if the requested preference doesn't exist. Instead, a default value provided by the caller is returned. This can cause bugs if there is a typo in the preference name, or if the pref is not created properly in src/preferences-skeleton.h. The latter problem caused the 'oversample bitmaps' preference to be broken for at least 2 releases (0.44 and 0.45) (bug 167824 and bug 168346). I wrote a patch to issue a warning when the requested preference doesn't exist, and found that this 'silent failure' behavior is actually used in a few places to allow debugging parameters to be passed in by manually adding items to your preferences.xml file. I saw warnings for 'options.filtertest', 'options.bulia', and 'debug.icons', but there may be more in code paths that I just haven't passed through yet. I can see 3 ways to address this usage while adding the new warning. I have implemented #3 in the attached patch. 1) Deprecate/disallow the use of the preferences file for passing in arbitrary debugging parameters. pro: "clean" con: would remove useful functionality; hard to systematically find all the debugging pref names 2) Introduce a flag in the preferences get/set functions that suppresses the warning. pros: debugging usage would be explicit; no changes to current prefs names con: would have to rewrite all callers 3) Do not issue a warning for prefs that begin with "debug.", and move existing debug prefs to this namespace (options.filtertest becomes debug.filtertest, etc.) pro: captures the developer's intent to use the pref for debugging, without having to rewrite function calls as in #2 con: developers who currently use these flags would have to manually change their preferences.xml files I chose to implement the warning in inkscape_get_repr in src/inkscape.cpp, rather than in the helper functions in src/prefs-utils.cpp, in order to avoid duplication. This may be a bit late for 0.46? Since it's just adding a warning, it seems like a low risk patch, but I don't have SVN access in any case, so will defer to the wisdom of the list... Thoughts/suggestions welcome: I'm new to this! -Tom

3 2

More z-order operations
by Rob Antonishen 20 Feb '08

20 Feb '08

Hi- I have been playing with more z-order operations. I wrote the restack extension I posted about a while back, and have been adding features... first arbitrary angle reordering, then radial reorderring, and most recently, I have (in my version) added some more basic z-order functions, such as reverse the selected objects z-order, randomize the z-orders, and shift (rotate?) the z-orders. All these options are making the single extension UI an ugly mess, as many of them have options that only apply to some of the choices. I am thinking of breaking it into three separate extensions. What is the policy for providing extensions like this? Currently I have it under Effects->Modify Path... but don't like that as it is really doesn't modify the paths, just changes the z-order. It seems more like the Object->Raise, Lower, Top, Bottom functions (though it always moves them to the top after adjusting the z-order). I am considering registering these as Object->Change Z-order->*** and having XX separate extensions (or can I have XX menu entries in one extension?) Right now I have: 1: Orthagonal (pick comparison point and 1 of 4 directions) 2: Arbitrary Angle (comparison point and angle slider) 3: Radial (comparison point and direction option-outward or inward) 4: Random (no options) 5: Reverse (no options) 6: Shift (+/- slider either in actual numbers or % of objects in the selection) Are there guidelines for how to best to do this? Thanks, -Rob A>

3 4

Release Announcement edits by Brian Forte
by Andy Fitzsimon 20 Feb '08

20 Feb '08

Andy, Below is a copy-edit of my original PR re-write. I've corrected a couple of typos (blame them on the lateness of the writing hour last night) and added your 'what 3D Box' does sentence. I haven't tried to re-write the Tweak Tool or Live Path Effects paragraphs, however. I still think they need re-writing, but I don't know enough about the tools to do the re-write blind. If someone wants to throw some hard data up about what the tools do, I'd be happy to go over said data with an editorial eye. Hope this is at least diverting, if not useful. Regards, Brian. -- tech writer: <http://apac.redhat.com/> columnist: <http://www.redhatmagazine.com/category/documentation/> mobile: +61 (0)439 721 274 email: <mailto:bforte@...43...> ___________________________________________________________________ The Inkscape Community Releases Inkscape 0.46 New York, NY yyyy/mm/dd — The Inkscape community today announced the release of Inkscape 0.46, the newest stable version of their multi-platform, open-source vector graphics editor. This newest Inkscape release includes a plethora of new tools and improvements, beginning with native PDF support. Developed with the assistance of the 2007 Google Summer of Code, and utilising the open source Cairo and Poppler libraries, Inkscape 0.46 provides an easy, open source tool for editing and creating PDF documents. The 2007 Google Summer of Code also produced the new 3D Box tool, the Tweak tool and Live Path Effects. As its name suggests, the 3D Box tool makes it possible to create and edit the perspective of three-dimensional boxes. The Tweak Tool [something other than market speak here: what exactly is the Tweak Tool and what does it do?]. Live Path Effects can be used to create "brushes" and organic effects while keeping the original paths editable. [This needs to be more concrete as well.] As well, gradient editing is now done visually and on-canvas. Gradient stops are depicted as nodes, and multiple nodes can be selected and moved simultaneously. Colour management has also been improved, with initial support for colour spaces other than sRGB, including Adobe RGB and calibrated CMYK. This makes it possible to use calibrated colour values, including CMYK values, that are preserved across applications. The new Paint Bucket Tool allows bounded areas to be filled with colour at the click of a mouse button. This new tool creates a closed-path based on the visible canvas and is useful for quickly colouring line drawings. The Gaussian Blue filter, introduced in Inkscape 0.45, was the first SVG Filter. Inkscape 0.46 expands on this with Offset, Blend, Diffuse Lighting, Specular Lighting and Turbulence primitives. There is also a new, dedicated user interface for creating and altering filters based on these new primitives. Finally, Inkscape 0.46 introduces workflow and user interface improvements. Dialogue boxes can now be docked and minimised to a side-panel, reducing visual clutter and making the relationship between documents and interaction choices clearer, especially when working on multiple documents in separate Inkscape instances. With 0.46 out, the Inkscape community is already working on future releases, including the upcoming 0.47. Full compatibility with SVG Mobile/Tiny is slated for version 0.50 and version 1.0 will include complete W3C SVG 1.1 compliance. Inkscape users have contributed many features and ideas to the project and the community invites anyone to contribute to the project. The more help Inkscape gets, the sooner we reach these goals.

2 1

Bounding box calculation
by Pierre-Luc Auclair 19 Feb '08

19 Feb '08

Hi, It would be really nice if Inkscape would take into account the cap-end style of lines when doing bounding box calculations. Right now, it makes it *impossible* to have a 1px line both on the pixel grid on display and on the pixel grid when exporting the object when butt-cap cap style is applied. Now I have to create invisible objects to export these lines, and it's really tedious and a serious time-waster. You can't also simply set the Y coordinates (if vertical, X if horizontal) through the main toolbar because it results in misaligned pixels. It's a major PITA for me and I'm sure it is for others, it would really require a fix soon. Thanks, Pierre-Luc

1 0

Release 0.46pre2
by Ted Gould 19 Feb '08

19 Feb '08

Hello all, I've put together another tarball, which unfortunately took longer than expected. If anyone has some spare time, run "make check" and see how many of those they can get to pass :) Here's the download page: https://sourceforge.net/project/showfiles.php?group_id=93438&package_id=991… MD5 Sums: b08fd4821c9f44fdab1b2d7ca4e9531d inkscape-0.45+0.46pre2.tar.bz2 e8ed5d6737058f689763f3d36adc1a87 inkscape-0.45+0.46pre2.tar.bz2.sig cd6b7a74d99e109d07eca31a36bea918 inkscape-0.45+0.46pre2.tar.gz 74cb640225bebbaaf47183cddd026f0a inkscape-0.45+0.46pre2.tar.gz.sig ba21e89b796451d62548f19aae8e0f45 inkscape-0.45+0.46pre2.zip a57b8e435d23d0619467cb3d3defb228 inkscape-0.45+0.46pre2.zip.sig --Ted

1 0

Optimized path data
by Jasper van de Gronde 19 Feb '08

19 Feb '08

I just submitted a patch (id: 1896251) to the patch tracker that changes Inkscape::SVG::PathString to generate the shortest possible path string with decent spacing (that is, it uses the same spacing rules as the old PathString). It does this by eliminating repeated operators when it can, as well as using relative coordinates if it helps. Using this patch I got file size reductions of about 10% on car.svg(z), the new about screen and some of my own files (I looked at both the uncompressed and the compressed svg's). To do this I opened the files, selected all objects and performed a translation of 0px on them, then saved the file (as uncompressed svg, and then again as compressed svg). The optimized path strings are about just as readable as the old ones (sometimes they're even easier to read). I would welcome any suggestions/comments.

2 4