Subject: Re: XP design for image support
From: Hubert Figuiere (hfiguiere@teaser.fr)
Date: Fri Apr 20 2001 - 03:14:57 CDT
According to Dom Lachowicz <cinamod@hotmail.com>:
> >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
Yes
> Render type foo
Why not, but...
> Save type foo in my file format
Absolutely NO. I'm totally against this. Why ? See how a big mess it will be.
Take the example of RTF: picture format supported are PICT, WMF, DIB, BMP, JPEG,
PNG, TIFF, GIF, etc. Not really a few for an *interchange* format.
So we should onle save PNG, SVG and JPEG (I'm pushing hard for this).
When it comes to object embedding, any object embedded MUST include its last
representation, for display and printing purpose, in one of the 3 support
file format (most likely SVG).
> Possibly, if the native code has the ability to save as PNG/SVG. That's the
> one thing I'm not counting on. But even then, why have a renderer for
> anything more than PNG?
I think having renderer for all the 3 format we will support (given that it is
the case) is a requirement.
Note that except for SVG, it is easy to implement both as XP or platform native.
Hub
This archive was generated by hypermail 2b25 : Fri Apr 20 2001 - 03:15:21 CDT