Subject: Re: previews for embedded objects
From: Caolan McNamara (cmc@stardivision.de)
Date: Wed Mar 15 2000 - 04:43:02 CST
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 15.03.00, 10:39:40, Paul Rohr <paul@abisource.com> wrote regarding
previews for embedded objects:
> At 08:11 AM 3/14/00 GMT, Caolan McNamara wrote:
> >One thing that word also does for the insertion of ole objects or
> >external entities such as equatrions and clipart is to have the
result
> >stored as a graphic which is a snapshot of the last graphical layout
> >of the active object. i.e. insert a equation edit object and the
> >result of the field is stored as a wmf picture of what the object
> >looked like, again allowing previewers and importers that do not
> >understand ole2 objects to at least display what it looked like. In
> >this case the field data itself contains the actual information as to
> >where the active objects data is stored.
> Oh, are those objects done as *fields* too? I didn't realize that.
Its gets a bit hairy in practice but thats the general idea. A non
floating object is usually a field with a result of an 0x01 graphic
placeholder and that 0x01 character has a fOle2 set so its fcPic is
the ole2 id which can be found under that name in the standard ole2
storage tree that contains the whole bundle and also has fSpec set and
sets a data offset variable so that a preview graphic can be found of
the object.
If the object is a floating object a 0x08 graphic is embedded where it
is anchored, that 0x08 graphic is an escher object which has some
custom fields set and contains a preview of the object, using the
custom data you can look up an offset of a different subdocument
called the textbox area, and in this area the field can be found. The
field is then the same as previously with a 0x01 with the OLE id of
the object and another preview for good measure. So one object and two
previews, this appears the be the default insertion mode for a
majority of objects.
Of course there is no real need to have a field wrapped around these
things as all are is specialized graphic placeholders and indeed they
often appear fieldless. Though for the most part word likes to put a
field around them. With me so far ? So no matter what you do if you
have some sort of a half assed *plan* as opposed to nailing bits of
jellylike functionality to a tree then you will be coming out ahead of
word already.
> Notes on this proposal:
> 1. Part of the idea here is to allow us to preserve round-trip
fidelity for
> embedded content from other file formats that we can't handle natively
in
> AbiWord.
> For example, say we're opening a Word2000 document on BeOS which has
an
> embedded Visio document as part of its OLE stream. Even though we're
not
> likely to find an appropriate handler to invoke which is capable of
editing
> that data on the current platform, there's still no reason why we
should
> lose track of it entirely. By "parking" the unreadable gunk in our
file
> format, our BeOS user could edit other parts of the document and then
save
> it back out, so that the embedded Visio content remained there when
the
> updated document got transferred back to a Windows box.
There will be issue of what to do when the user under BeOS in this
example *does* edit the graphic and modifies that instead. Its
basically a UI problem though of informing the user of the tragedy
that has befalled him as there is no way around it I can think of.
> How much information *does* OLE2 provide about the contents of one of
these
> blobs? How far up the usefulness curve do they go?
> - just a GUID?
> - a user-readable name for the application or file format?
> - a reliable mime type?
The CompObj data member thingy has a Class ID which uniquely
identifies the type of object, you could create a large database of
these and map them to mimetypes (but for instance imagine a word
document with 25 visual basic controls attached to it, each of these
will be stored as an ole object). There is also a Display name field
which for instance for windows PaintBrush is "PBrush" and a Clipboard
format name (the same for the most part), finally there is the format
version and a windows version, these are the ole2 encoding version and
the window compatible version I think. Dunno what you could do there,
you at least have a unique number which does identify the format (I
think now, don't place large bets on this) and a name that *might*
make sense to the user :-)
C.
This archive was generated by hypermail 2b25 : Wed Mar 15 2000 - 04:41:39 CST