Subject: Re: NO consensus!
From: Leonard Rosenthol (leonardr@lazerware.com)
Date: Sat Apr 21 2001 - 17:13:08 CDT
At 10:50 AM 4/20/2001 -0700, Paul Rohr wrote:
>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.
Not me! I think we can do a LOT better in terms of where the
XP/AP lines cross. I believe that the ONLY thing that should happen in AP
code is rendering an RGBA bitmap into platform space. All image format
loading, manipulation (scaling, etc.) should be done in XP code!! I don't
care whose code it is (IM, gdk-pixbuf, etc.) but I can't think of ANY GOOD
REASON to duplicate all that stuff for each platform. We already have too
much duplicated code, let's not add more!
>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.
That I agree with.
>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]
I can live with this IF the images are then loaded into an XP
buffer for later processing, so that the ONLY service we are using is image
import.
>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.
OK.
>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.
You lost me on this one...Care to explain?!?!
>5. We seriously consider Hub's suggestion to streamline the import /
>conversion process of raster images to be RGBA-centric instead of
>PNG-centric.
This is also what I am suggesting above!
>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.
True, but we'd also slow down rendering since it would have to
decompress each time it needs to update - and I think this is one case
where we can spare the memory in favor of performance (IMHO).
>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).
PNG writing is pretty fast and it's at a time where the user
doesn't mind a bit more time - as opposed to scrolling the document...
>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.
So you're suggesting we don't even bother with SVG till
post-1.0? Why? Hub, Dom and I have already shown that with ImageMagick we
can have it today (tomorrow?).
>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]
Agreed.
LDR
This archive was generated by hypermail 2b25 : Sat Apr 21 2001 - 19:48:09 CDT