wrong handling of invalid style declarations

[Thebohemian-users]

Hi,
I have worked quite some time on a map in SVG format
with Inkscape 0.42.2. When I upgraded to 0.43 the fill
color of the polygons were lost.

I always saved it as a "plain svgz". You can find the
file here:
http://page.mi.fu-berlin.de/~rschuste/olsrexperimentberlin-1.0-rc1.svgz

What was green in 0.42.2 is now black.

Btw: I just see that Mozilla renders the file in the
correct way.

[Thebohemian-users (thebohemian-users)]

operating system information:
Gentoo GNU/Linux, GNOME 2.10.2

Configure:
./configure --prefix=/usr --host=i686-pc-linux-gnu
--mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --build=i686-pc-linux-gnu
--with-xft --with-gtkspell --without-bonobo --without-inkjar
--with-gnome-print --with-python --with-xft --with-gtkspell
--without-bonobo --without-inkjar --with-gnome-print
--with-python --with-xft --with-gtkspell --without-bonobo
--without-inkjar --with-gnome-print --with-python
--disable-gtk-doc

GCC: 3.4.4

[Buliabyak-users (buliabyak-users)]

In fact, this was a bug in 0.42 and before, while 0.43 is
correct. The black rendering
of your file is correct, it is confirmed by both Batik and
Firefox. The real bug was in
0.42 writing the style of the polygons in such a way that it
was lost. Namely, in many
objects it used an exponent in stroke width:

stroke-width:7.3501251e-05

but per CSS, this is invalid, and as a result the entire
style= attribute is ignored,
including fill color (so it defaults to black). To manually
fix this file, simply
replace in a text editor all occurrences of "7.3501251e-05"
by "0" and the green color
will come back. The 0.43 never writes exponents where they
are not allowed.

I'm not entirely sure that ignoring the entire style
specification due to parsing error
in one property is correct and compliant behavior. So I'm
assigning this bug to Peter
Moulder who did this fix, so he can comment on this and
close this bug if it is indeed
correct behavior.

[Peter Moulder (pjrm)]

As Bulia says, exponents are not valid in CSS numbers:
neither CSS2 (http://www.w3.org/TR/REC-CSS2/grammar.html#q2)
nor the more general "core CSS" language
(http://www.w3.org/TR/REC-CSS2/syndata.html). The SVG spec
(v1.1) in fact has the same restriction for properties even
when specified as individual attributes (stroke-width="...")
(http://www.w3.org/TR/SVG11/types.html#BasicDataTypes).

I also believe we have incorrect behaviour when parsing
invalid style declarations: we should ignore the invalid
declaration (until the `;') and accept the rest.

(Source: Although the SVG spec (v1.1)
(http://www.w3.org/TR/SVG11/styling.html#StyleAttribute)
isn't explicit about what to do when the style attribute
includes invalid declarations, I would presume that CSS
rules apply, and in particular that the "Illegal values"
bullet item of
http://www.w3.org/TR/REC-CSS2/syndata.html#parsing-errors
applies.)

Currently, libcroco doesn't conform to the requirements for
error handling. I'll try to change that.
The fix is for libcroco to use the core grammar of

[Buliabyak-users (buliabyak-users)]

Originator: NO

Actually this file must be black, but for a different reason. Its shapes
have huge transform matrices. Most of them have invalid stroke-width
properties (with exponents). Per CSS, this means this property is not set.
Per SVG, this means it has its initial value which is 1. And after being
multiplied by the huge transform matrices, these extra wide strokes fill
everything with black, except for some boundaries and the legend. This is
how Batik renders this file and Inkscape now complies too, after my
libcroco fixes today. Closing as fixed.