xml-dev - RE: What is wrong with SVG?

["Didier PH Martin" <martind@netfolder.com>]

Hi Jon,

Jon Said:
There has been lots of email disagreeing with the tradeoffs and decisions
made with SVG's path syntax. There were conflicting goals in making
decisions. The path data syntax in the current spec gives maximum
importance to file size compression as we decided that goal had very high
priority.

Didier replies:
I am doing some experiments in Didier's lab with SVG files and I have found
that up to now the actual SVG recommendation does a good job for interactive
technical manuals.

Today, the figures used in these manual are encoded in CGM. Also, these
files tend to be usually quite big. The experiments consist to convert these
files into SVG and use bi-directional Xlinks to link the figures pointers to
the parts descriptions. Illustartion can be very sophisticated as have a lot
of details. Just imagine an interactive tech manual for a car, a train, an
airplane!

I tried to convert the paths (used quite often in the figures) into elements
and I got an explosion of elements and a huge DOM. But with the actual
format the number of nodes seems reasonable

To implement bi-directional xlinks, I used JavaScript to implement an xlink
interpreter and because of this fact, the size of the DOM is critical.

So, my conclusion, up to now, is that for sophisticated SVG applications
like interactive technical manuals, the size of the DOM is very very
important. To have more elements would prevent more sophisticated
applications.

Numbers?:
 The SVG file creation: An exported DXF file from autocad is then imported
into a) Corel or b) Adobe illustrator and then exported from these authoring
tool to create an SVG file. The figure contains approx 500 path elements
each patch containing an average of 10 instructions. In its cuurent format I
got 570 elements nodes. To convert each instruction into elements means now
500 X 10 = 5000 element nodes. I can tell you that the difference in
performance, memory usage is huge and can make the difference between what
is feasible and what is not.

Next step: use XSLT to modify some parts of the parts catalog, I'll see the
real difficulties in the praxis....

Cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: Web Chicago(http://www.mfweb.com)
             XML Europe (http://www.gca.org)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)
Products: http://www.netfolder.com


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************