- From: Didier PH Martin <martind@netfolder.com>
- Date: Wed, 8 Mar 2000 16:37:54 -0500
- To: "Jon Ferraiolo" <jferraio@adobe.com>, "Elliotte Rusty Harold" <elharo@metalab.unc.edu>
- Cc: <donpark@docuverse.com>, <xml-dev@xml.org>, <www-svg@w3.org>
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
Received on Wednesday, 8 March 2000 16:37:31 UTC