freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Hin-Tak Leung
Subject: Re: Implementing Skia OT-SVG hook bridge in ftinspect?
Date: Wed, 27 Sep 2023 19:43:58 +0000 (UTC)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]