Mike Scheidler <c23mts(a)eng.delcoelect.com> writes:
> >> Why is XPM superiour to PNG? Cause it's plain text?
> Glynn> That's an advantage (IMHO), but the main issue for me is symbolic
> Glynn> colour names.
> I second Glynn's comments. The XPM format is great for things like toolbar
> icons because of the configurability that symbolic color names offer. I
> don't know much about the PNG format, but unless it has similar symbolic
> color capabilities, it would be a net loss, IMHO.
It can have. Cause PNG is the ability to add private tags, we could use this
feature to add symbolic names to a palette. This will *not* break the png for
'standart' PNG libs/viewers/converters, but XEmacs (who will know those tags)
can use them to change the colors.
If you (and the others) are interested in such an addition, here is a short
example how it will look like (I can also code this example, but first tell me
if you and the others will accept such an addition):
Each png image will have a standart PLTE (Palette; critical, public, unsafe to
copy) chunk. This will define the colors of the png image.
In addition there will be a syMN (Symbolic Names; uncritical, private, unsafe
to copy) chunk which lists color names mapped to pallette indicies. If the
docoder (XEmacs in our case) 'knows' syMn, he will try to change the symbolic
colors. In the case the chunk is not known, a viewer will ignore it without a
warning, but an editor which does not know it, will complain and don't copy
it, cause the image may change if the palette is changed.
A simple converter can do the job converting XPM to PNG and preserve the
symbolic names, but it is also an easy task to write an 'Palette Symbolic Name
Editor' which will give the 'programmer/painter' the ability to edit the
symbolic names of the palette (this is no workaround, cause currently there is
no drawing program which will let you edit such sym names -- you always have
to use an editor to do the job).
So we will have sym names and the advantage of having small image files in one