Subject: Re: Graphic Images
From: Paul Rohr (paul@abisource.com)
Date: Thu Apr 19 2001 - 21:29:55 CDT
At 09:06 PM 4/19/01 -0400, Dom Lachowicz wrote:
>Matthew Kirkwood wrote:
>>My take on this stuff is that it would clearly be great to
>>support as many image formats as possible, but I have an
>>absolute horror of the situation where I can, without
>>noticing, make a document on one platform which cannot be
>>loaded on another.
>
>It wouldn't be "un-loadable", it just runs the risk of being lossy. We are
>already @ this point WRT available fonts.
To be fair. As Tomas has been proving recently, the technology required to
get a particular font working on another system isn't that bad.
Avoidable loss due to something we *can* fix (namely profusion of image
formats) is a whole 'nother animal.
>>Borrowing Mr Rohr's hat for a minute, there's also the
>>issue that "native" support of these formats significantly
>>raises the bar for new platforms -- an otherwise complete
>>port would be unable to consider itself "done" until it
>>supported all image formats.
>
>I don't see this as a problem.
>
>1) What new ports are we going to add *right now*?
>
>2) Platform parity is a nice goal, but it isn't 100% true even now, the time
>I'm assuming that you mean all platforms are relatively equal. Everything is
>always in various stages of "completement." It all comes down to how much
>we're willing to allow to slide/get added on certain platforms and why we
>allow this to happen.
But why raise the bar like this when there's simply no need? Just store PNG
for all raster images and we've ducked the bullet.
>> > 3) Just not support GIF, JPEG, TIFF, XPM, XBM, etc... This is
>> > absolutely horrible.
>>
>>The alternative isn't a lot better -- it adds significant
>>complexity (though not on the surface) to the file format,
>>and raises the bar for new ports/platforms.
>
>I fail to see why. One the surface, we would see:
>
><d mimetype="image/png"> -> <d mimetype="image/tiff">
>
>Which doesn't look all too complex to me. Underneath, all we have is
>basically the same as for our current importers/exporters:
>
>recognizeSuffix
>recognizeContents
>recognizeMimeType
>
>Again, not terribly difficult. Use some shared lib to draw to the screen
>(ala GdkPixbuf, IM, QuickTime, OS primitives) and you're home free.
You have to have all that code on all those platforms. That's a big
assumption and expense, especially since we don't need to do so.
In essence you're proposing that we ship and support a greatest common
denominator, instead of just exporting the least common denominator to our
file format to make it easier on ourselves.
I don't want to ship XPM code on Windows just because an AbiWord user on
Unix saved a copy of one in a file format *we* designed. Ick.
>>With that the way it is, it would be easy to get into a state
>>where the file format and common (or even all) platforms
>>supported TIFF images. But we might easily find that an
>>ImageMagick-based importer could load (and thus save, or at
>>least copy to file format) an image which any gdk-pixbuf (or
>>Imlib, or ..)-based one couldn't.
>
>The file format would be common. How well do we want to integrate with our
>host platforms and are we willing to sacrifice some extra effort to do so?
I'll freely admit that I have absolutely no idea what you mean here. :-)
I'll try again tomorrow.
Paul
This archive was generated by hypermail 2b25 : Thu Apr 19 2001 - 21:22:22 CDT