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

I think that the only benefit of this is that you can incrementally load
your document as the PieceTable is populated since you can access the data
items (images and embedded content) as they're needed.

Right now AbiWord data items are placed at the end of the
document so they're not available until the document is loaded.

On the other hand as things stand now we don't incrementally build the
document as it is loaded into the piecetable. We first load the piecetable
then build the document. All the tests we've done show that the slowest
part of document loading is actually building the view (by about a factor
of 4).

It's not clear to me that going to structured files in a document wins us
much.

Cheers

Martin
Received on Thu Jan 13 11:46:53 2005