On Sunday, 16 July 2023 at 07:13:20 BST, Werner LEMBERG <w...@gnu.org> wrote: > > 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
