[Drawkit] SVG / other file format support

[Graham Cox]

On 13 May 2008, at 4:21 am, Brad Larson wrote:

> After a significant delay, I'm starting to work on porting our  
> drawing software across to DrawKit.  One thing that we will need is  
> native load/save support for our custom XML file format, and we're  
> looking at moving to SVG.  I am willing to add this functionality to  
> DrawKit, but I noticed that you have SVG import and export on the  
> roadmap and I thought I'd get your thoughts first before I started.

SVG would be cool, and definitely highly desirable. Right now, I have  
not done anything about this.

> How, architecturally, would you like this to be added?  Personally,  
> I would like to see SVG as a native file format for DrawKit, rather  
> than something you have to do a File | Import and Export for.  It is  
> a highly extensible standard that a lot of people are getting behind  
> (including Apple with WebKit).  Inkscape uses SVG as its native file  
> format and it seems to keep up well with all of its capabilities.   
> If you'd prefer to have different file formats be handled via import  
> and export instead of the standard load / save functions, I could do  
> that, too.

Bear in mind that your UI (in this case your menus) is up to you -  
DrawKit would neither prevent nor require you to implement this as a  
separate import/export command.

> Right now, all loading from disk is handled with a simple unarchiver  
> in DKDrawing's drawingWithData: method that takes only an NSData  
> object.  If you were able to pass in the filename or extension, you  
> might be able to have different parsers for different file  
> extensions (svg, svgz, dxf, ai, etc.) within this method.  The same  
> could be done in reverse for the writeToFile:atomically: method.    
> This would make it possible to do different file formats during the  
> load / save operation.  If so, would you want separate helper  
> classes for each different file type, load / save methods under  
> DKDrawing, or DKDrawing categories for each file type?

At the top level you'd probably just have a category of DKDrawing with  
a class method that accepted NSData in SVG format, returning a new  
DKDrawing instance, and an instance method that returned the data in  
SVG format. My view is that DKDrawing has no business interpreting  
file extensions or other file metadata - it just provides the basic I/ 
O methods for converting to and from SVG data. The document class  
(DKDrawingDocument or other NSDocument subclass) would figure out  
which methods of DKDrawing to call based on the extension, and that in  
turn allows you complete freedom to implement your UI however you want.

Regarding writeToFile:atomically:, that's more a convenience for quick  
and dirty saving - even DKDrawingDocument doesn't use it, but instead  
currently gets the NSData object. You could have a  
writeToSVGFile:atomically: for orthogonality if you wanted, but I see  
it as being more useful to just return SVG as NSData on request and  
let the document handle it.

Note that the current DKDrawing class methods that accept a path to a  
file were originally intended to allow the drawing to make a note of  
the file name and path in its own metadata, rather than interpret the  
extension. I realise that looking at those methods they might give the  
wrong impression, and my feeling currently is to remove them so that  
it's up to the drawing's owner to set up the metadata if it wants it,  
and to eliminate this possible confusion.

> I figure saving would be accomplished by iterating through the  
> internal store of objects and calling an svgRepresentation method,  
> or something corresponding to the file format, on them.  This might  
> be where separate categories for the file formats would be useful,  
> so that the drawing objects could each have their own input / output  
> methods.

Again a category for each significant piece of the data model would  
probably be what's needed here. Following the architecture of the  
NSCoder protocol would probably be the most sensible way to go if that  
works with SVG - it may be that this would be overruled by the SVG  
design, since hierarchical archiving may not be a good fit. I'd need  
to look at the SVG spec in detail to be sure. Hopefully you wouldn't  
need any ivars to support SVG, and it can all be done in a category.  
That would be the cleanest and easiest way to add the necessary  
methods, IMO.

> I wanted to check first so that anything I did would not conflict  
> with anything you had in mind or had already started.

Cool ;) well, as I haven't started the field's wide open. It would be  
great if you can add this, it would be a big thing I can cross off the  
"to do" list. Naturally I'll give all and any help I can.

cheers, Graham