Batik is correct in rejecting the content, although it is a bit confused in the error message. 'stroke-width' is a CSS property and as such can not use scientific notation, as you quoted (silly yes, but that is what CSS2 has said for a long time). The error comes because Batik is trying to interpret 'e-03' as a unit (like 'em' for example). It seems to be getting part way in and bailing - the error message may be intending to say 'does not support _this_ dimension value'.
Other attributes, like 'x', 'y' that are not CSS properties do support scientific notation. There is a summary of which attributes are presentation attributes and which attributes are 'real' attributes in the back of the SVG specification.
I don't know if this means you are wrong about the SVG specification. :)
BUFFET Philippe (CS SYSTEMES INFORMATION) wrote:
I am currently carrying out a study about the capacity of the SVG format to handle technical illustrations. This means, illustrations with thousands of graphic primitives (polyline, polygone, path) and coordinates given with lots of digits precision for printing issues
Apparently, the CSS engine of Batik does not handle scientific notation for the style-width property (and perhaps for other properties, i have not tested the whole of them)
the following example is extracted from a conversion programme :
<circle cx="0.905334" cy="3.5029" r="0.0196838" style="fill-rule:evenodd; fill:none; stroke-linejoin:round; stroke-linecap:round; stroke:#000000; stroke-width:4.90147e-03; stroke-dasharray:none" />
this example provokes the following exception Batik exception :
SVG Error:
file:/C:/Documents and l_mm_242100_0_aae0_01_00_CV.svg:
The attribute "style" represents an invalid CSS declaration ("fill-rule:evenodd; fill:none; stroke-linejoin:round; stroke-linecap:round; stroke:#000000; stroke-width:4.90147e-03; stroke-dasharray:none").
Original message: The "stroke-width" property does not support dimension values.
However, the SVG 1.1 Specification specifies the following points :
'stroke-width' Value: <length> | inherit Initial: 1 Applies to: shapes and text content elements Inherited: yes Percentages: Yes Media: visual Animatable: yes
<length>: A length is a distance measurement. The format of a <length> is a <number> optionally followed immediately by a unit identifier. (Note that the specification of a <number> is different for property values than for XML attribute values.)
If the <length> is expressed as a value without a unit identifier (e.g., 48), then the <length> represents a distance in the current user coordinate system.
<number> (real number value): The specification of real number values is different for property values than for XML attribute values.
* CSS2 [CSS2] states that a property value which is a <number> is specified in decimal notation (i.e., a <decimal-number>), which consists of either an <integer>, or an optional sign character followed by zero or more digits followed by a dot (.) followed by one or more digits. Thus, for conformance with CSS2, any property in SVG which accepts <number> values is specified in decimal notation only.
* For SVG's XML attributes, to provide as much scalability in numeric values as possible, real number values can be provided either in decimal notation or in scientific notation (i.e., a <scientific-number>), which consists of a <decimal-number> immediately followed by the letter "e" or "E" immediately followed by an <integer>.
Is this a bug of Batik? or am I wrong about the SVG specifications?
(i am using Batik Squiggle 1.5)
Thank you for response,
Philippe
------------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
