fontgoggles
fontgoggles copied to clipboard
Allow choosing CoreText shaper
Requires https://github.com/harfbuzz/uharfbuzz/pull/72, of course.
Thanks, this looks good upon first glance, will review more thoroughly later.
Lovely! Can you point me to the font and the test string?
Not really, I'm afraid, for this font. Apparently the difference is fixed in the Big Sur version of CoreText anyway. You might find some CoreText/Harfbuzz shaping differences here: https://raw.githack.com/icu-project/text-rendering-tests/master/reports/CoreText.html#SHLANA-1
I'm getting a hard segfault crash when I choose the CoreText shaper on a UFO. Could easily be a mistake on FG's side, but I haven't been able to figure it out yet.
Do you mind if I rebase this PR and add a test that reproduces the crash? It may be easier to debug from there.
The uharfbuzz issue is fixed, I think this PR can be merged.
It doesn't segfault anymore, but it still doesn't work for the sparse fonts that FG builds from UFOs. We need to figure out which tables CoreText can't do without. Might be as simple as adding a dummy OS/2 table or whatnot.
I think FontBook might show what Core Text thinks is wrong with such fonts. How can I get the binary font FG is building from UFO?
I bet FontBook will complain about missing glyf
or CFF
tables, but that should not be the problem.
The "sparse" compile code is here: https://github.com/justvanrossum/fontgoggles/blob/99a4579834719ac17bc2725c8f09e5891f9ba44b/Lib/fontgoggles/compile/ufoCompiler.py#L63
This makes hb-shape with coretext shaper work for me. The dummy values should be OK, except for the metrics (coretext shaper does not use HarfBuzz font functions, so it always needs an hmtx
table):
index 98aad12..58bced8 100644
--- a/Lib/fontgoggles/compile/ufoCompiler.py
+++ b/Lib/fontgoggles/compile/ufoCompiler.py
@@ -12,6 +12,7 @@ from fontTools.fontBuilder import FontBuilder
from fontTools.ttLib import newTable
from fontTools.ufoLib import UFOReader
from fontTools.ufoLib.glifLib import _BaseParser as BaseGlifParser
+from fontTools.pens.ttGlyphPen import TTGlyphPen
from ufo2ft.featureCompiler import FeatureCompiler
@@ -36,6 +37,12 @@ def compileUFOToFont(ufoPath):
glyphOrder.insert(0, ".notdef")
cmap, revCmap, anchors = fetchCharacterMappingAndAnchors(glyphSet, ufoPath)
fb = FontBuilder(round(info.unitsPerEm))
+ pen = TTGlyphPen(None)
+ glyph = pen.glyph()
+ fb.setupGlyf({n: glyph for n in glyphOrder})
+ fb.setupNameTable({"psName": "TestFont"})
+ fb.setupHorizontalHeader(ascent=800, descent=-200)
+ fb.setupHorizontalMetrics({n: [1000, 0] for n in glyphOrder})
fb.setupGlyphOrder(glyphOrder)
fb.setupCharacterMap(cmap)
fb.setupPost() # This makes sure we store the glyph names
When using CoreText, are callbacks like the one set with hb_font_funcs_set_glyph_h_advance_func()
not used at all?
Yes, external shapers like CoreText basically get the font blob and are on their own after that.
(I don’t even think CoreText provide an API like this for HarfBuzz to use)
Ok, makes sense, but that makes it far less interesting to support for live UFO previewing. Considering to just fall back to the HB-native shaper in this case.
I don't use the UFO functionality, so I have no idea what makes sense for it. But I often need to test different OpenType implementations when doing complex OTL and I need compiled fonts for this anyway, so limiting the CoreText shaper to compiled fonts is not worse than the status quo.
Good, let's do it that way. It may be as simple as appendng the "ot" shaper to the shapers list as fallback.
Btw. I notice that the shaper is saved to the project file, but the popup is not set from the value in the project file upon reading.
That would be a bit misleading, I’d rather not allow selecting CoreText in this case.