Re: Generic Embeddable plugins.

> My concern here is that while it is possible to
> embed XML data such as
> SVG and MathML as XML in the AbiWord document, if
> (for example) you
> create an SVG image in Adobe Illustrator, insert it
> into AbiWord, later
> extract it from AbiWord, then the resulting SVG will
> not be the
> original. Now, you may argue that the differences
> are acceptable, but
> it doesn't really satisfy me. The easiest way around
> this is to embed
> the original file (base-64-encoded, naturally).

Storing a Base64 representation of the document is by
far the most natural and robust way of storing this
information in a flat, AbiWord XML file. Embedded XML
namespaces will likely cause our parser to be
confused, plus it doesn't address the general case
where the thing is not XML (eg. an Excel spreadsheet).

Having a common solution instead of 2 competing
solutions that differ depending on the embedded file's
type is probably preferable here.

Something possibly worth examining is using a
structured document format, such as OOo does, in which
embedded objects (including things like PNG/JPEG
pictures) are stored in their own "stream".

It should be noted that I'm not advocating adopting
the OOo format (nor am I advocating against it). I'd
just like to point out that:

1) The problem of storing embedded content has been
solved before by people who have given it a lot of
thought
2) The problem of how to identify and present embedded
content has been solved before by people who have
given it a lot of thought
3) We have easy access to their answers

"If I've been able to see as far as I have, it's been
because I've stood on the shoulders of giants."

"Those who do not learn from history are doomed to
repeat it"

etc...

Best,
Dom

                
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Received on Wed Jan 12 21:52:41 2005