Subject: Re: XP design for image support
From: Paul Rohr (paul@abisource.com)
Date: Thu Apr 19 2001 - 21:22:59 CDT
At 08:52 PM 4/19/01 -0400, Dom Lachowicz wrote:
>>design constraints
>>------------------
>>A. We run natively on all kinds of platforms.
>>B. We use the maximum amount of XP code feasible.
>>C. We try hard for a common look and feel on all supported platforms.
>>D. In the rare cases where rules A-C conflict, sort in this order.
>
>I disagree with 'B'. s/feasible/reasonable/g and I'm happier. We could do
>*everything* in XP land if we tried hard enough. Using "feasible" in B.
>unfortunately directly clashes with stated goals A & D.
I tend to use the words synonymously. Sorry.
>>how do these constraints apply to images?
>>-----------------------------------------
>>1. We *must* be able to open and render an AbiWord document on *any* of
>>our
>>supported platforms. Period.
>>
>>1a. The only plausible exceptions to #1 are when a user makes a conscious
>>decision to embed platform-specific content (Bonobo, OLE, etc.) or fonts in
>>their documents. Even in that case, we should do our best to fall back to
>>something reasonable to allow the document to be viewed properly.
>
>We can actually get around this if we're sneaky and smart enough (and I
>think that we are). I have dreams of mime-types and data sniffers...
Sniffers and mime types only get you so far. If the only variant of the
content detected is in Visio format, then you either have to have
visio-handling code available or you punt.
My claim was that we should design *our* file format to always include an
alternate format that we *know* will at least be legible on our other
platforms. Even a PNG snapshot of that portion of the screen would help.
Remember that we're talking about *our* file format here. The only embedded
content there *we* put there on one of our platforms. For example, the
Win32 version's future OLE support (which is cheap and native) allowed a
proprietary-format Visio document to land there. The least we can do for
our other platforms is also stash a readable variant.
See the note under 1b for google terms to use if you want to find prior
discussions of this idea.
>>1b. Note that #1a is not just a platform issue -- it's quite possible that
>>two users on the same platform might have different applications or fonts
>>installed, making the viewing of shared documents more difficult (insofar
>>as
>>the document relies on the existence of that font or application). For
>>more
>>details on this issue, search the mail archives for discussions of embedded
>>data via the object tag.
>>
>>1c. Thus, the AbiWord *file format* should only support a minimum set of
>>image formats that we have XP code to handle. Currently, the plan is to
>>just have two -- PNG for raster, and a useful subset of SVG (ie, not much
>>more than WMF) for vector images.
>
>Woah, that's a big leap from 1b to 1c! What then for, say, a minimum set of
>fonts? Forget Hattenschwatler! The idea is to be as robust as possible, not
>as feature-limited as possible. There's a trade-off that probably should be
>reached, and I don't think that 1c fully appreciates that.
Don't get tto excited. :-) It's not that big a leap. All I'm saying is
that there's no need for arbitrary image formats wehn PNG plus SVG will
suffice.
Of course people will use Hattenschwatler, and thus make their documents
less portable. Ditto for Visio. All I'm saying is that we shouldn't make
the problem worse for common cases -- namely, gratuitous variantion in image
formats.
>>2c. Whatever mechanism we choose should provide a single API for
>>image-handling services to a number of places, including:
>>
>> - our file format
>> - other word processing file formats
>> - the clipboard
>> - the insert image / picture command.
>>
>>For more details, search the archives for posts from me including the
>>phrase
>>"switching mechanism".
>
>Agreed. A nice Interface/API is what we need. There's nothing distinct about
>points 1-4 here. A common interface will allow us to do them all. In fact,
>we already have that:
>
>1) File format - mime-type associated with data items. convertToBuffer() &&
>convertFromBuffer commands & "magic" sniffers.
>2) Other WPs - importers are smart enough to handle them based on other WP
>constructs/tags
>3) Clipboard - see point #2, specifically relating to RTF
>4) Insert - ez enough. See point #1
We have the mechanism for our imp/exp use. We don't yet expose a similar
mechanism for image conversions *to* those places in the code, so they can
use them too.
This is hardly rocket science, just a TODO.
>>For example, if support for the FOO format gets added to your platform's
>>underlying image-handling service, then nothing in the following code path
>>needs to change:
>>
>> FOO ---glue--> PNG ---GR_<os>Image--> screen / printer
>> ---IE_Exp--> file
>
>This much is right...
Cool. I'm glad we agree on *something* here. ;-)
>>Likewise, if someone (say Hub) adds XP support for a new image format (say
>>JPEG), there's essentially no platform code needed either, since the XP
>>code
>>already exists:
>>
>> FOO ---XP--> PNG ---GR_<os>Image--> screen / printer
>> ---IE_Exp--> file
>
>But this assumes that your platform either:
>1) Can't handle image type FOO already
Of course. That can (and does) happen. My platform doesn't support squat.
That's why I was so happy to see Mitchell add BMP and Hub get close to
adding JPEG. Thrilled, in fact.
>or
>2) You use a distinct library for handling type FOO1 than FOO2.
Yep. I want a design which allows us to not be locked into *only* the set
of formats supported by a single library.
>Further, I'm not sure that either #1 or #2 is necessarily true.
Not all image libraries support the exact same formats. I hope and expect
that for any given platform we need at most two sources of file format
converters:
- something offered by the system
- XP implementations of anything else
The latter augments the former as needed. Plus which, it's XP, so the first
platform who needs to add format FOO43 thus instantly makes it available for
any other platform who needs and wants it.
>>T2. GR_Image vs. gdk-pixbuf vs. miniMagick
>>There are well-understood libraries for supporting each format, most of
>>which we don't need, so for me the key design issue has been the switching
>>mechanism. Once that's done right, the remaining work is *very*
>>straightforward, and we can produce a maximally lean solution.
>
>GdkPixbuf was ~50 LOC. I'm relatively sure that similar implementations will
>be along the same O(n).
Awesome. That actually sounds quite high.
>>However, there are folks on this list who've been advocating that, instead
>>of implementing our own flyweight API for this, we adopt an existing API
>>and
>>codebase.
>
>An interface would let us get a "flyweight" API and handle things *very*
>robustly.
Great.
>>Any volunteers? ;-)
>
>+1 for a "committee," but I'll take it if noone steps up.
Let's keep discussing and see if we can lure anyone else in.
Paul
This archive was generated by hypermail 2b25 : Thu Apr 19 2001 - 21:15:22 CDT