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

 I have now rebuilt the ft2-demo rpm ( github.com/FontVal-extras/binary-archive/) against m118. There is no change to the ft2-demo patch between m117 and m118. There was a small difference between m116 and m117 - headers are more separate and no longer includes related ones so there were two additional lines of includes from m116 and m117.
I just checked - the header moved I mentioned was between m110 and m116. One particular header had moved within skia.
I realised I actually haven't uploaded the m117 version of the diff (since I am really using the COLRv1 diff which is a larger one). I shall do that now and also put a symlink to m118 too, since it is identical.
    On Thursday, 28 September 2023 at 13:30:42 BST, Hin-Tak Leung <[email protected]> wrote:  
 
  The answer to the first question, as a whole, is no. Skia people don't guarantee anything. Skia is always statically linked to google chrome for that reason; shared library builds are there as is but not really supported. That said, the ft2-demos skia-port code use very little of skia, and doesn't change since m103 AFAIC.
The skia build result is more or less stable. I'd say you give it a try. The shared libraries get deposited at out/Shared/ (configurable and can be out of tree), and includes are in include/ and modules/ , both relative to the bottom skia/ directory. 
I would suggest getting rsvg-ports.[ch] (and rsvg/cairo) working with ftinspect first. The bridge interface is all the same - it is just what the actual "hooks" passed to FT_Set_Properties() is different.
The mention of skia-python is just to say what's the busy part is... out of the ~2400 API of skia, skia-port only uses 10 to 20. Well, actually I have an exact answer:
nm -D -C /usr/bin/ftview | grep Sk | wc -l
is 35. That's inclusive of the COLRv1 code, which I have only posted the skia side changes so far. (The ft2-demos side is still too ugly, and I am not spending much time on it any time soon)
    On Thursday, 28 September 2023 at 09:10:38 BST, Charlie Jiang <[email protected]> wrote:  
 
 Hin-Tak,

Hello.

- About the Skia version issue, it would be extreme concerning if every 
time Skia releases a new version, the bridge code has to be changed... 
Is there any degree of stability guaranteed for SVG-related interfaces 
(header files, class/method/function names...)?

- About the build system, is the directory structure of results from 
Skia's gn build system and prebuilt Skia binaries stable? If so, we can 
use something like `FindSkia.cmake` to locate the libraries and include 
directories required to compile against Skia from a simple `SKIA_DIR` 
CMake or Meson variable.

- About skia-python, I'm not planning to introduce skia-python or 
freetype-py... Since ftinspect is a pure C++ project, I wonder if any 
Python part is required to incorporate Skia into ftinspect. Glad to know 
that Skia won't cause circular dependency.

Charlie Jiang