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 <ht...@users.sourceforge.net> 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 <char...@chariri.moe> 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