MHonArc v2.5.0b2 -->
office message
[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]