bug#28400: 26.0.50; lcms2 bindings

[Mark Oteiza <mvoteiza@udel.edu>]

On 11/09/17 at 06:01pm, Eli Zaretskii wrote:
> > 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.

Thanks, I'll attempt that.

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

That is a good question.  I've thought about it, but don't have a good
answer.  lcms2 could certainly replace some of the things in color.el,
but if it's an optional feature I guess there are a number of ways to
handle it.  If we include lcms2.c providing its own 'cms or 'lcms2
feature, I guess featurep'ing things wouldn't be so bad.

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

It will get some interesting results. For instance, asking Emacs for
#3d3535 (dark, slightly reddish grey) in a 256 color term will yield
#5f005f (color-53, a strong purple) instead of color-235 or color-236
(dark greys).  It does a good job overall, so I don't suggest changing
it.

> If so, perhaps this optional feature could provide
> compatible alternatives to that?

Sure, like the example above for color-distance, tty-colors-approximate
could expose an extra optional argument and/or respond to a variable.