> > I added a "-s" command line option to both ftview and ftgrid to swap
> > rsvg out with skia and run the same binary twice, one with "-s" and
>.> one without, just to look at them side by side. Fixed the pixel
> positioning discrepancies. Patch posted online below
>.>
> >
https://github.com/HinTak/harfbuzz-python-demos/blob/master/skia-adventure/ft2-demos-skia-m110.diff> Very nice! Of course, it would be necessary to properly adjust the
> build support to find Skia the 'official' way before I can add this to
> the `freetype-demos` repository. Too bad that building Skia is so
> demanding.
Yes, that's completely understood. There are at least two problems of committing the diff as is - the use of prebuilt and unofficial binaries, and that skia is moving so fast (the patch has already bit-rotten between m110 and m116/main). Both of which can be solved by having skia as a git submodule and locking it at a particular state; then we have a 3rd problem, which is that building skia is a 1GB clone, which then wants to clone another 1GB+ of dependencies before starting. I'd like to give it a try eventually to trim it down, do shallow clones etc, later, maybe one cold winter holiday with nothing to do :-).
Since this is just adding a "-s" switch (and 100MB+ disk usage), I have rebuilt my system's ft2-demos to have the feature semi-permanently.
https://github.com/FontVal-extras/binary-archive/commit/8c7d17bc7423e4371e29ac7074ea6e8ec530cf98
One question, is c++ built libfreetype binary completely compatible? It seems the opposite is (c++ built ft2-demos can use c-built freetype) is. In fact I was running 2.13.1 c++ built ft2-demo against the system's c-built freetype 2.13.0 briefly, before I rebooted.
But I don't want to install the matching c++-built libfreetype (people thinking of grabbing my ft2-demos rpm - please DON'T grab the matching libfreetype one, take the one from the commit before that! The matching one is just a built-set for archive purpose...)
I am thinking of stuffing skia underneath for COLRv1 too. Added the COLRv1 detection python code to freetype-py yesterday.
Basically I am thinking of doing a
FT_Load_Glyph_Extended(face, glyph_id, flags) {
if (glyph_id not COLRv1)
return FT_Load_Glyph(....); /* pass it on */
... do stuff and fill in a color bitmap and it's size/offset..
}
Since ftgrid has only one FT_Load_Glyph() call (in fact most of ft2-demos are like that), this is the least intrusive way of adding it. It is actually mostly very similar to how the SVG renderer hook is done.
I think the SVG renderer hook is somewhat equivalent to this:
FT_Load_Glyph_Extended(face, glyph_id, flags) {
If (not SVG)
return FT_Load_Glyph();
If (svg_init() not yet run once)
run svg_init(); /* once ever */
svg_preset_slot();
if (flags without LOAD_RENDER)
return;
svg_render();
/* svg_free() is never used... */
}
Except svg_renderer() and svg_preset_slot() wants to keep some private state persisting and sharing between successive calls.
I actually like some part of skia better than cairo: skia objects are shared pointers and internally reference-counted, so they just go away when you stop using them. No need to do "cairo_destroy_context(ctx);" etc. In fact the Google folks extended some of freetype structs to automatically do that too, something like:
convenientFT_Face = unique_ptr<FT_FaceRec, <destructor_func>FT_Face_Done>();
So that "FT_Face_Done" is called automatically when "convenientFT_Face" goes out of scope.
Quite clever. If only skia is easier to build and use!
Hin-Tak