>> Not for this case, as far as I can see.  The code to blend two
>> color layers as specified in COLR/CPAL is (currently) function
>> `tt_face_colr_blend_layer'.
> 
> I strongly suggest that this is removed.  Linear blending is bad
> anyway.  We should just provide coverage maps for each layer
> (including MONO and LCD optimized ones) and let client libraries
> with good gamma-corrected blending do the final assembly job.  We
> stayed away from blending and should continue to do so.

Mhmm, I disagree.  I think that FreeType should provide a single, most
basic solution for convenience – it's really just a few lines of code.
This is also a wish from

  https://savannah.nongnu.org/bugs/?44689#comment22

I'm no expert in blending, so please help improve the code!  It should
do the right thing in a clean way, not necessarily as fast as
possible.

As you can see in the git, I've already added an interface to the
`COLR' table so that clients can extract the color layers for advanced
use.  For the basic use, I will move the blending part of
`tt_face_colr_blend_layer' to a separate, public function in
`ftbitmap.h'.


    Werner
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Reply via email to