Re: EXI WG's inquiry about ISSUE-2050

On Tuesday, April 24, 2012, 11:52:49 PM, Takuki wrote:

TK> After looking around for any existing such efforts, we were informed of
TK> ISSUE-2050 [1] that seems to suggest there has been similar interest within
TK> SVG WG itself as well.

Yes, the trade-offs regarding expressivity, manipulability, verbosity and filesize for SVG paths have been a constantly recurring feature in the design of SVG.

TK> It looks as though, however, that the issue has not been given much attention
TK> since its creation. We would like to know if the issue is still considered
TK> valid within SVG WG, and if so, there is any plan to revisit the issue in the
TK> near future. 

Having fixed the path syntax for SVG 1.0, the problem then became how to introduce a new, more verbose syntax in parallel while minimizing the impact on existing implementations, and not requiring content authors to redundantly author both forms, for old and new user agents.

Besides better compression with schema-aware processors, the other motivation for considering the more verbose syntax was the ability to manipulate (and perhaps style) subpaths without content authors having to implement a path parser themselves. It would also allow smaller incremental changes to be made to individual subpaths without having to pull out an entire, possibly large, path attribute value and replace it with another, probably similar, value.

SVG 1.1 is now completed, and the WG is concentrating on requirements and features for SVG2. So it is a good time to re-consider this longstanding issue; we looked at it on todays SVG conference call, and I was given ACTION-3270 to relay to you the results of that discussion.

One way forward which we have considered in the past is to add a DOM API which would allow interconversion of the two path forms. This would allow content authors who want to manipulate sub-paths to call the API, get a handle to the verbose form, manipulate it and then call the corresponding API to convert it back to the old path syntax. this approach would also allow deployment to a mix of old and new user agents, by supplying  a 'shim' or script which implements the API if it is not supported natively.

The API could also be used by an EXI pre-processor, taking existing SVG content and converting paths to the new form. This could be transmitted as EXI and then on the receiving end, converted back to the old syntax (to minimize the DOM footprint and to allow rendering in existing implementations).

TK> The EXI WG would like to move the issue that is well described in [1] forward,
TK> however, we do not want to make an overlapped effort inadvertently. It would
TK> be ideal if the two WG can make a concerted efforts toward the same goal.

The SVG WG would value the opportunity to work on this together with the EXI WG.


-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Thursday, 26 April 2012 22:21:41 UTC