[Drawkit] SVG / other file format support

Tue May 13 14:33:24 PDT 2008

You might want to look to NSAttributedString as a model.  It's been
through a few iterations as people needed more from it.  The most
generic methods are

- (id)initWithURL:(NSURL *)url options:(NSDictionary *)options
documentAttributes:(NSDictionary **)dict error:(NSError **)error;
- (id)initWithData:(NSData *)data options:(NSDictionary *)options
documentAttributes:(NSDictionary **)dict error:(NSError **)error;

- (NSData *)dataFromRange:(NSRange)range
documentAttributes:(NSDictionary *)dict error:(NSError **)error;
- (NSFileWrapper *)fileWrapperFromRange:(NSRange)range
documentAttributes:(NSDictionary *)dict error:(NSError **)error;

The options control how the file or data is read, while the document
attributes describe metadata and other information about the document.
 File type is one of the document attributes, identified by UTI.

A file wrapper lets you deal with bundle-based file formats.  The
NSErrors provide nice user-presentable explanations of problems
reading or writing the specified format.

-Ken

On Tue, May 13, 2008 at 12:56 PM, Brad Larson <larson at sonoplot.com> wrote:
>
>  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
>
>
>
>  _______________________________________________
>
>  Drawkit mailing list
>  Drawkit at lists.apptree.net
>  http://lists.apptree.net/listinfo.cgi/drawkit-apptree.net
>

ou