[Drawkit] SVG / other file format support

[Brad Larson]

On May 12, 2008, at 9:04 PM, Graham Cox wrote:
>
>> 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.
>

I guess I was just asking that to determine where to patch things in.   
A File | Open sends an openDocument: message to the first responder,  
eventually triggering a readFromURL:ofType:error: message in the  
document.  Therefore, you'd have your file handling switches there or  
below.  With a File | Import, you could have a different entry point  
into the new document.  I would prefer to handle other file formats in  
the readFromURL and below.

>> 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.
>

So, we could use readFromURL:ofType:error: in DKDrawingDocument as the  
starting point to figure out how to process the input file and grab  
the extension using [[absoluteURL path] pathExtension].  To provide  
for categories on the DKDrawing, we could fire off a [drawing  
performSelector:NSSelectorFromString[NSString  
stringWithFormat:@"process%@:", extension]) withObject:data] message  
to the drawing object (I don't know how to do a class-based  
convenience constructor with a runtime-determined selector).  Then the  
categories would provide processSVG:, processDXF:, etc. methods in  
DKDrawing for their appropriate file extension.  The same would occur  
in reverse on writing to disk.  Does this make sense or am I going  
about things the wrong way?

>> 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.
>

Even if you did need to add more information to the drawing objects,  
can't you do that right now as per-object metadata?  Admittedly, I've  
not gotten that far into it.  Other than that, a simple category  
sounds like it would do the job for the formats I can think of.  I'll  
see if that's true as I get into it.

>> 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.
>


You've given us a great start with the framework itself.  If I can  
make something work, I'll post the patches here.
______________________
Brad Larson
SonoPlot, Inc.
3030 Laura Lane, Suite 120
Middleton, WI 53562