Re: gdk_pixbuf::xpm_image_save patch

[Owen Taylor <otaylor redhat com>]

Hans Breuer <hans breuer org> writes:

> >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 ?

Definitely not - there is no reason it should be win32 specific,
and our goal should be to reduce inter-platform dependencies
as much as possible.
 
> Btw: could you comment on the other things the patch was adressing?

 - The module prototypes changes are fine.

 - As far as mkstemp goes, I think the strategy I discussed with
   Tor was to add a g_mkstemp function in glib.

 - The HAVE_UNISTD conditional and the inclusion of io.h look  
   OK, though it might be nice to identify what unistd.h
   was being included for as a comment next to it so we can
   see why it doesn't need to be included everywhere.

 - The file open mode changes are probably OK; fopen (..., "rb")
   is standard ANSI unlike the horror of O_BINARY.

I think that was all the other changes - if you make a patch
with just those and not the saving patch, it might be useful.
 
> >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 ...

The GIMP's XPM plugin does handle saving. It does have the same
problem as mentioned above, but it at least gives the person
some more flexibility in using it.

So this should be a good option on win32. I'm pretty certain
that some of the other image manipulation suites such as
netpbm have been ported to Win32 or at least to djgpp
or cygwin, though using command line utilities without
a real shell isn't that much fun.

The goal of adding saving to gdk-pixbuf is not to give it enough
capabilities of something like the GIMP, but rather to allow
programs that need to incidentally save an image or two to
do so simply.

I don't think the XPM format is really suitable for this
sort of black-box, forget-about-the-details saving.

> >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?

In GTK+-2.0, we have a special inline-rgb format and a utility
for creating these files; this probably will be the standard
for small images. (It isn't especially space-efficient, but
better than XPM and allows storing the image data in the 
read-only/shared storage)

For bigger images, inline or out-of-line
 
> As a compromise: if I arbitrary limit the number of colors to be saveable
> (e.g. to 256), would it be acceptable than ?

I don't think so - it would just make it more confusing for the
user.

Regards,
                                        Owen