Hi Werner, > 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.
Wonderful! > Alexei, I think we miscommunicate. I struggle to get your attention to FT_Glyph_To_Bitmap. > 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. Please do not oversimplify. FT_LOAD_COLOR is not passed but rather dug up from face->internal. Again. let's get rid of this hack for the sake of FT_Glyph abstraction. Perhaps, the *detached* FT_Glyph abstraction is useful for threading. > 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. FT_Render_Glyph used to be democratic. The renderers were chosen based on the match between the glyph format and the rendering mode. That was wonderful and agnostic. You suggest a different logic for BGRA mode. What is somebody wants to plug in an alternative (say PNG) renderer? Oops, we are going to make it hard for you. FT_Render_Glyph used to be democratic. The renderers were chosen based on the match between the glyph format and the rendering mode. The only way to keep it this way is either FT_RENDER_MODE_BGRA or FT_GLYPH_FORMAT_LAYERED. You know that I tried both. We are introducing new way or rendering (for FreeType) I do not see a problem with being open and transparent about it. _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
