bug#28400: 26.0.50; lcms2 bindings

[Eli Zaretskii]

> Date: Sun, 10 Sep 2017 18:04:22 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: 28400@debbugs.gnu.org
> 
> >Is it really so much better than what we have now to justify requiring
> >yet another library to build Emacs?  If it is, could you tell what are
> >the main advantages, or point to where those advantages are described?
> 
> It was just much easier for me to hack existing code than figure out adding
> a new file and the configure.ac business.  It would be much more
> sensible to offer it as an optional feature and expose color metrics as
> optional arguments, e.g.
> 
>   (color-distance COLOR1 COLOR2 &optional FRAME METRIC)
> 
> where METRIC accepts two colors and returns a number.

Oh, I see.  But in that case, I think adding a new file and the
configure.ac business is actually quite easy.  Search configure.ac for
"libz", and you will see a typical example: it involves adding a new
"--with-FOO" option to configure, and then some pretty boilerplate
code to test whether some tell-tale header file is present, and tweak
the compilation/linking flags accordingly.  The new file then should
have all of its body wrapped in "#ifdef HAVE_FOO..#endif", with only
config.h outside of that condition and maybe some simple predicate to
test for the feature existence; see xml.c for a good example.  Then
add that new file to src/Makefile.in, and you are pretty much done.

As for color-distance, did you intend to replace or provide a better
alternative to similar functions in color.el?

> >Btw, 256 colors is not "small" by Emacs standards, because our color
> >approximation should (and does) work in 8-color terminals as well.
> 
> Yes, I should have used a different word than "small".  Approximations
> for smaller palettes is easier because the differences between
> individual members of the palette are much bigger.  The 256 color
> palette (and larger) has many colors much closer to one another, and
> calculating perceptual differences between colors that are close
> requires a more sophisticated model.

So you are saying that tty-colors.el is too simplistic for ncolors
around 256?  If so, perhaps this optional feature could provide
compatible alternatives to that?

Thanks.