Subject: Re: previews for embedded objects
From: Paul Rohr (paul@abisource.com)
Date: Wed Mar 15 2000 - 20:03:35 CST
At 10:43 AM 3/15/00 GMT, Caolan McNamara wrote:
>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 ?
Yep. It makes the usual odd kind of sense.
>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.
ROTFL. You hit the nail on the head there. What a tough choice:
(a) "some sort of a half assed *plan*"
(b) "nailing bits of jellylike functionality to a tree"
I guess I'd rather go out on a "limb" and choose (a). :-)
>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.
Yep. We have two UI choices in a case like this:
1. If we let them choose to edit the preview directly, we'll have to throw
out the invalid OLE2 blob. This process could be thought of as
"downgrading" the contents to something which is actually more portable.
However, in some cases information could be lost here, since presumably the
OLE2 blob stores some additional information not captured by the preview.
Thus, an appropriate warning would be needed when they start editing.
2. The other approach would be to show the user a preview instead of the
"real" OLE stuff and not allow editing at all, so that we preserve that OLE
blob in all its pristine glory.
Personally, I find option 1 more tempting, but it does make the wording of
that warning especially important. (In fact, there should probably be an
intermediate step which prompts them to *find* the relevant software if they
wish.)
>> 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 :-)
OK. Sounds like there might be a little bit of information worth parsing
out for user display -- for example, in the warnings for UI option #1 above
-- but not a heck of a lot more.
Maintaining that large database of mappings from IDs to real-world mimetypes
sounds like a process that's not likely to scale well. In most cases, just
saying it's OLE is probably a lot more reliable than assuming we can always
come up with the right mimetype.
Paul
PS: When you get a chance, how difficult would it be to run a script over
your vast collection of Word documents which just dumps out:
- the number of these other OLE blobs in the file
- how big each one is, and
- what the values for these OLE properties are?
I don't know how representative a sample this would be, but it ought to give
a rough feel for how wide a variation of these OLE blobs are found "in the
wild". :-)
This archive was generated by hypermail 2b25 : Wed Mar 15 2000 - 19:58:02 CST