|
From: | Behdad Esfahbod |
Subject: | Re: [ft-devel] completed CPAL/COLR support |
Date: | Sat, 30 Jun 2018 00:26:32 -0400 |
bThird, "palette[layer_color_index]" is recipe for invalid memory access. Let alone that it does not handle the foreground color magic number 0xFFFF.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.I haven't got time to fully review the API. But just taking a look now, in the example in freetype.h:First, I think the use of a FT_LayerIterator type is unnecessary. A single index could have done.
* 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 );
* }--On Sun, Jun 17, 2018 at 1:17 PM, Werner LEMBERG <address@hidden> 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
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype-devel
behdad
http://behdad.org/
[Prev in Thread] | Current Thread | [Next in Thread] |