Re: Implementing Skia OT-SVG hook bridge in ftinspect?

[Hin-Tak Leung]

A few things...

- skia-port.[ch] isn't the only OT-SVG bridge - it is better than rsvg-port.[ch] (rsvg/cairo-based) in skia's svg processing is more complete. but rsvg-port.[ch] are already in.

- skia has a 4-6 week release cycle. I started with m116; m117 didn't change much as far as the bridge code is concerned (I think one upstream header has moved location). Most of the questions about building skia is answered by the shell-script in https://github.com/HinTak/skia-building-fun/ - it takes one argument, the branch name (m116, m117, m118, etc, but also m87, m88 for some of the older ones I tested), and build a zip files with shared libraries and headers. You unzip into a skia/ sub-directory of ft2-demos/ to build . So the building of the skia shared-libraries and ft2-demos are completely separate.

This is how I build https://github.com/FontVal-extras/binary-archive/ these days - the "source" rpm has an extra zip file with that skia binary bundle, build ft2-demos with them, then packaged those shared libraries in system locations as well as the ft2-demos binaries as rpms.

- I would advise against adding meson files. Skia is moving too fast and another bolted-on build system would bit-rot very fast. Other than the shell script in https://github.com/HinTak/skia-building-fun/, I would take some tips from scripts/build_Linux.sh of skia-python, to build gn from source. That way, you build gn, requires ninja, and (look at the shell script), fetch about 5 git repo on-the-fly, and you can build skia in about 20 minutes with 300MB disk space needed. If you really want to disable network access while building, grab and snapshot those 5 repo's. The 5 is listed in one of the patches in https://github.com/HinTak/skia-building-fun/ .

- yes, there is extra dependencies. But so has harfbuzz <-> freetype, etc. It is not exactly circular in this case: ft2-demos depends on skia depending on libfreetype (and libjpeg, fontconfig, etc), and also directly on libfreetype.

- I haven't looked at ftinspect, but for most freetype-dependent programs, it is just

#include "rsvg-ports.h" // or "skia-port.h"

FT_Property_Set( handle->library, "ot-svg", "svg-hooks", &rsvg_hooks ); // or one of the others

before you do FT_Load_Glyph(...) . This is done in ftview and also in ftgrid (or I added it in the patch?).

- the python equivalent is the similar, any freetype-py dependent python scripts,

from otsvg import hooks

library = get_handle()
FT_Property_Set( library, b"ot-svg", b"svg-hooks", byref(hooks) )

In https://github.com/HinTak/harfbuzz-python-demos/ , "hb-view-ot-svg.py" is the rsvg-based example. "hb-view-ot-svg-skia-GL.py" is the skia openGL example.


I haven't built m118 for https://github.com/FontVal-extras/binary-archive/ yet - mostly just time. AFAIK the skia-based bridge code is stable and expect not to change much across skia versions. skia-python is a bit more of a pain. skia-python covers about half of skia, and with skia changing so fast, skia-python is getting broken every month, if you try to follow skia's release cycle in skia-python :-(.

If you want to quantify, the last time I counted, freetype has about ~220 (?) public routines. freetype-py exposes about half to 70% of those. Skia has about 2400 public routines; skia-python m87 expose over 1000 - it is a bit difficult to count as skia-python uses dynamic casts, so dependencies don't show up at link-time. about 200 (or 20%) were broken in m116 initially, between m87 to m116 (29 releases, or about 3 years) . I think it is down to about 100 broken at the moment in m117b3, just out.

On Wednesday, 27 September 2023 at 02:55:41 BST, Charlie Jiang <chariri@chariri.moe> wrote:

Hi Hin-Tak, Werner and other folks,

The recent posts from Hin-Tak provided us promising insights in

implementing OT-SVG hook bridges in calling programs. I wonder if the

current status of Skia hook is approriate for being incorporating into

ftinspect. My considerations are:

- Maturity of bridge code (namely, skia-port.[ch]): Are they performing

well enough for a (experimental) integration? Do they work stably across

Skia versions? I'm seeing different patches for different Skia versions;

- Building Skia: Skia is built using tools (e.g. gn) completely

different from what we're using for building ftinspect (CMake and

Meson). I plan to not directly include the commands to build Skia into

the ftinspect build system, but to ask user to provide Skia library

paths. However, I'm concerned that Skia depends on (possibly another

build of) freetype, which may cause conflict. Maybe Hin-Tak have some

tips on handling this correctly?

If done, I plan to flag this feature as experimental and optional

(default disabled, enable in build system). However, I may lack the

resources and experise to test the code thoroughly, so I wonder if

Hin-Tak could help.

BTW @Hin-Tak, The Qt6 support for ftinspect has almost completely not

been worked on, I just wrote the conditional compilation (specifically,

code about `QTextCodec`) because I learnt that `QTextCodec` was

deprecated in Qt6, and that's the only part I've considered about Qt6.

Therefore, further work is definitely required to ensure the whole

program works on Qt6. Sorry for the confusion.

Best regards,

Charlie Jiang