Subject: consensus! (was Re: Image handling [draft])
From: Paul Rohr (paul@abisource.com)
Date: Fri Apr 20 2001 - 12:50:02 CDT
Dom,
Thanks. If I understand your proposal correctly, I think we're all in
agreement. Indeed, I think you're proposing something nearly identical to
what many of us have been asking for all along.
One more summary, just to make sure we're all on the same wavelength.
1. Images get persisted to the file format in a minimum number of file
formats -- PNG (and perhaps JPEG, but we don't yet have consensus on this)
for raster images, and SVG for vector images.
2. We leverage available OS libraries to import other raster and vector
formats. The OS specific details for this are hidden behind a flyweight XP
interface that can be used anyplace in AbiWord that we might run across
image content. [A]
3. For platforms which don't have a system service for image conversion, we
add optional XP libraries, such as libjpeg or IM or miniIM or an XP
gdk-pixbuf or whatever. These use the same interface(s) as needed in #2.
4. For platforms with "weak" system services, it might be nice to to
augment #2 with #3. (For example, I doubt that most platforms or imaging
libraries have vector support that's anywhere near as useful as their raster
support.) If it's easy to spec the interface to do so now, great. If not,
we can come up with the necessary fixes as needed.
5. We seriously consider Hub's suggestion to streamline the import /
conversion process of raster images to be RGBA-centric instead of
PNG-centric. The existing process works as follows:
file --> FOO --> RGBA+metadata --> PNG --> RGBA --> screen / print
PNG --> file
Note that this code path only applies for non-AbiWord content. For *our*
documents, the code path is much simpler:
file --> PNG --> RGBA --> screen / print
PNG --> file
A potential advantage of the current approach is that we can minimize the
in-memory footprint by carrying around compressed PNGs for images that
aren't on-screen. The corresponding disadvantage is that we have to
compress them on import and then decompress them to RGBA as needed for
display. The former step only happens at most once (in the lifespan of the
document), but the latter could be quite frequent without a good caching
scheme.
The proposed alternative is to only do the PNG encoding on export:
file --> FOO --> RGBA+metadata --> RGBA --> screen / print
RGBA+metadata --> PNG --> file
Note that for our file format, this would become:
file --> PNG --> RGBA+metadata --> RGBA --> screen / print
RGBA+metadata --> PNG --> file
Beyond the time vs. space tradeoffs mentioned above, I think that the net
effect of this would be to speed up import of non-PNG content (from other
file formats) at the potential cost of slowing down export of our file
format (to re-encode the PNGs).
6. #5 is all about the tradeoff of various in-memory representations of
raster images. I suppose there'd be a corresponding tradeoff for vector
images. Something like SVG vs. an editable draw list of GR_Graphics
primitives. But hey, let's cross that bridge when we come to it. It's
certainly not a 1.0 issue, for instance.
7. All other embedded content (ie, not images) has an associated PNG or SVG
preview that can be displayed on platforms which can't edit and render the
associated content. [B]
open issues
-----------
My sense of the extremely lengthy discussion over the last 24 hours is that
we have rough consensus on most, and perhaps all, of #1-7 above. The
specific details which may still need to be resolved now include:
- whether to make JPEG native, too (#1)
- which XP solution to use on crippled systems (#3)
- whether to be PNG-centric or RGBA-centric (#5)
Have I left anything out?
Finally, of course, we'll need to nail down the specific interfaces we'll
use to address all these issues. However, once we've got full consensus on
the intended design, the APIs should be easy.
net effect
----------
If we have consensus on the above, then we have a solution which has the
following nice property.
Say someone builds a new settop box (a la WebTV or TiVO) and wants to add
word processing support, because it allows them to upsell their existing
customers to a premium service (at $24.95 a month instead of $19.95) which
requires the new settop with a hard drive and a printer port.
On that box, there's only one image format: some custom TV-specific mess
that they use to make everything look good on-screen. To implement a
version of AbiWord with *full* interoperability with every other AbiWord
user on the planet, they need to add the following imaging support:
- libpng
- libsvg (or the equivalent)
- their GR_<os>Graphics
- their proprietary graphics format
Bingo. Now your grandmother can read and print the family newsletter you
emailed her even if your clipart started out as XPMs or TIFFs. The fonts
will be remapped to something TV-friendly, and all other embedded content
won't be editable ... the Visio module for that settop won't be available
until next year at the earliest ;-) ... but the entire document is usable.
She can even add her own stories to the newsletter and then mail it back to
you.
Voila! All of the embedded content you added is still intact. If the folks
doing that port do their job right, so are your fonts.
Better yet. She can include a screenshot of AbiWord running on her TV in
the document, and *you* can read it, even though that image started out in
some weird TV-specific format that nobody else supports -- not IM, not
gdk-pixbuf, not even anywhere else in AbiWord.
Pretty cool, huh?
Paul,
whose grandmother *does* use WebTV
[A] This is the switching mechanism I've been talking about, so I'll go dig
through the archives so we can discuss that intelligently.
[B] Again, sounds like it's time for me to dig out those details from prior
embedding discussions in the archives.
This archive was generated by hypermail 2b25 : Fri Apr 20 2001 - 12:42:32 CDT