Subject: Re: XP design for image support
From: Dom Lachowicz (cinamod@hotmail.com)
Date: Thu Apr 19 2001 - 19:52:44 CDT
>Since Dom's unclear on the technical merits of my intended design, I'll
>take
>a new, fresh stab at explaining it. Most of the substantive discussions of
>these issues on this list are over a year old, and I doubt that everyone's
>found the time to troll through the archives to get up to speed on earlier
>discussions.
Thanks a lot. I know that you're a huge advocate of mailing-list discussion,
searching back through threads to find docs/design decisions isn't exactly
pleasurable. We're seriously lacking all sorts of docs on the underlying
design of Abi. Jskov has done well to get us at least inline Doxygen
comments as a standard. There should also be more docs lying around (maybe
with UML or Pics) about many/all of the design decisions. All we have now is
basically Jeff going "well, I'm going to write 6 pages of fluffy quasi-spec
on a 30,000 LOC implementation of a piecetable." The (unfortunate) short
story is that if we had to deliver this product to a client complete with
Doc/Spec, we'd get sued.
Why is this important? Well, who here helped Jeff write the PT? XAP vs. AP?
/me searches for hands in the crowd
Ok, so really no one besides Paul, who is an invaluable resource BTW :) So
being the new developers/maintainers, it is absolutely *essential* to have
these things lying around.
>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.
>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...
>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.
>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
>2d. One important consequence of #2c is that we ought to be able to
>isolate
>our platform-specific imaging code to minimal implementations of two
>GR_Image subclasses. All other imaging code should fall into the following
>XP categories:
We have this. Raster and Vector. PNG is a raster. So is JPG, GIF, etc... SVG
& WMF - vector. The distinction already exists suffeciently in my mind.
>AFAIK, little of the preceding should be controversial -- and I'm sure
>people will be happy to register specific complaints if I'm wrong. :-)
>
>The three remaining technical issues I can think of are:
>
> T1. in-memory format -- PNG vs. native
> T2. GR_Image vs. gdk-pixbuf vs. miniMagick
> T3. who's gonna own this?
>
>Of these, I have strong opinions on T1, some half-formed intuitions on T2,
>and little to say about T3. Here goes:
<snip>
>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...
>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
or
2) You use a distinct library for handling type FOO1 than FOO2.
Further, I'm not sure that either #1 or #2 is necessarily true.
>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).
>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.
>T3. who's gonna own this?
>--------------------------
>This is, of course, the most important "technical" issue. There are a lot
>of people who've stepped up to offer their 2 cents and partial solutions,
>but that's not enough.
>
>AFAIK, we still need someone to step up and take ownership of the entire XP
>design. It's one thing to say that something "ought" to work on other
>people's platforms, but the real test is to take responsibility for making
>sure that we have a solution which, in fact, *does* work everywhere in a
>reasonable way.
>
>Any volunteers? ;-)
+1 for a "committee," but I'll take it if noone steps up.
Dom
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
This archive was generated by hypermail 2b25 : Thu Apr 19 2001 - 19:52:56 CDT