[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] color framework
From: |
Alexei Podtelezhnikov |
Subject: |
Re: [ft-devel] color framework |
Date: |
Wed, 19 Dec 2018 05:43:09 -0500 |
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.
- Re: [ft-devel] color framework, (continued)
- Re: [ft-devel] color framework, Behdad Esfahbod, 2018/12/17
- Re: [ft-devel] color framework, Werner LEMBERG, 2018/12/18
- Re: [ft-devel] color framework, armin, 2018/12/18
- Re: [ft-devel] color framework, Werner LEMBERG, 2018/12/18
- Re: [ft-devel] [SPAM] Re: color framework, armin, 2018/12/18
- Re: [ft-devel] [SPAM] Re: color framework, Werner LEMBERG, 2018/12/18
- Re: [ft-devel] color framework, Behdad Esfahbod, 2018/12/19
- Re: [ft-devel] color framework, Werner LEMBERG, 2018/12/18
- Re: [ft-devel] color framework, Alexei Podtelezhnikov, 2018/12/18
- Re: [ft-devel] color framework, Werner LEMBERG, 2018/12/19
- Re: [ft-devel] color framework,
Alexei Podtelezhnikov <=
- Re: [ft-devel] color framework, Behdad Esfahbod, 2018/12/19
- Re: [ft-devel] color framework, Alexei Podtelezhnikov, 2018/12/19
- Re: [ft-devel] color framework, Behdad Esfahbod, 2018/12/19
- Re: [ft-devel] color framework, Alexei Podtelezhnikov, 2018/12/19
- Re: [ft-devel] color framework, Werner LEMBERG, 2018/12/13