[MPEG-OTSPEC] Scheduling Zoom meeting to discuss new proposals and AHG recommendations

[Dominik Röttsches]

On Tue, Jul 4, 2023 at 3:06 PM Hin-Tak Leung <htl10 at users.sourceforge.net>
wrote:

> On Tuesday, 4 July 2023 at 17:18:30 GMT+8, Dominik Röttsches <
> drott at google.com> wrote:
>
> > COLRv1 rendering in Python exists in
> https://github.com/BlackFoundryCom/black-renderer - that's using
> fonttools for parsing, to my knowledge, not using FreeType, but you can
> probably take inspiration from the drawing backends of blackrenderer. Or
> then, potentially through pycairo if it has a recent cairo backing it. Or
> then https://pypi.org/project/skia-python/ - I haven't tested that and I
> don't know if that's built with FreeType in it, but if it is, it should
> support COLRv1 as well.
>
> Thanks. The black-renderer is the first one I found too, besides cairo. It
> is probably not hard to parse the fonts themselves, extract the bits and
> draw with it, but until freetype can load them via LOAD_RENDER (and its
> python equivalent) like it can with OT-SVG and COLRv0, COLRv1 is looking
> like limited to specific usage.
>

COLRv1 bridges the gap between font concepts and 2D graphics library
capabilities. From an architectural point of view, many COLRv1
implementations have chosen to leave the font parsing to a font library,
and perform the 2D graphics operations with the help of a typical 2D
graphics library. This is the case for the DirectWriteCore implementation
by Microsoft (DWriteCore + D2D), for blackrenderer (fonttools + cairo,
skia, svg), and for the backends we have in Skia (now 2, one based on
FreeType, one based on DirectWriteCore / Windows App SDK font parsing +
SkCanvas). I don't think it would be the right architectural choice to
redundantly repeat these concepts inside FreeType itself. Even more so, as
fast compositing and gradient implementations require time and effort to
make them reasonably fast.

It's true that color font support has thus higher requirements and usually
then needs to combine a font parser with a 2D graphics library to achieve
correct glyph rendering.

I may be wrong, but it seems that Freetype git HEAD cannot see COLRv1 glyph
> layers (yet).
>

I am not sure if that's what you mean by "see", but using
FT_Get_Color_Glyph_Paint
<https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/include/freetype/ftcolor.h#L1405>
it's
possible to traverse the Paint graph. COLRv1 is organized in a DAG, not
strictly in a list of a layers.

Dominik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20230704/2b861b59/attachment.html>