M122 public

[HinTak]

This should passed CI. But there is no reason of merging/upgrading at the moment, since all it differs is in default fontmgr being emulated.

@kyamagu I am not sure what is the problem, but the "FontConfigInterface" is the one being used up to 121 and being moved to chrome, but it segfaults , and somehow the "fontconfig" one, which was not and is not used anywhere, works. If you have time I'd appreciate your thought, but probably don't spend too much time on it, since we have something that "works", and this shouldn't be merged yet.

[kyamagu]

@HinTak As far as I look, the SkFontConfigInterface::RefGlobal() calls a static instance, but this static instance must be instantiated somewhere. It seems Chromium initializes a font loader in multiple places.

  sk_sp<SkFontConfigInterface> fci(SkFontConfigInterface::RefGlobal());
  return fci ? SkFontMgr_New_FCI(std::move(fci)) : nullptr;

[HinTak]

I believe we were using this particular SkFontMgr::Factory() in m121 - https://github.com/google/skia/blob/chrome/m121/src/ports/SkFontMgr_FontConfigInterface_factory.cpp - there are multiple implementations, only one is linked in per platform.

@kyamagu yes, chrome seems to be also use fontconfig directly in multiple places too, independently of skia...

[HinTak]

RefGlobal() calls GetSingleton() , https://github.com/google/skia/blob/6cea26c3f3c16d9726b998dfc7d4eba8950f7211/src/ports/SkFontConfigInterface.cpp#L25 , https://github.com/google/skia/blob/main/src/ports/SkFontConfigInterface_direct_factory.cpp#L11 , https://github.com/google/skia/blob/main/src/ports/SkFontConfigInterface_direct.cpp#L496 I think... hmm, but that's a dead end?

[kyamagu]

The singleton object is static and instantiated here.
https://github.com/google/skia/blob/main/src/ports/SkFontConfigInterface_direct_factory.cpp#L11

The nullptr to FcConfig* is probably okay, as most fontconfig APIs seem to use the default FcConfig*. But maybe fontconfig needs FcInit() called somewhere.
https://www.freedesktop.org/software/fontconfig/fontconfig-devel/x103.html

[kyamagu]

Anyway, it is probably fine as long as SkFontMgr_New_FontConfig(nullptr) is working...

[HinTak]

The call chain is doing multiple std::move in the middle, so I am wondering if some of some of fontconfig internals gets out of scope at some point.

There is a curious breakage between 121 and 122 where for Mac os x, font(typeface("")) stops returning a "practically usable" font, and the glyph outlines come to none. Not surprising given the other recent changes, but that's a other reason not to merge this until 123 etc.

[HinTak]

I'll put "don't use empty font(typeface("")) on mac os x" in the readme.m122 - it isn't something upstream wants you to do (an "any font") so it is not surprising it stops working at some point. Possibly upstream removed a "LEGACY..." define somewhere.

[HinTak]

I have added an explict test for font(typeface("Times")) returns non-empty glyphs for 'abcde' since somehow font(typeface("")) returns 5 empty ones m122 . It is not a surprise change given the other general no-default/valid-but-empty-default elsewhere, but it is a not-useful one for general users, so having a choice that would put some non-empty glyphs out is nice.

[HinTak]

Last:
2084 passed, 98 skipped, 11 xfailed, 27 warnings

[HinTak]

@HinTak As far as I look, the SkFontConfigInterface::RefGlobal() calls a static instance, but this static instance must be instantiated somewhere. It seems Chromium initializes a font loader in multiple places.

  sk_sp<SkFontConfigInterface> fci(SkFontConfigInterface::RefGlobal());
  return fci ? SkFontMgr_New_FCI(std::move(fci)) : nullptr;

I am finding myself revisiting this issue with #214 - google actually had a skia+sdl2 example before m93, and trying to get it to work with m126, I have to do something similar - and found that it RefGobal and SkFontMgr_New_FCI does work there. There is of course a small difference - SDL2 itself must be using fontconfig somehow, so must have initialized it via SDL_Init. Maybe that's the missing part: maybe it would work without segfault if anything else is initialising fontconfig first. So one thing to try is maybe doing the same in some python code and see.