Subject: [README] Re: XP design for image support
From: Thomas Fletcher (thomasf@qnx.com)
Date: Fri Apr 20 2001 - 08:06:53 CDT
On Thu, 19 Apr 2001, Dom Lachowicz wrote:
> >But why not simply always /save/ PNGs or SVGs (perhaps JPEGs too, I can see
> >the case for that), but /load/ (from external graphics files) based on
> >platform-specific code (as I mistakenly thought the current design was
> >already doing)?
>
> Then why have anything but a PNG loader/renderer and a bunch of classes to
> convert foo->png? This is what i'm arguing against. I want to:
>
> Load type foo
> Render type foo
> Save type foo in my file format
>
> No conversions needed.
>
I am dead set against this solution. If you don't understand
why (based on the previous discussions about cross platform
interoperability and what I like to believe is common sense),
I'm sorry.
AbiWord should be able to do the following:
PNG --> onscreen platform specific renderable format
-This is built into AbiWord since PNG is the native format
-Every platform must support this, so at the least every
platform can import PNG images.
formatXXX --> onscreen platform specific renderable format
-Done by whatever system services your system provides.
-If your system doesn't offer any services, tough break
you can only import PNG images then (since it is supported
internally by AW).
onscreen platform specific renderable format --> PNG
-This is required because we need to be able to support
scaling and manipulation of the renderable format and
this scaling should be saved back to the file format.
-Additionally, since we support the platform specific
import of various file formats we need to convert them
to PNG so that other AW users can read them.
Then of course a similar system has to be done with SVG (which
I beleive we are going to adopt as our internal vector format)
but that case is trickier since you have to render an onscreen
raster format from the vector content so you may have to have
a translation of either
vectorformatXXX --> AW stored SVG --> onscreen format
-> Vector information preserved
vectorformatXXX --> onscreen format --> AW stored PNG
-> Vector information lost
This isn't as bad as it seems since most systems with translators
can actually translate between formats as well as to onscreen
formats. In any case it is a bit of a moot point right now
since our SVG support is still up in the air.
Doing this allows AbiWord to take advantage of local image
libraries where they are present in addition to maintaining
the ability of AbiWord users to pass documents back and forth
among one another without a loss of graphic content.
"But what if I pass around a Bonobo object ... they won't
get that so why treat images differently?"
- This is true, but this is also totally different. I can
embed images into my Word document and have them show up
on any other Word system/reader, assuming I didn't embed
the imaging program. I can't embed an excel spreadsheet
and be _guaranteed_ that the end user will see it.
"But what about fonts ... if I use a font that some other
user doesn't have then they won't see it so why treat images
differently?"
- This is also true, but we make a best effort where possible
to map "unkown fonts" to a font that is available on the
system so that while the formatting may get screwed up, at
least the document is readable (potentially). In fact we
already have issues with formatting since the glyph metrics
for TNR on QNX are different from Windows so acheiving a
perfect match is next to impossible.
---I hope that this will pull us all back to reality. Our framework is well set in place and IMHO just needs a bit of tweaking to allow the above to all happen properly (I think that it already does for the most part with the exception of the scaling -> saving). This way the import classes can be written to use system services for each platform and we just need to be able to have our importer classes handle that "ambiguity" ... perhaps by adding a platform specific directory to our already XP import/export stuff.
While generating some interesting discussion here, this thread seems to be degenerating a bit so I wanted to pull things back on track and lay down a simple, flexible, relatively efficient scheme.
Thomas ... Can you please all of the people all of the time? ------------------------------------------------------------- Thomas (toe-mah) Fletcher QNX Software Systems thomasf@qnx.com Neutrino Development Group (613)-591-0931 http://www.qnx.com/~thomasf
This archive was generated by hypermail 2b25 : Fri Apr 20 2001 - 08:06:45 CDT