Re: gdk_pixbuf::xpm_image_save patch

[Hans Breuer <hans breuer org>]

At 15:23 29.10.00 -0500, Owen Taylor wrote:
>
>Hans Breuer <hans breuer org> writes:
>
>> the attached patch adds the ability to save xpms with gdk-pixbuf.
>> It also fixes some problems with the !USE_G_MODULE case and 
>> finally with the win32 build. 
>> 
>> >From ChangeLog:
>> 
>> 2000-10-29  Hans Breuer  <Hans Breuer Org>
>> 
>> 	* io-xpm.c : implement (gdk_pixbuf__xpm_image_save).
>> 	Added HAVE_UNISTD_H and HAVE_MKSTEMP conditions.
>> 
>> 	* gdk-pixbuf-io.c : add xpm->save to module functions.
>> 	Fix all function prototype macros for self contained
>> 	image handlers (!USE_G_MODULE). Files to save should
>> 	be opened in binary mode.
>> 
>> 	* io-tiff.c : add header for win32 build
>> 
>> 	* test-gdk-pixbuf.c : add test case for load and save
>> 	functions
>> 
>> 
>> Would it be ok to commit these changes to cvs?
>
>Hmm, it looks like you've done a lot of work here, so I feel
>bad about saying this, but I don't think we should have
>XPM saving.
>
Not so much, it's rather straightforward. At least on Win32 it would take
me more time to create XPMs by hand, if I need some for another ported Gtk
application ...

What about wrapping it with G_OS_WIN32 ?

Btw: could you comment on the other things the patch was adressing?

>The problem with saving XPMs is that XPM was never meant
>as a full-color image format; it was meant as an image
>format for limited palettes.
>
But at least on win32 there is currently no other way to create XPMs (afaik).
But having coded it I could as well put it in Gimp's XPM plug-in, which
obviously would have the same problem mentioned above, if used without
thinking ...

>Saving a full-color image as an XPM without quantizing to
>a small number of colors has a number of problems:
>
> - It is extremely inefficient
> - Some programs will die when presented with XPMs with
>   more than 256 colors
> - Many programs tend to allocate a colormap cell for 
>   XPM color, so the tendency is to eat the entire
>   colormap on a pseudo-color display.
>
>Plus XPM is a horribly inefficient format to begin with,
>and I don't think we should be encouraging people to create
>more XPM files.
>
But aren't XPMs used as general image resource format in every *ix program.
Do you think this would be replaced by inline PNGs in the near future?

As a compromise: if I arbitrary limit the number of colors to be saveable
(e.g. to 256), would it be acceptable than ?

Thanks for your fast response,

	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert