[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Open Office File Format / Graphics / Draw
Forwarding answer from Dirk Schönberger <dirk.schoenberger@sz-online.de> : On Friday 01 August 2003 19:48, Daniel Vogelheim wrote: > Hi all, > I'm a bit late on this one... :-) Thanks for the interest ... > >I have uploaded some sample documents, you may find it at > >http://www.angelfire.com/realm/dschon/fillrule.xml > >http://www.angelfire.com/realm/dschon/almeria2_corel.xml > >http://www.angelfire.com/realm/dschon/logo.xml > > > Nice, and I think this is definitely worth a look for phase 2. > Just some comments: As I said, the project is largely work in progress, so I currently am not quite sure about where it is heading. There are some more sample documents, namely http://www.angelfire.com/realm/dschon/02_b.xml http://www.angelfire.com/realm/dschon/kiev.xml The second is converted from an Adobe Illustrator 10 file. Adobe Illustrator 9 and 10 introduced a PDF wrapper around the Postscript based actual file format, so I am rather proud to be able to decode flate style binary streams (implemented by zlib) with Ruby... > - The main part of the data appeared to be stroke paths, which are > constructed by path elements rather than the mangled path expressions we > copied from SVG. I like that a little better, but would still vote for > the SVG syntax for commonality reasons. :-) This is a trade-off, which I implemented for the following reasons: - I currently target no existing file format, but just generate SAX like events (got_begin_tag, got_end_tag, got_simple_tag) with my parser. I get the unmangled path compositing operators from the AI file format, so I didn'tz like to re-mangle this. - The operators / tags I generate contains slightly more information than the SVg form, namely the type of the end-points (curve or edge). This is less interesting for a render format, a la SVG, but it could become interesting for an editor format. > - There appeared to be some new stuff e.g. for gradients. However, I > couldn't make too much sense of it, since it contained some binary-type > data. Since we had previously agreed to approach SVG on gradients, it > might make sense to see how such functionality maps to our SVG proposal. Gradients are better supported in the actual version of the code, which was used to generated the newly uploaded sample documents. the 02_b.xml shows some nice examples about how gradients are supposed to work in Adobe Illustrator. This is only a Adobe Illustrator 5 sample document, I suppose more recent AI versions have a more complicated gradient system. Unfortunately I haven't seen sample documents for these newer gradients. > - I found it a little odd that some samples contained code which was > distinctly PostScrip-ish. I wonder whether that's a relict of an > incomplete XML-ization of the source files, or wether that's embedded > graphics more akin to embedded .jpg in our format. It is a relict of incomplete XML-ization. I will attempt to translate the whole file format to XML, but I think this may take some time. Now I have the context stack mechanism in place, I suppose I can start to work again on more features, like the AI3 style vector patterns (which accound for large amounts of the remaining Postscript fragments. Vector patterns in Adobe Illustrator are stored as string constants, which need some kind of nested parser. Regards Dirk
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]