Re: Negative values in polygon/polyline points

On Tuesday, March 23, 2010, 12:01:10 AM, Jeff wrote:

JS> Two-part question.

Hi Jeff. This question was discussed on todays SVG WG telcon.

JS> 1) The SVG spec states that superfluous whitespace (and comma) can be
JS> removed from the path's d attribute [1] so that

JS>     L 100, -100

JS> can be written as

JS>     L100-100

Yes.

JS> Is this described in the EBNF grammar [2] ?  

No, its only described in the prose, in section 8.3.1 General information about path data. In the bulleted list, these two list items modify the grammar:

# Superfluous white space and separators such as commas can be eliminated (e.g., "M 100 100 L 200 200" contains unnecessary spaces and could be expressed more compactly as "M100 100L200 200").

# The command letter can be eliminated on subsequent commands if the same command is used multiple times in a row (e.g., you can drop the second "L" in "M 100 200 L 200 100 L -100 -200" and use "M 100 200 L 200 100 -100 -200" instead).


On the call we found that suboptimal, and wondered about rewriting the EBNF, but worried it would become rather huge.

JS> I'm not a EBNF expert but
JS> couldn't find that.  If this is not something you can effectively
JS> represent in EBNF, could an example be added to the bulleted list of
JS> shortcuts so that it is clear that negative coordinates can be handled
JS> this way?

Yes, we can do that. The first of the bullet points I quoted above could be expanded to cover that case.

The EBNF could be changed also, but only by adding separate productions for positive and negative numbers ....

JS> 2) My second question is whether this grammar also applies to the
JS> polygon/polyline points attribute?  Can

JS>     points="100, -100"

JS> be rewritten as

JS>     points="100-100"

It should be allowed, implementations (mostly) allow it, but the BNF for points and polygons crystalised much earlier than the BNF for path; for path we were much more concewrned about filesize,  and we did not spot this inconsistency at the time.

JS> Doing a quick test shows that Opera, WebKit and IE9 support this
JS> shortcut but Firefox does not.  I couldn't find the rule in the
JS> grammar.

Its not in either the grammar nor in prose. 

JS> Here's my test file:

JS> <?xml version='1.0' encoding='utf-8'?>
JS> <svg xmlns="http://www.w3.org/2000/svg">
JS>  <polygon fill="red" transform="translate(100,100)"
JS> points="0,0,100,0,100,-100,0,-100" />
JS>  <polygon fill="green" transform="translate(100,100)"
JS> points="0,0,100,0,100-100,0-100" />
JS> </svg>

JS> Since most browsers seem to support it and it aligns with path's @d I
JS> guess it would make sense to allow it.  Can you clarify the points
JS> grammar [3] in a similar fashion?

If we can add it to the grammar for 1.1SE we will, otherwise we will add clarifying prose.

Another thing that came up on the call - you mention not being a BNF or EBNF expert. Is there another formalism which would be easier to understand? (Perhaps not for 1.1SE,  but we could switch to something better for 2.0)

Also, would sample code help? We wondered about having code that will take a path, check its valid, and then either make it most readable (lots of whitespace and commas, add omitted path commands) or maximally compact.

JS> Thanks,
JS> Jeff Schiller

JS> [1]
JS> http://dev.w3.org/SVG/profiles/1.1F2/publish/paths.html#PathDataGeneralInformation
JS> [2]
JS> http://dev.w3.org/SVG/profiles/1.1F2/publish/paths.html#PathDataBNF
JS> [3] http://dev.w3.org/SVG/profiles/1.1F2/publish/shapes.html#PointsBNF

ACTION-2753
ACTION-2752



-- 
 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Thursday, 8 April 2010 21:06:50 UTC