[MPEG-OTSPEC] Chrominum patches for OT-SVG Re: Future of OT-SVG (Re: Scheduling Zoom meeting to discuss new proposals and AHG recommendations)

[Hin-Tak Leung]

 Happy holidays.
After the skia/skia-python OT-SVG addition, I looked for simple way of patching and rebuilding chromium/chrome, but got into a bit of a dead end with building chrome from source... anyway, then I found that the QT folks switched from webkit to webengine (a fork of  chromium) between qt4 to qt5, and it is buildable from source on github CI for about 5.5 hours (just under github's 6 hours limit) at 4x core, with about 17 GB of disk space.
And they track chrome/chromium changes quite closely too. The upcoming qt 6.7 uses m118 (current is 121/122, so it is about 3 to 5 months old chrome code).
Anyway, the patches are posted athttps://github.com/HinTak/Qt6WE-OT-SVG
together with the CI yaml to build it for linux. And visiting 
https://pixelambacht.nl/chromacheck

with the parched qt6.7 beta1 webengine works.
The patch set is logically in 3 parts - besides the two I outlined: make freetype process OT-SVG font with skia's SVG module, divert font formats not native to non-linux to use a bundled freetype (this is already done for sbix on windows and colr for mac, and for CBDT for both), there is a 3rd - getting the bundled ots to let ot-svg web fonts through. So I posted it in two files, the first and the last in patch 1 and the 2nd in patch 2.
(Basically patch 1 makes it works on Linux, patch 2 has no effect on Linux as you get freetype or freetype on Linux...).
I'll probably try to get the QT folks to take the patches... obviously this is no news to Google folks - they just choose to not switch OT-SVG support on :-).

    On Tuesday, 5 December 2023 at 07:39:07 GMT, Hin-Tak Leung <htl10 at users.sourceforge.net> wrote:  
 
  Dear mpsuzuki, and others,

Slightly beating a dead horse - most of the following info (with further details) is posted at the end of
https://bugs.chromium.org/p/chromium/issues/detail?id=306078

- Google folks did add OT-SVG support to skia for freetype/directwrite-based systems (i.e. linux/android and windosws) in m103, but left it off. You need to add one extra line of code at the start of your application to switch it on.

- Variants of chrome browser includes blink, which in-term includes skia. Blink has the ability to configure skia to use freetype on mac/windows instead of mac' coretext or windows directwrite to load fonts. This enables chrome on mac to load COLRv0 and CBDT/CBLC color fonts, and chrome on windows to load sbix color fonts, which the "native" font loader does not support.

Both of these are included in the next skia-python, m120 ( https://github.com/kyamagu/skia-python) - should be out as soon as I can tag it to build/publish. I can't confirm that the directwrite OT-SVG code works, but loading OT-SVG via freetype on windows does. Would appreciate some windows users having a try.

So maintainers/packagers of chrome variants - it should be just one additional line to support OT-SVG fonts on freetype-based system (i.e linux). On windows/directwrite, I can't confirm that single line works, but freetype is already used as fallback for COLRv0 and CBDT/CBLC on mac, and for sbix on windows, and it shouldn't be hard to do the same thing for OT-SVG for non-linux.

Regards,
Hin-Tak

P.S. Here is the top part of skia-python m120's release notes - yes, I created the pull so I wrote this myself:

New in m120:

* Rudimentary support (TextBlob::MakeFromShapedText) of text-shaping via
 upstream's libSkShaper module. Intially this was added to support
 emoji's with skin-tone modifiers (#195), but has the fortunate side-effect
 that now LTR languages (Arabic, Hebrew, Tibetan ...) work as desired in
 skia-python's drawing. Note libSkShaper is buggy on windows.
 ( https://issues.skia.org/issues/310510988 )

* Option to use freetype as fontmgr on non-linux (#213) - using
 skia.FontMgr.New_Custom_Empty() (upstream's SkFontMgr_New_Custom_Empty).
 This allows Windows/Mac users to use some font formats not supported by
 DirectWrite/CoreText (see #195); and also work around bug in CoreText (#138,
 https://issues.skia.org/310510989 ).

* OT-SVG font support is on by default now (#212, also see #195).

* Vulkan is enabled for Linux/Windows. Most of the APIs were in m87 (stubs?)
 but were made optional in m98+, and dependent on GPU backend compiled in.
 For Mac OS X users, upstream removed MoltenVK support in m83, and recommend
 using Metal backend (TODO).

     On Friday, 14 July 2023 at 02:43:44 BST, suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp> wrote:  
 
 Dear Hin-Tak,

The Google Chrome m103, the web browser released on the late 2022-06
( https://chromium.googlesource.com/chromium/src/+log/103.0.5060.53..103.0.5060.66?pretty=fuller&n=10000 ),
supported OT-SVG?

According to https://bugs.chromium.org/p/chromium/issues/detail?id=306078 ,
a feature request for OT-SVG support was closed as "wont fix" on 2021.

My Google Chrome 114 reports "OpenType-SVG is not supported" on
https://pixelambacht.nl/chromacheck/ , it sounds consistent with the
status of this feature request.

However, although this feature request was closed, some people still post
some comments.

Regards,
mpsuzuki

On 2023/07/14 1:59, Hin-Tak Leung wrote:
> I see the future of OT-SVG as falling into half-half. There are technical/implementation details, but also overall strategies and decisions from stakeholders. One glaring(?) aspect is certainly that Google's  chrome team supports COLRv1 (not yet a OFF spec) in m98, earlier than OT-SVG (in 4th edition in 2019) in chrome m103...
  _______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20231224/f84a40de/attachment.html>