>> FT_LOAD_COLOR should trigger a standard case with some default
>> blending; for finer color and blending control separate functions
>> should be provided to allow direct layer access.
>
> Which [of] is these flags is spurious?
> FT_LOAD_COLOR | FT_LOAD_RENDER | FT_LOAD_TARGET_BGRA
>
> I am ok with assuming FT_LOAD_TARGET_BGRA if FT_LOAD_COLOR is set.
> FT_LOAD_RENDER should be explicit! It is absolutely crazy to
> enforce slow rendering unless explicitly asked for. FT_LOAD_COLOR
> should just merge all outlines/layers/contours and tag them with
> COLOR, of course. I am just warning. FT_LOAD_COLOR does not imply
> FT_LOAD_RENDER yet. Keep it this way.
Alexei, I think we miscommunicate. FT_LOAD_COLOR will *never* set
FT_LOAD_RENDER. How do you come to this impression? We are only
talking about the effect of FT_LOAD_COLOR on the rendering of
color-layered glyphs.
Actually, the current FreeType code *does* separate loading and
rendering. If you say
FT_Load_Glyph(... | FT_LOAD_COLOR);
FT_Render_Glyph(... FT_RENDER_MODE_NORMAL);
you get grayscale rendering of the normal outline. You must rather
say
FT_Load_Glyph(... | FT_LOAD_COLOR);
FT_Render_Glyph(..., FT_RENDER_MODE_NORMAL | FT_LOAD_COLOR);
to get a default blending of the color layers.
I consider this hacky. The main reason is that currently
FT_LOAD_COLOR makes FT_Load_Glyph load *both* the normal outline and
the colored-layered data. It would be better if this flag makes the
function load only a contours array with glyph color information so
that
FT_Render_Glyph(..., FT_RENDER_MODE_NORMAL)
automatically produces a BGRA bitmap. The definition of
FT_RENDER_MODE_NORMAL should be then changed to
Default render mode; it corresponds to 8-bit anti-aliased bitmaps
for normal outlines (FT_PIXEL_MODE_GRAY) and color bitmaps for
color-layered glyphs (FT_PIXEL_MODE_BGRA).
I think this is more user-friendly than introducing
FT_RENDER_MODE_BGRA. In other words, the presence of a `color' array
in the glyph slot makes the renderer select colour output.
Werner
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
