November 2011 - Inkscape Devel

Cleaning up Inkscape's SVG output.
by Tavmjong Bah 30 Nov '11

30 Nov '11

Hi, I have just checked into trunk some of the fruits of Abhishek's GSOC project to improve Inkscape's SVG output. Abhishek wrote the core routines to which I added a variety of utility functions. This code can result in cleaner and smaller SVG. It does the following things: For a given element (<rect>, <path>, etc.) it checks: 1. That all attributes are valid.[1] 2. That properties are appropriate.[2] 3. That properties are useful.[3] What Inkscape does when it finds a problem is controlled by settings under the "SVG output" section of the Inkscape Preferences dialog. For each of the above cases, you can independently: 1. Print out warnings to the console (if running Inkscape from the command line). 2. Delete the invalid or not useful items. In the dialog, you can choose when Inkscape should test the SVG: 1. When reading files. (If this option is enabled at start-up, files Inkscape uses internally like icons.svg will also be checked.) 2. When editing files. (Mostly useful for debugging Inkscape.) 3. When writing files. This code has been test on a variety of SVG files but it will need much broader testing. The default preferences are set to do nothing so as to avoid the risk of damaging files. Please take your favorite SVG files and compare the visual output when the "Remove" and "Writing" boxes are checked in the Inkscape Preferences dialog. Also, compiling the code under Windows and OSX needs to be checked. Tav [1] Only elements in the SVG name space are tested. [2] The SVG specification explicitly allows styling properties such as 'font-family' on most SVG elements (e.g. <rect>) but there a many cases where they are of no use. [3] A property is useful if it changes an inherited or default value.

7 12

Regressions after r10326 (initial merge of the cairo-rendering branch)
by ~suv 29 Nov '11

29 Nov '11

Since we don't have a dedicated thread for regressions introduced with the initial merge of the cairo-rendering branch and I don't want to mix it with reports about merge of the rendering cache or the removal of libnr, I'm starting a new thread forwarding related confirmed reports in the bug tracker which haven't been mentioned on the list before: Bug #845153 <https://bugs.launchpad.net/inkscape/+bug/845153> "radial gradients not rendered correctly" Bug #837066 <https://bugs.launchpad.net/inkscape/+bug/837066> "Bucket Tool regressions with Cairo renderer" Bug #814179 <https://bugs.launchpad.net/inkscape/+bug/814179> "CMS tab: Yellow and Cyan colors are swapped" Bug #805392 <https://bugs.launchpad.net/inkscape/+bug/845153> "Circle resizing do not preserve stroke width" ~suv (trying to work around the flood of bug mails to developers and the apparent inability of gmail's web interface to filter on custom mail headers [1] ;) ) [1] List of custom mail headers in bug tracker e-mail notifications to allow filtering on assignee, status, importance, tags etc.: <https://help.launchpad.net/Bugs/Subscriptions#Bug_mail_headers>

3 6

Re: [Inkscape-devel] Make script?
by Martin Owens 28 Nov '11

28 Nov '11

> On 27 November 2011 00:18, Mark Voorhies <mark.voorhies@...2508...> wrote: >> Do we have an inkscape make script to convert inkscape-svg to >> plain-svg when compiling/building programs that include svg files? > > Is this what you're looking for? > > inkscape --export-plain-svg=stripped.svg inkscape.svg Yes and in a way no, you see having inkscape are a build dependency would probably be considered unacceptable for most build servers, or at least slow down the processing of package building enough for it to be not useful. I'm imagining something light and probably Independent. Perhaps even a script to automatically limits any xml structure to a set list of needed namespaces would be quite cute.

3 3

Make script?
by Martin Owens 27 Nov '11

27 Nov '11

Hey guys, Do we have an inkscape make script to convert inkscape-svg to plain-svg when compiling/building programs that include svg files? I just noticed that many of the svg icons shipped with Ubuntu have inkscape and sodipodi references. Could we help to make sure that inkscape-svg is more like sources and plain-svg is compiled? Thoughts? Best Regards, Martin Owens

2 1

how to query current color on code level?
by Aapo Rantalainen 23 Nov '11

23 Nov '11

Hi, how I query current color (color of the selected object), fill or stroke, on code? I.e. color of the box in left-bottom-corner "Fill:". I have read the code (version 0.48.2) and tried this: SPDesktop *_desktop = SP_ACTIVE_DESKTOP; guint32 color = sp_desktop_get_color(_desktop, true); printf("selected color: %6x\n",color); But it is always returning 'ff0000'. ** I have found the place which writes text (but not the value) for the tooltip: ui/widget/selected-style.cpp:195 __color[i] = (i == SS_FILL)? (_("Flat color fill")) : (_("Flat color stroke")); And value is on ui/widget/selected-style.cpp:979 g_snprintf (c_string, 64, "%06x/%.3g", color >> 8, SP_RGBA32_A_F(color)); But I do not see is this correct place at all for accessing it. -Aapo Rantalainen

1 0

Second opinion
by Kris De Gussem 22 Nov '11

22 Nov '11

Hi all Could someone check independently the modifications in css.h in revision 10748? Seems to me that besides the initialisation, the equals operator in the CSSPrimitiveValue class was not doing what it was supposed to do. Thanks. Kind regards Kris

2 1

glibmm dependency should be updated
by Markus Peloquin 20 Nov '11

20 Nov '11

I just went through a lot of trouble installing dependencies for inkscape in RHEL5 only to find this error nigh instantaneously in the build: color-profile.cpp: In static member function static void Inkscape::ColorProfile::set(SPObject*, unsigned int, const gchar*): color-profile.cpp:299: error: g_uri_escape_string was not declared in this scope color-profile.cpp:308: error: g_uri_unescape_string was not declared in this scope The g_uri_* functions came in glib-2.16, not 2.4 like configure.ac looks for. I'll just go back to using RHEL5 and hating life...

1 0

Inkscape wiki news
by Kris De Gussem 15 Nov '11

15 Nov '11

Hi all I thought it was good moment to give an update from the wiki spam fighting front. I performed a thorough check on the nature and type of the recent vandalism. It is actually quite possible that there is only a single vandal. Because there is no captcha system active, anybody with even very basic programming skills is able to make a simple bot in a few hours that allows automated account creation, uploading fake images and adding spam links. Luckily, all vandalism appears to come from a few specific but broad ranges of open proxies. The reason is that if a vandal is using the IP address he gets from his internet server provider, he gets quickly blocked. Even if he is lucky to have a very dynamic IP address, he generally runs out of available IP addresses quite soon. Therefore, if he is able to, a vandal can (and will) use badly configured open proxies to have a bigger impact. Anyhow, I first checked for the individual vandal IP addresses, which I blocked. After a while, I was able to detect a line in the vandalism and IPs used, so I was able to block a few relatively small /24 IP ranges. With information from wikipedia about known and dangerous or abused open proxy ranges, I finally blocked 5 quite wide IP ranges. As far as I can see, no genuine wiki edit is done from these ranges nor any genuine account created. Since the blocks, no vandal activity was seen. Hopefully this keeps on being the case. Kind regards Kris

2 1

powerstroke
by Alexandre Prokoudine 12 Nov '11

12 Nov '11

Hi, I was wondering how powerstroke LPE was doing and whether we should enable it, and just have come across a document on somewhat similar thing called Advanced Outlines in Synfig Studio. I think some people in this list will enjoy reading it :) http://bit.ly/qwZ4lD BTW, should we perhaps enable some of the LPEs in nightly PPA? Some testing wouldn't hurt? Alexandre Prokoudine http://libregraphicsworld.org

11 32

Foot unit
by Johan Engelen 10 Nov '11

10 Nov '11

Hi all, I just found this in the code: gchar const *sp_svg_length_get_css_units(SVGLength::Unit unit) { switch (unit) { ... case SVGLength::MM: return "mm"; case SVGLength::FOOT: return ""; // Does not have a "foot" unit string in the SVG spec ... That seems weird. Are we sure this is correct, instead of returning "ft" for the foot unit? Thanks, Johan

3 4