W3C home > Mailing lists > Public > www-svg@w3.org > June 2003

Re: Request for path having child paths or being composed of point elements

From: Tobias Reif <tobiasreif@pinkjuice.com>
Date: Tue, 17 Jun 2003 22:30:33 +0200
Message-ID: <3EEF7A69.7000009@pinkjuice.com>
To: www-svg@w3.org
CC: Andy Bailey <ambailey@usb.edu.co>

Andy Bailey wrote:

 > I just happen to think that xsl is the best invention since sliced
 > bread. And want to be able to process everything xml using xsl.

So with "xsl" you mean XSLT ("XSL" generally refers to XSLT+XSLFO).

 > It just
 > happens that I want to reverse a svg cubic spline path using xsl and
 > there is no easy way to do it.
 > Idea 2:
 > For paths it would be nice to have a syntax that could be processed
 > with
 > xsl so instead of: <path d="M 0 0 C 100 100 .. "/>
 > have
 > <path>
 > <action type="M" x="0" y="0"/>
 > <action type="C" x="100" y="100"/>
 > ....
 > </path>

You might want to try XSLT 2:
http://www.w3.org/TR/xslt20/ plus
http://www.w3.org/TR/xpath20/ etc,
for example with Saxon
http://saxon.sourceforge.net/ .

Specifically, I suggest to play with
http://www.w3.org/TR/xquery-operators/#func-tokenize .

 > Then anyone could invert the order of the path (ok maybe for relative
 > paths the maths involved is too dificult to do in xsl-

Check out
and also check what XSLT 2 has to offer.

 > Not everyone will be using software to generate the svg. What about
 > web
 > services that generate xml from a database and get processed by a xsl
 > transformation.

Yes, XSLT is a good candidate in scenarios where a web service processes 
  or generates XML (eg SVG), or does both.

 > I think the <path d attribute breaks the idea of xml, and there should
 > be elements that have the same funcionality.

There has been discussion about this before; I think that file size was 
the main argument for the current syntax.
(Many SVGs (especially many of those generated by WYSIWYG editors) 
mainly consist of path data.)

 > I understand that the idea is to have a compact reprentation but it
 > would be good to have an alternative.

I think the suggestion makes sense. Then let author or tool choose which 
syntax to use.

On the other hand, it's not really surprising that in addition to an XML 
parser, you need some micro-parsers for script, style, and ... path data. :)

 > By the way is there any other way to do what I want?

To handle the path data attribute, try XSLT 2, possibly with extensions.


Received on Tuesday, 17 June 2003 16:30:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:56 UTC