afdko
afdko copied to clipboard
adobe-type-tools
Generating italic TTFs messes up spacing.
I think something is happening with FDK’s interpretation of extrema on slanted shapes, which is drastically compromising spacing.
I've made two nearly identical test UFOs with the glyph c. The other glyphs are just reference blocks. The only difference between these two UFOs is that one has conventional "upright" extreme points, which solves the spacing issue.
Please see the UFOs and their resulting TTFs below: test.zip
It seems ~~makeotf~~ whatever tool generated the TTF puts into the hmtx table the minimum x coordinate that the curve touches, not any actual point on or off the curve:
<mtx name="c" width="626" lsb="23"/>
The leftmost off-curve point in c is at x = 2, I think that’s what should go into the lsb value (and changing it manually indeed fixes the spacing).
Given that makeotf does not build TTF binaries natively, the issue must be somewhere else.
It would be interesting to know how the TTFs are built within Batch, presumably a conversion is happening @typemytype ?
Looking at the Batch source code, I see from lib.settings import doodleSupportedExportFileTypes, I assume the rest happens within the application itself (and might not be related to makeotf at all)
~Right, whatever is building the TTF is not calculating the bounding box correctly. Per the OT Spec the value for xMin should be simply the "Minimum for x coordinate data" and that bounding box values "[...] are obtained directly from the point coordinate data for the glyph, comparing all on-curve and off-curve points."~
Sorry, the bounding box calculation is correct, but the 'hmtx' LSB value should be set to the glyph's xMin as @jenskutilek mentions to get things to align properly. Keeping the 'head' table flags bit 1 OFF (as this font appears to) is supposed to counteract this mismatched xMin/LSB condition but most schemes seem to assume that xMin will always equal LSB so best to set them that way.
As commented in the fonttools thread, it is easy to reproduce with RoboFont. RF does not use fontmake to build TTF, so the bug is at least somewhere in the Venn diagram between RF and afdko. Maybe @typemytype can have a look?
I tried to build the attached font (slightly updated from the one posted in the fonttools thread) with afdko but it is (and therefore I am) failing.
$ makeotf -f LSBTTFBug.ufo -o test.ttf
tx: --- /Users/just/Desktop/LSBTTFBug/LSBTTFBug.ufo
tx: (ufr) Warning: No version specified in source UFO font.
Command '['tx', '-t1', '/Users/just/Desktop/LSBTTFBug/LSBTTFBug.ufo', '/var/folders/r6/16l72gg51gqcwbgpk9gtv0mc0000gn/T/tmphuj68a10']' died with <Signals.SIGSEGV: 11>.
Ha, unfortunately makeotf can really only make OTFs :-)
The -o option is just for moving files around.
We (in Source Serif, for example) make TTF files using otf2ttf, a fontTools snippet: https://github.com/fonttools/fonttools/blob/main/Snippets/otf2ttf.py
The reason for this probably is that cubic input data is expected. tx is trying to convert it to T1 and then crashes:
Downloads $ tx -t1 LSBTTFBug.ufo [20:06:26]
tx: --- LSBTTFBug.ufo
tx: (ufr) Warning: No version specified in source UFO font.
[1] 1561 segmentation fault tx -t1 LSBTTFBug.ufo
I would say this proves no involvement of the afdko 😅
The fact that tx crashes when presented with quadratic source data means that it cannot be involved in creating a TTF binary. It must come from somewhere else.
ufo2fdk sets it to the left margin of the shape not the most left point...
https://github.com/robotools/ufo2fdk/blob/99a01d340de3ef3c3d86708c45afebd682daab00/Lib/ufo2fdk/outlineOTF.py#L442
honestly, confused about the term left side bearing https://learn.microsoft.com/en-us/typography/opentype/spec/hmtx
Thanks to everyone here and https://github.com/fonttools/fonttools/issues/3072 for your attention to this issue!