I haven't got time to fully review the API. But just taking a look now, in
the example in freetype.h:
* if ( palette && layer_glyph_index )
* {
* do
* {
* FT_Color layer_color = palette[layer_color_index];
*
*
* // Load and render glyph `layer_glyph_index', then
* // blend resulting pixmap with previously created pixmaps.
*
* } while ( ( layer_glyph_index =
* FT_Get_Color_Glyph_Layer( face,
* glyph_index,
* &layer_color_index,
* &iterator ) ) != 0 );
* }
First, I think the use of a FT_LayerIterator type is unnecessary. A single
index could have done.
Second, the use of 0 return value to signify end of iteration is
problematic given that 0 is a valid glyph index that can appear in the
layers itself.
Third, "palette[layer_color_index]" is recipe for invalid memory access.
Let alone that it does not handle the foreground color magic number 0xFFFF.
b
On Sun, Jun 17, 2018 at 1:17 PM, Werner LEMBERG <[email protected]> wrote:
> >> the CPAL/COLR interface is now implemented and committed to git.
> >> However, it is still mainly untested; I'm working on it the next
> >> days – be warned that there might be issues.
> >
> > If I combine FT_LOAD_COLOR and FT_LOAD_TARGET_LCD, should I get LCD
> > optimized results with separate alpha used for each color channel?
>
> I don't understand the question. The BGRA format only supports a single
> alpha for the three color channels...
>
> > I would love to have FT_LOAD_COLOR_STRAIGHT for non-premultiplied
> > output.
>
> Do we really need that? Using `FT_Get_Color_Glyph_Layer' in
> combination with `FT_Palette_Select' you can easily extract the colors
> and do the blending appropriate blending function outside of FreeType.
>
>
> Werner
> _______________________________________________
> Freetype-devel mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>
--
behdad
http://behdad.org/
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
