Subject: XP design for image support
From: Paul Rohr (paul@abisource.com)
Date: Thu Apr 19 2001 - 17:30:06 CDT
Folks,
There've been a lot of great ideas scattered through today's threads in
image support, but the discussion seems to be getting fuzzy.
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.
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.
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.
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.
1d. I suppose an argument could be made for adding JPEG as a third
"abi-native" format, but I'd like to resist the temptation to do so. The
tradeoff is extra code (to support JPEG) versus a possibility of bloat
savings from JPEG's lossy compression of huge images. However, for the most
part, it's not reasonable to print huge images on the kinds of paper sizes
usually used by word processors.
2. However, we definitely should have a scalable way to add support for
more image formats.
2a. In particular, any image file format which is common on a given
platform *must* be supported there. For example, BMP on Windows, PICT on
Macintosh, and XPM on Unix are all much much more important on their
"native" platform. The need for those file formats on other platforms is
much less severe.
2b. Likewise, any image file format which is common online should be
supported on all of our platforms. For example, PNG and JPEG now. GIF,
however, probably waits until the patent expires. (Again, for details,
search the archives.)
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".
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:
- image conversion
- the switching mechanism
2e. We should *certainly* take advantage of high-quality native file format
converters, where available. To do otherwise is reinventing the wheel, and
just plain silly. IIRC, Thomas added support long ago to do so for BeOS,
and insofar as other platforms (such as QNX and more recent versions of
MacOS) also ship with similar libraries, then we should add the necessary
glue code to use them too.
2f. So long as we get our class design right in the "switching mechanism",
then each platform can choose at compile time which file formats to
implement via OS services, and which to build from our XP libraries. (This
is similar to what we currently do with the zlib, libpng, and iconv
libraries.)
3. All of the above are eminently doable for 1.0, I'll assert.
4. Once 1.0 ships, it might be nice to refactor the switching mechanism so
that additional file format converters could be added via drop-in modules.
However, the first requirement is to get this all working statically.
remaining issues
----------------
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:
T1. in-memory format -- PNG vs. native
--------------------------------------
For an XP app, it's clear that the platform-specific image-rendering code
will have a "preferred" format for raster images. Any image not already in
that format will need to be converted before it can be rendered.
The proposed design minimizes the platform-specific implementation burden by
converting all raster images to PNG. This means that there's essentially
*zero* new platform code needed to add support for image format N+1, since
it was either added as an Abi XP class, or at the OS level (which still gets
invoked by the same glue code used to invoke a subset of the first N formats.)
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
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
At most, you'd need to tweak the switching mechanism's class factory or
makefiles to *not* add that XP code if your platform already supported that
format.
However, it's worth pointing out that some folks might not want to keep the
PNG version around in memory, preferring to hang onto the image in some
other screen-friendly format, presumably a platform-specific one. This kind
of strategy works well for read-only apps, since they don't have to preserve
enough information to also save the image in an XP-friendly way.
We do. (See #1c above.)
T2. GR_Image vs. gdk-pixbuf vs. miniMagick
-------------------------------------------
I must admit that my bias going into these discussions has always been to
come up with a simple XP switching mechanism, and then implement the
subclasses in one of the following ways, as appropriate:
- via glue code to an existing system service
- via a stripped-down XP implementation of the underlying libjpeg, etc.
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.
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.
I'm pleased to see that both Paolo and Leonard are on this list as
advocates for the existing gdk-pixbuf and miniMagick APIs, so I can learn
what I'm missing. :-) My next step is to reply to their threads, I guess.
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? ;-)
Paul
This archive was generated by hypermail 2b25 : Thu Apr 19 2001 - 17:22:33 CDT