Re: path data bug to be fixed in 2.0?

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
>>
>>
>>
>>
>
>