Re: path data bug to be fixed in 2.0?

On 19 July 2013 05:25, ComSquare Martin Osieka <martin.osieka@comsquare.ch>
 wrote:
> My parser just draws the 'c' because spec says:


That sentence is only in the SVG 1.2 Tiny spec.

The SVG1.1 and SVG2 specs don't have that note.  Instead they say (in
appendix F.2 and C.2 respectively):

"If a ‘path’ element is the first element which has an error and the only
errors are in the path data specification, then render the ‘path’ up to the
point of the path data error."

Although it is not exactly clear whether the file should abort at that
point, or just the path.

Paul




On 19 July 2013 05:25, ComSquare Martin Osieka
<martin.osieka@comsquare.ch>wrote:

>  My parser just draws the 'c' because spec says:
>
> Values of the 'd' <http://www.w3.org/TR/SVGTiny12/paths.html#DAttribute>that do not match the EBNF are treated as
> unsupported<http://www.w3.org/TR/SVGTiny12/intro.html#TermUnsupportedValue>.
>
> => My interpretation: Don't render the element at all but log a warning.
>
> Martin
>
>
> On 18.07.2013 19:07, Paul LeBeau wrote:
>
> Actually it looks like FF is not doing things quite right after all.  It
> is not aborting at the error, it is actually drawing a bit extra.
>
>  Take for example the first character ("a"). The path definition is:
>
>  "M 0 220 C 0 60, 300 60, 300 220 L 300 550 300 400, C 300 600, 0 600, 0
> 400 C 0 240, 300 240, 300 400 "
>
>  The extraneous comma should mean that the parsing should abort with the
> definition equivalent to:
>
>  "M 0 220 C 0 60, 300 60, 300 220 L 300 550 300 400"
>
>  However the line is actually extending further down (to 300,600), so FF
> is actually rendering the equivalent of:
>
>  "M 0 220 C 0 60, 300 60, 300 220 L 300 550 300 400 *L 300 600*"
>
>  Paul
>
>
>  PS. Just to repeat to the list something I accidentally send just to
> Doug. My parser aborts like FF. I would obviously change that if the
> consensus of the list was that we should be more flexible.
>
>
>
>
>
> On 19 July 2013 03:51, Paul LeBeau <paul.lebeau@gmail.com> wrote:
>
>> I would definitely change it if that is what the WG decides is the right
>> thing to do.
>>
>>  Paul
>>
>>
>>
>> On 19 July 2013 03:48, Doug Schepers <schepers@w3.org> wrote:
>>
>>> Hi, Paul-
>>>
>>>
>>> On 7/18/13 11:44 AM, Paul LeBeau wrote:
>>>
>>>> My parser (as inconsequential as it is) also rejects these path
>>>> definitions. So that's two in the FF camp. :)
>>>>
>>>
>>>  Could you change your parser? Is it a hard change?
>>>
>>> Anything that makes it easier on authors should be preferred.
>>>
>>> Regards-
>>> -Doug
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>