Re: skia-enabled ft2-demos with ot-svg suport, updated to m125 and now on github.

[Hin-Tak Leung]

On Wednesday 8 May 2024 at 05:09:36 BST, Alexei Podtelezhnikov <apodtele@gmail.com> wrote:


> On Mon, May 6, 2024 at 2:27 PM Hin-Tak Leung

> <htl10@users.sourceforge.net> wrote:
> >
> > I have set up a repo for the skia ot-svg patch, updated it for skia m125 (out two weeks ago; skia-python m124 was released last week and there is a pull for m125), and set up github CI to build it against current freetype git head.
> >
> > https://github.com/HinTak/freetype2-demos-skia/


> Cool. Would you like this integrated into the main repo? You can
> probably judge better if skia or rsvg is a more direct approach.

> At the time those hooks were implemented I hated them because they are
> just an extra layer of calls into a generic FT_Renderer module. It is
> just a layer after layer of redirection so it seems. So I am for
> either the most direct or the most portable code.

The call stack via FT_Renderer indeed looks a bit convoluted... I wonder if it can be simplified - it would be useful perhaps extending it for COLRv1 also, since that's quite a lot of extra code (about ~1000 lines in skia, and depends on the rest of skia - so probably will be no less than that drawing bitmap raw ; Justin seems to have about 300 lines of python drawing code for each of 4 implementations).

The latest librsvg seems to fix the rendering issue I filed around m116, so Nabla looks okay now. svg-native-viewer still hasn't. For a while librsvg and skia seems to be at opposite ends - one has too little man power (incomplete/bugs don't get fixed), one has too much man power (unstable API, and only care about usage inside Chrome; compilation against non-chrome projects break every few months).

The long-term value of intergrating skia is probably in its having an actively maintained COLRv1 functionality. I have an additional diff with adds
FT_Load_Glyph_Extended(), FT_Glyph_To_Bitmap_Extended(), FT_Get_Color_Glyph_ClipBox_Extended() which do that counterparts without "_Extended()" for COLRv1. Currently it toggles and overwrites the svg allocations, but I'd like to separate them at some point, and do it in a different way, so that color fonts with only a cOLRv1 table (i.e. without svg table) works. Such fonts don't exist "in the wild", since google color fonts have both, and the webkit folks seem not to want to support COLRv1, while the google chrome folks don't want to support OT-SVG.

But before that, we probably want to get ft2-demos having its own ./configure (or cmake equivalent) first. It is a bit wierd that detection of librsvg happens at freetype's configure (and freetype itself has no use of librsvg), and CC= is also set there. I am a little uncomfortable using c++ compiled freetype as my system library, although c++ is a must for skia. (and svg-native-viewer too).

The new repo has 4 submodules (skia, svg-native-viewer, freetype2, freetype2-demo) and the CI is setup to try building them one after the other, so the little green tick next to the commit (after about 20 minutes of build time) indicates a specific combinations of 4 commits works. github CI seems to have a weird bug (filed already) where submodule referring to non-github git:// repo must points to its current HEAD, so that basically means whatever else I do to update, I must sync the freetype2, freetype2-demo submodule against savannah, or it would fail. (fortunate for you to have frequent c++ build test, I guess).

Last I heard somebody else was comtemplating getting freetype2-demos its own ./confgure or equivalent?

Hin-Tak