>> 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 [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
