Re: State of Text Rendering 2024
Hin-Tak Leung <[email protected]> Thu, 11 Jul 2024 20:52:10 +0000 (UTC)
| Newsgroups | gmane.comp.fonts.freetype.devel,gmane.comp.freedesktop.harfbuzz,gmane.comp.lib.cairo,gmane.comp.gnome.gtk+.devel.general |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_6652640_1120578133.1720731130414 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Behdad, for a very thorough if somewhat subjective and at times in= complete survey. I'll try to make 4 short comments, then expand on them. Please feel free to= TL;DR, at any point. 1. The mini "font war 2.0", between Google/Chrome and Webkit/Safari, on COL= Rv1 vs OT-SVG. There is a 10-year old "won't fix" https://issues.chromium.o= rg/40336440 on Chrome's SVG in OpenType support, despite Google actually ad= ded OT-SVG support in m103 about two years ago, but left it disabled. Webki= t/Safari folks has a couple of public statements stating they won't impleme= nt COLRv1, last I heard. 2. Skia/Chrome being the reference/practical implementation of COLRv1, cove= rage of various skia-related resources are perhaps lacking. For example, yo= u mentioned HarfBuzzSharp being part of dot net API, but you did not mentio= n that SkiaSharp pre-dates HarfBuzzSharp, and are AFAIK, maintained togethe= r by the same team: https://github.com/mono/SkiaSharp-API-docs (this contai= ns the HarfBuzzSharp API docs also), and https://docs.microsoft.com/dotnet/= api/skiasharp . I'll tell you more below, since I have been co-maintaining = skia-python for about a year now, and in fact the person who released the m= onthly update to skia-python, tracking skia's monthly releases, for the las= t 10+ releases, after it having been somewhat dormant at m87 for three year= s.=20 3. On font editors, there was a discussion between me and Georg of Glyphs, = and some initial investigation of the possibility of porting Glyphs to wind= ows via Microsoft's WinOBJC, and to Linux via OpenStep (the open-source clo= ne of NeXT, what Mac OS X started with two decades ago). Likewise, MS is no= t oppose to open-sourcing the whole of Visual Truetype GUI (minus the Apple= /Microsoft font scaler code), and I have approached Apple folks about the f= irst truetype font editor, RoyalT, from 35 years ago. Some of it depends on= FontVal-RX (https://github.com/FontVal-extras/FontVal-RX ), and what's pos= sibly the beginning of FreeType 3. FontVal-RX was supposed to happen two ye= ars ago, except I got really ill and was hospitalized for a bit, and during= my recuperation, distracted by skia-python. 4. another 10-year-and-still counting issue: https://github.com/fontforge/f= ontforge/issues/1534 - that fontforge cannot be used to manipulate Google N= oto / Adobe Source CJK fonts. I think it is worth mentioning, considering t= he role of fontforge and Google Noto / Adobe Source fonts. People who want to stop reading, should stop now... anyway. Further. 1. I submitted the one-line patch to qt - https://bugreports.qt.io/browse/Q= TBUG-120543 - to switch on OT-SVG support in qt-webengine (a folk of the ch= romium code). qt 6.7 was about 6 months behind at m118, the upcoming 6.8 is= still m118-based like 6.7. Current chrome is m127, although the QT folk se= ems to have a m122 based qt-webengine backend in dev, which means it is sti= ll about 6 months behind chome's. skia and chrome version numbering are in sync, and has a 4/6 weeks release = cycle, for those people who don't know. so m118 and m127 is roughly about 9= months to just over a year apart, without looking at precise dates. The way I see it, Google folk likely will spend time adding COLRv1 as a pat= ch, and submit that to the webkit folks. Whether they will take it, is anot= her matter. The one-line patch to enable OT-SVG is included in recent releases of skia-= python, since I co-maintain it. I can put random stuff in myself, within re= asons. BTW, I have left instruction to the project owner that if I disappea= r for extended time, and the COLRv1 addition to skia-python gets bit-rotten= , please just remove it. 2. SkiaSharp is at m116, which is after m98 (the COLRv1 entry point) and m1= 03 (the disabled OT-SVG support in skia/chrome). https://github.com/HinTak/skia-building-fun/ is a shell-script plus some pa= tches, to build current skia on linux in about 20 minutes using about 300MB= total disk requirement. The default / official instruction requires about = 9GB of disk spaces. https://github.com:HinTak/freetype2-demos-skia/ is a modification of freety= pe2-demos to use skia in addtion to cairo/rsvg (switching by a launch switc= h between the two) for OT-SVG rendering. There is a not-yet-public addition= on top of that to add COLRv1 viewing support to ft2-demos too. I consider = the COLRv1 addtion a bit too ugly to be posted at the moment, but the addit= ional COLRv1 patch is used to build https://github.com/FontVal-extras/binar= y-archive , the rpms of freetype demos and the modified freetype on my own = system. Grab both and set LD_LIBRARY_PATH etc to see it, if you want to. I'= ll add some notes, instructions at some point. TODO: submit one-line patch to SkiaSharp to enable OT-SVG support. 3. and 4. After working on FontVal for almost a decade now, I have come to = the realization that it is using the editor-like APIs in Apple/Microsoft's = font scaler (which does not exist in FreeType, and I spent 3 years adding p= artial bits of). Despite Microsoft claiming otherwise, the font scaler API = continue to be extremely similar - for example, it is possible to run FontV= al with Apple's font scaler instead of MS's, without any noticeable code ch= ange, and Apple's libFontValidation (and Apple's FontTool suite) can likewi= se inter-op with Microsoft's font scaler. And I realise that the Apple font= scaler having an accompanying font editor, RoyalT, since day one, was a ve= ry important part of its design. One frequent complaint of the current incarnation of FontVal is that, howev= er good it is, it does not reflect suitability of use for windows (or Mac O= S X) - that's just a harsh reality: a font validation tool must use the pla= tform's renderer, to have any authenticity of claiming suitability.=20 Likewise, font editors, at its final finishing stage, must use the platform= 's renderer for looking at the near-finished outcome. FontVal-RX is the project to detach FreeType (and make it an optional backe= nd), and re-enable the bridge to the Apple/Microsoft font-scaler. So I have= closed off https://github.com/HinTak/Font-Validator/ a few months ago, but= it should have happened about two years earlier. The potential outcome of FontVal-RX, is bringing Visual Truetype to open-so= urce (minus its fontscaler code), since it means making FreeType more Apple= /Microsoft font-scaler interface-similar. Plus porting Apple's libFontValid= ation, and Glyphs, among other possibilities. The original plan for FontVa-RX was an initial release about 18 months ago,= and reaching its ending goal (a modified FreeType having Apple/MS font-sca= le like APIs) around 2028. That didn't happen because I have fallen ill, an= d now distracted by skia-python. Skia-python itself would basically push Fo= ntVal-RX's ending goal date by another two years, to 2030. The time estimate is based on that fact that I can only justifiably spend x= amount of my time, uncompensated, in any period, on "hobbyist" pursuits. S= o spending time on skia-python means not spending time on FontVal-RX. And, = responding to flames, such as answering "why don't you do...." also cut int= o that time. So - please think before you comment, because responding to yo= ur comments also cut into that time share. Thanks for reading so far. And o= n the off-chance that somebody feel like funding me on portion of this, ple= ase get in touch. On Tuesday 9 July 2024 at 03:05:15 BST, Behdad Esfahbod <[email protected]>= wrote: Hi, I'd like to share with you the "State of Text Rendering 2024": =C2=A0=C2=A0https://behdad.org/text2024/ Feedback and comments are most welcome. Thanks, behdad http://behdad.org/ =20 ------=_Part_6652640_1120578133.1720731130414 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div> Thanks, Behdad, for a very thorough if somewhat subjec= tive and at times incomplete survey.<br><br>I'll try to make 4 short co= mments, then expand on them. Please feel free to TL;DR, at any point.<br><b= r>1. The mini "font war 2.0", between Google/Chrome and Webkit/Sa= fari, on COLRv1 vs OT-SVG. There is a 10-year old "won't fix"= https://issues.chromium.org/40336440 on Chrome's SVG in OpenType suppo= rt, despite Google actually added OT-SVG support in m103 about two years ag= o, but left it disabled. Webkit/Safari folks has a couple of public stateme= nts stating they won't implement COLRv1, last I heard.<br><br>2. Skia/C= hrome being the reference/practical implementation of COLRv1, coverage of v= arious skia-related resources are perhaps lacking. For example, you mention= ed HarfBuzzSharp being part of dot net API, but you did not mention that S= kiaSharp pre-dates HarfBuzzSharp, and are AFAIK, maintained together by the= same team: https://github.com/mono/SkiaSharp-API-docs (this contains the H= arfBuzzSharp API docs also), and https://docs.microsoft.com/dotnet/api/skia= sharp . I'll tell you more below, since I have been co-maintaining skia= -python for about a year now, and in fact the person who released the month= ly update to skia-python, tracking skia's monthly releases, for the las= t 10+ releases, after it having been somewhat dormant at m87 for three year= s. <br><br>3. On font editors, there was a discussion between me and Georg = of Glyphs, and some initial investigation of the possibility of porting Gly= phs to windows via Microsoft's WinOBJC, and to Linux via OpenStep (the = open-source clone of NeXT, what Mac OS X started with two decades ago). Lik= ewise, MS is not oppose to open-sourcing the whole of Visual Truetype GUI (= minus the Apple/Microsoft font scaler code), and I have approached Apple fo= lks about the first truetype font editor, RoyalT, from 35 years ago. Some o= f it depends on FontVal-RX (https://github.com/FontVal-extras/FontVal-RX ),= and what's possibly the beginning of FreeType 3. FontVal-RX was suppos= ed to happen two years ago, except I got really ill and was hospitalized fo= r a bit, and during my recuperation, distracted by skia-python.<br><br>4. a= nother 10-year-and-still counting issue: https://github.com/fontforge/fontf= orge/issues/1534 - that fontforge cannot be used to manipulate Google Noto = / Adobe Source CJK fonts. I think it is worth mentioning, considering the r= ole of fontforge and Google Noto / Adobe Source fonts.<br><br>People who wa= nt to stop reading, should stop now... anyway. Further.<br><br><br><br><br>= 1. I submitted the one-line patch to qt - https://bugreports.qt.io/browse/Q= TBUG-120543 - to switch on OT-SVG support in qt-webengine (a folk of the ch= romium code). qt 6.7 was about 6 months behind at m118, the upcoming 6.8 is= still m118-based like 6.7. Current chrome is m127, although the QT folk se= ems to have a m122 based qt-webengine backend in dev, which means it is sti= ll about 6 months behind chome's.<br><br>skia and chrome version number= ing are in sync, and has a 4/6 weeks release cycle, for those people who d= on't know. so m118 and m127 is roughly about 9 months to just over a ye= ar apart, without looking at precise dates.<br><br>The way I see it, Google= folk likely will spend time adding COLRv1 as a patch, and submit that to t= he webkit folks. Whether they will take it, is another matter.<br><br>The o= ne-line patch to enable OT-SVG is included in recent releases of skia-pytho= n, since I co-maintain it. I can put random stuff in myself, within reasons= . BTW, I have left instruction to the project owner that if I disappear for= extended time, and the COLRv1 addition to skia-python gets bit-rotten, ple= ase just remove it.<br><br>2. SkiaSharp is at m116, which is after m98 (the= COLRv1 entry point) and m103 (the disabled OT-SVG support in skia/chrome).= <br><br>https://github.com/HinTak/skia-building-fun/ is a shell-script plus= some patches, to build current skia on linux in about 20 minutes using abo= ut 300MB total disk requirement. The default / official instruction require= s about 9GB of disk spaces.<br><br>https://github.com:HinTak/freetype2-demo= s-skia/ is a modification of freetype2-demos to use skia in addtion to cai= ro/rsvg (switching by a launch switch between the two) for OT-SVG rendering= . There is a not-yet-public addition on top of that to add COLRv1 viewing s= upport to ft2-demos too. I consider the COLRv1 addtion a bit too ugly to be= posted at the moment, but the additional COLRv1 patch is used to build htt= ps://github.com/FontVal-extras/binary-archive , the rpms of freetype demos = and the modified freetype on my own system. Grab both and set LD_LIBRARY_PA= TH etc to see it, if you want to. I'll add some notes, instructions at = some point.<br><br>TODO: submit one-line patch to SkiaSharp to enable OT-SV= G support.<br><br>3. and 4. After working on FontVal for almost a decade no= w, I have come to the realization that it is using the editor-like APIs in = Apple/Microsoft's font scaler (which does not exist in FreeType, and I = spent 3 years adding partial bits of). Despite Microsoft claiming otherwise= , the font scaler API continue to be extremely similar - for example, it is= possible to run FontVal with Apple's font scaler instead of MS's, = without any noticeable code change, and Apple's libFontValidation (and = Apple's FontTool suite) can likewise inter-op with Microsoft's font= scaler. And I realise that the Apple font scaler having an accompanying fo= nt editor, RoyalT, since day one, was a very important part of its design.<= br><br>One frequent complaint of the current incarnation of FontVal is that= , however good it is, it does not reflect suitability of use for windows (o= r Mac OS X) - that's just a harsh reality: a font validation tool must = use the platform's renderer, to have any authenticity of claiming suita= bility. <br><br>Likewise, font editors, at its final finishing stage, must = use the platform's renderer for looking at the near-finished outcome.<b= r><br>FontVal-RX is the project to detach FreeType (and make it an optional= backend), and re-enable the bridge to the Apple/Microsoft font-scaler. So = I have closed off https://github.com/HinTak/Font-Validator/ a few months ag= o, but it should have happened about two years earlier.<br><br>The potentia= l outcome of FontVal-RX, is bringing Visual Truetype to open-source (minus = its fontscaler code), since it means making FreeType more Apple/Microsoft f= ont-scaler interface-similar. Plus porting Apple's libFontValidation, a= nd Glyphs, among other possibilities.<br><br>The original plan for FontVa-R= X was an initial release about 18 months ago, and reaching its ending goal = (a modified FreeType having Apple/MS font-scale like APIs) around 2028. Tha= t didn't happen because I have fallen ill, and now distracted by skia-p= ython. Skia-python itself would basically push FontVal-RX's ending goal= date by another two years, to 2030.<br><br>The time estimate is based on t= hat fact that I can only justifiably spend x amount of my time, uncompensat= ed, in any period, on "hobbyist" pursuits. So spending time on sk= ia-python means not spending time on FontVal-RX. And, responding to flames,= such as answering "why don't you do...." also cut into that = time. So - please think before you comment, because responding to your comm= ents also cut into that time share. Thanks for reading so far. And on the o= ff-chance that somebody feel like funding me on portion of this, please get= in touch.<br><br><br><br>On Tuesday 9 July 2024 at 03:05:15 BST, Behdad Es= fahbod <[email protected]> wrote:<br><br><br>Hi,<br><br>I'd like = to share with you the "State of Text Rendering 2024":<br><br>=C2= =A0=C2=A0https://behdad.org/text2024/<br><br>Feedback and comments are most= welcome.<br><br>Thanks,<br><br>behdad<br>http://behdad.org/ </d= iv> =20 ------=_Part_6652640_1120578133.1720731130414--