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
