Subject: Re: Graphic Images
From: Hubert Figuiere (hfiguiere@teaser.fr)
Date: Thu Apr 19 2001 - 15:31:10 CDT
On jeudi, avril 19, 2001, at 10:17 , Dom Lachowicz wrote:
>> I'm convinced it is. We should support internally 3 image format. SVG
>> for vectors, PNG for bitmaps, and JPEG for JPEG and arbitarly other
>> lossy compression format. (yeah, it is a real waste to store JPEG as
>> something else than JPEG).
>
> I'm not seeing the argument for JPEG here. Is the argument here that
> storing a JPEG as a PNG will take up a few extra bytes?
A few is an oximoron IMHO. That can be up to 10x the size in PNG. That
is really the justification of JPEG.
>>> 2) Use IM or some other lib to convert FOO->PNG. This kind-of sucks
>>> because of the various overheads needed for the translation. Plus we
>>> presumably could use this lib to render stuff to screen instead.
>>
>> This is the easiest way as the ABW file format, that will contains such
>> images, will stay simple and limit itself to 3 image format. Have a
>> look
>> at the mess of RTF and Word. To fully support them, we need to support
>> PICT, WMF, DIB, BMP, JPEG, GIF, PNG, etc. That is a real pain. In the 3
>> format mentionned, handling the last 2 of them (PNG and JPEG) will be
>> walk in the park given the fact that JPEGLib and libpng does the stuff,
>> and that the various platform even have built in renderers (see
>> gdk-pixbuf). SVG must be supported as XP, but more on this later.
>> Conversion is done once (or twice, because of the preview in the open
>> file dialog). That's all. Once imported it is in one of the 3
>> internally
>> supported format that we know how to handle. Period.
>
> #2 was the only option I was even going to consider. I don't see what's
> so hard about storing a GIF or XXX in our file format.
>
> <d mime-type="image/foo" ...>
It is NOT hard. It is just too much. Why for example keeping GIF while
PNG would store *exactly* the same image and make only one image format
to be handled instead of two. That is exactly the purpose of having only
one lossless bitmap image format used within our file format. This apply
to BMP, TIFF, XBM, XPM, etc.
> But IMHO we have a serious problem/issue that we're going to have to
> deal with embedded data in our file-format. No, I'm not just talking
> about OLE2/Bonobo, but images too. We might need a streams API or
> Embedded Filesystem concept. The way that we handle SVG in our file is
> interesting.
For SVG, perhaps can we use XML namespace ? (I'm not an XML wizard, feel
free to correct me).
For other things, I think that storing images as a base64 flow would be
a good compromise between bloat and compatibility. For OLE/Bonobo, I
request that there is a requirement to store the latest state of the
object as a picture (choose the best format, SVG coming on the first
row).
>> Nope. That is the reason of 2. Convert the image on entry, like we
>> ALREADY do for word processor. Yes, actually opening a file and saving
>> it as RTF is not a safe (ie lossless) process. Same for all the other.
>
> Converting the image on entry is the only way to go if we choose the #2
> route. I'm just seriously wondering why:
>
> 1) We wouldn't want to take advantage of system libs inside of an XP
> framework
No objection. Or XP is done to not be too XP-ish, ie not reinventing the
wheel for each byte.
> 2) We just don't embed data with a mime-type tag
Not a problem, but only 3 data type are allowed (see above)
> 3) We don't re-engineer a lot of our image framework. It seriously
> isn't "passing muster" here...
Yes definitely. Some other things need to be worked on too with the XP
stuff. But I'm get off topic. (more to come once I'd like to rant).
> And for the record, my GdkPixbuf work right now doesn't serve as
> anything more than a replacement for our libpng rendering code. It
> doesn't (but could easily) load other raster-graphics with a few
> modifications to XP code and design.
Why do you think I did fix it :-)
BTW, gr_UnixGnomeImage should not inherit from gr_UnixImage but from
gr_Image (or an abstract class should be in beetween), and
gr_UnixGraphics should not be aware of each of these class, reporting
the drawing to the image class....
(it currently calls itself drawing routines which is NOT a good idea
IMHO).
Hub
This archive was generated by hypermail 2b25 : Thu Apr 19 2001 - 15:31:05 CDT