Hi Joseph, There is another parameter: which SVG profile do you intend to address? Tiny or Full? It really makes a difference.
We (Beatware) did a lot of work to optimize the file size for our output, especially for SVG Tiny. I am not sure there is really a problem on the desktop where bandwidth is ubiquitous even if it does not hurt to output well structured code... We have an option in our products to generate a more "compact" SVG code at the expense of readability (we remove any comment, shorten the variable names, etc...). Are you ready to go that far? Marc --- In [email protected], "Joseph" <[EMAIL PROTECTED]> wrote: > > First, I would like to thank you for the links you provided me. :) > > --- In [email protected], "Andreas Neumann" > <[EMAIL PROTECTED]> wrote: > > Hi Joseph, > > > > http://www.carto.net/papers/svg/postgis_geturl/ has a listing of > > possible optimizations at the bottom of the tutorial. > > > http://www.svgopen.org/2002/papers/isakowski_neumann__svg_for_interac tive_topographic_maps/index.html > > > has a section on "code optimization". > > > > As you mentioned yourself, performance is not only about filesize. > > It also depends on the implementation and the underlying XML parser. > > To get more info about that you would have to contact the authors of > > the implementation, f.e. you could ask at the batik list or contact > > the Adobe people. > > What you explained above is good to be mentioned but then I have a > problem I think! How can I make it possible to have a general > optimisation mechanism that does not depend on any particular > "rendering implementation" since we have different authors with > different rendering implementations. Am I right or is there something > that I have missed?! > > > > > In my own experience with map data, it is key to reduce the number > > of elements in the DOM. Maintaining the DOM is memory and computing > > expensive and keeping the number of elements low, helps. For example > > if you represent an island with lots of closed, disjunct polygons it > > is better to represent this island by one single path-element with > > several "M"ovetos than creating several <path/> elements and > > grouping them. I once came across this while processing > > Navteq/Teleatlas data that was extremely segmented. I first > > de-segmentized this data and got much better performance. > > > > Another thing is to reduce accuracy. There f.e. is no use in > > representing data with 8 decimal places if the base unit is a meter > > and accuracy is about 10 meters. Also, reducing the number of > > vertices helps. Many GIS or graphics software have simplification > > and smoothing functionality. > > > > In cartography, f.e. one good spline curve can replace a dozen or > > more single vertices and it even looks better when zooming in. > > All the things you have mentioned above, I have actually done during > my academic year here in Oxford. The good thing is that, all the bove > does actually optimise the SVG file somehow but the problem remains if > we have animations etc.. > > I have used XSLT to the all the following. I tried to optimize SVG > paths by converting to relative or absolute, converting lines to > horizontal or vertical lines when appropriate, C and Q to S and T > shorthands where appropriate, reduce accuracy of path coordinates, > simplifying a curve by converting cubic splines to quadratics or lines > where appropriate. > > > > > I also made the experience that using a lot of <symbol /> and > > <use /> elements slowed down the Adobe viewer but worked well in > > other viewers. This must be an implementation issue and probably > > depends on how the DOM is maintained and the XML parsed. > > > > Again, this actually will give me a problem. What am I going to > concentrate at? What implementation? Again, can I make it fit all > implementations? What do you think? I don't want my optmisation to > depend on one implementation or covering all implementations which > then it might give problems!? > > > Hope this helped a bit to get started. I would be very much > > interested in your results. Please publish them if you make > > progress. > > > > It did help, thanks alot. It gave me ideas. I will be coming back here > giving results of my dissertation. I will let you know :) Hope this > discussion will carry on since it does help me with the work. > > > Good luck with your work, > > Andreas > > Thank you > Joseph ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
