Wed 09 Aug 2017 11:10:54 PM UTC, comment #15:
I did a more thorough review:
- I don't think FT_GlyphSlotRec can change. You should put your FT_Colr_Internal inside FT_Slot_Internal,
- ttcolr.h header still says ttsbit.h; maybe other places as well,
- I don't see how clients can get the layer info, as FT_Colr_Internal is private, and I don't see any getter API. Am I missing something?
- I'm also unsure about blending, even though I was the one who proposed it initially. That said, I think there's value in it, given that practically all emoji fonts will be using color-only glyphs...
|
Wed 20 Apr 2016 09:06:18 PM UTC, comment #14:
Shao, any update on this?
Thanks,
behdad
(Can't seem to log in right now)
|
Fri 08 Jan 2016 12:38:09 AM UTC, comment #13:
Thanks Ben for the review. I see the blended version as a fallback implementation, for smaller clients who don't want to load the layers and do their own blending. The sRGB vs linear is a bug and should be fixed.
behdad
|
Thu 07 Jan 2016 11:14:51 PM UTC, comment #12:
Note that the proposed tt_face_colr_blend_layer is problematic. FreeType has avoided so far any color blending, and for good reason. For example, the blend being proposed is incorrect, since the colors are specified in sRGB (the proposed blend is linear). Also, by providing the blend here, the issue of the 0xFFFF color needs to be addressed.
|
Mon 04 Jan 2016 05:44:57 PM UTC, comment #11:
Thanks for the review.
I'll make the changes.
|
Sat 02 Jan 2016 12:39:46 PM UTC, comment #10:
Hi Shao,
I checked the patch I like your approach of keeping regular outline next to the color layers. A couple of things:
- Might have been better to not load the entire colr/cpal tables and just peek through the as needed, but that can be done as an optimization later,
- Make sure it's easy enough for clients to access the layers and color directly if they choose to,
- The foreground color issue can be fixed at a later time,
- I don't think we need to worry about your example of transform changing between load and render time. I don't think that's supported.
Cheers,
behdad
|
Mon 30 Nov 2015 09:53:01 PM UTC, comment #9:
I initially thought that the transform step in FT_Load_Glyph (about ftobjs.c:855) would morph the image. But it's a false alarm.
if ( ( load_flags & FT_LOAD_IGNORE_TRANSFORM ) == 0 )
The thought process led me to suspect that the glyph's size and shape can be modified due to this transform. So it might be possible to do the following:
FT_Load_Glyph(face, glyph_index, load_flags);
FT_Get_Glyph(face->glyph, glyph_slot);
FT_Set_Transform(face, new_transform, new_delta);
FT_Render_Glyph(glyph_slot, FT_RENDER_MODE_NORMAL)
// Now render glyph for color vector will use the the new transform
// and rasterize into an image different than the previous transform?
Hopefully there's no other mutable state that I'm not aware of.
|
Thu 26 Nov 2015 06:03:43 PM UTC, comment #8:
Very nice, thanks! I'll check this in after the next release.
Can you elaborate on your reservations, probably giving an example? I don't really understand what you are worried about.
|
Wed 25 Nov 2015 10:40:48 PM UTC, comment #7:
Hello,
Here is my attempt at this. I hope you guys like it.
https://github.com/ShaoYuZhang/freetype/commit/27d9e6f6012b55d4001c33e3d46f6814c94ebc0d
I started hacking on this a little independently from Behdad, and followed roughly the same line of thought. I borrowed the FT_Load_Glyph technique from Behdad.
My biggest reservation to the current diff is loading subglyph outlines during FT_Render_Glyph. It works for me so far but I suspect there may be state change with other APIs that cause final raster to differ from loading subglyph outline during FT_Load_Glyph?
|
Mon 26 Oct 2015 11:05:48 PM UTC, comment #6:
I did a proof-of-concept two years ago. That's here:
https://github.com/behdad/freetype/commit/d23a43dac26f34aa7cdaec9cfd81211298b0b5de
Note that a proper implementation needs to augment glyph formats. Here's a start:
https://github.com/behdad/freetype/commit/5e9023eabf916198a912244d5fef89b54096fda1
|
Sat 24 Oct 2015 08:22:11 AM UTC, comment #5:
Great, I think Gecko’s implementation can be ported into FreeType.
|
Wed 07 Oct 2015 07:11:08 AM UTC, comment #4:
For reference, Gecko’s implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=889401
|
Tue 07 Apr 2015 05:02:24 AM UTC, comment #3:
Great!
|
Mon 06 Apr 2015 11:20:16 PM UTC, comment #2:
Will get to it, eventually. :)
|
Thu 02 Apr 2015 01:36:12 PM UTC, comment #1:
I'm CCing Behdad :-)
|
Wed 01 Apr 2015 03:01:03 PM UTC, original submission:
After supporting Google’s way to do emoji (embedded PNGs in font files), it would be interesting to support Microsoft’s way (layered color fonts).
References for this:
A layered color font is a standard TrueType/OpenType, with standard monochrome glyphs as a fallback. Additional glyphs are used for each layer of the color version of every character.
There are two additional tables: CPAL for defining one or more color palettes. COLR to link the glyphs together as layers and pick their color.
Implementations:
|