adding SVG export

[Scott J. <joh...@ve...>]

I'm pondering just how to go about adding SVG export to ivtools.  I 
have two choices.  Either use the existing OverlayScript class 
hierarchy to generate SVG as well as native ivtools format, or create 
a SVG-specific subclass for every class in the existing hierarchy:

http://www.ivtools.org/ivtools/doc/classes/derivedclasses.html#OverlayScript

(with the largest subtree here: 
http://www.ivtools.org/ivtools/doc/classes/derivedclasses.html#OverlaysScript 
)

In the past we've used both approaches for supporting multiple 
formats.  The support for idraw-EPS in parallel with 
anything-goes-EPS is implemented with a global flag used by the one 
set of methods that generates PostScript.  In vhclmaps support for 
graphic export versus native map feature export was done with two 
sets of methods (and classes).

The drawback of creating an SVG-specific subclass is further 
proliferation of the somewhat confusing tree of external view classes 
already in place for ivtools:

http://www.ivtools.org/ivtools/doc/classes/derivedtree.html#ExternView

plus because of the manual nature of the component class registration 
of Unidraw, I find it somewhat labor intensive any time I have to 
create one class for each graphic shape and/or container.  It would 
be a different story if I could isolate this to a single derived 
class.

The drawback of not creating an SVG-specific subclass is I'll have 
many methods with a body split into two parts, one part for SVG, one 
part for native ivtools format, without much common ground.  A lot of 
common ground in underlying methods that are invoked to prepare data 
for serialization, but little in the serialization process.

Anyone care to share their opinion?

Scott Johnston