You are asking in the blog to report issues with the new makeOTF.
I am a bit of a special case. In the distant past I had to make fonts with OTL tables, before there was VOLT or makeOTF. I had to make my own tools and source format, which is still in use. So for Glyphs I have a script that generates a GPOS source from anchor and kerning, rather than relying on what Glyphs & makeOTF produce.
But now I am reviewing a Devanagari produced by somebody who provided us with a Glyphs source & glyph xml and binary fonts. If I want to fix something, the first step is to see if I can reproduce the binary font: Which turns out to be a challenge indeed. It its always different.
There are significant differences in the output of old 1219 and new 1230. The only issue I investigated so-far is mark attachment. There was a particular combination of base and mark, where previously the mark was displayed in the origin of the base glyph. A bad place! When trying out the same combination with a Mac app, and the font generated with 1230, the mark ended up half-way between two lines, a couple of lines above the line with the base glyph.
In a mark-to-base lookup, if you have more than 1 mark class, each base in the lookup gets an offset to an anchor record for each mark class. In the very first version of the OTL specification it was possible to have a zero offset, if the base did not need an anchor for a certain class. But shorty thereafter Microsoft decided not to allow zero offsets. So I have been putting every mark class in its own separate lookup, to avoid having to create source files with anchors in places where no anchors are needed.
But Glyphs-makeOFT assembles various classes into single lookups. Previously it was inserting anchors with coordinate 0,0 to make up for missing anchors. If I decompile the GPOS created with 1230, my tool mentions there are zero offsets. Not sure what happens with the Apple shaper. It is clear it ends up with some form of large number that gets used as an anchor.
In theory it is possible that the masters of the OT spec have decided to allow zero offsets after all. But I do not find a record of the change. And it doesn’t seem a good idea if the first font I try with the new makeOTF breaks the first software I use it with.
Apart from this the attachment lookups in the binary look a bit chaotic. There is a “mark” feature with two lookups, that should not have to be there as most obvious example. There is difference in kerning too, but I haven’t investigated.
My head is spinning from all these different fonts generated from the source. So I leave it at this for now.
Jelle
The feature code produced by Glyphs has not changed. What makeOTF makes with it has changed slightly. It seems that before, it would have added an anchor with o/o coordinates and now (correctly) adds a zero offset.
I’ll have a look.
I tried this and can’t find a problem. Do you have a sample font that shows the problem?
Let me start with an image showing the difference between having an inappropriately added anchor in the origin (black) and the effect of having a zero offset (red).
(Screen show with Apple’s Pages.app.)
Could you send me that font? My test fonts don’t show that problem.
I had a look and for now I can’t do much for now except for adding all the missing anchors.
I don’t like to always split lookups for each anchor as this uses much more space.
Thank you for taking a look.
Splitting up the lookups does not have to make the table larger. In the current set-up: if a base needs 1 anchor, then it has to have them all. In the sample font I send, there are many anchors that we can do without. They are just there to make up the count. Composites inherit anchors from component glyphs, whether they need these anchors or not. That is multiplying the count. If you are interested you can make the comparison with Noto Sans Devanagari (GPOS source on GitHub). Not that much different in glyph support. It adds GPOS support for Vedic that the sample Serif currently doesn’t support yet. But the binary table is about a third in size.
Some thoughts for reconsidering the issue
When putting several mark classes into a single lookup: for each unnecessary or bogus anchor we get a 2 byte offset and a 6 byte anchor record.
When putting each class into a separate lookup, the used storage for mark-anchors and actual base-anchors remains the same. But each base that has more than one anchor will be present in more than one coverage table. Assuming a format 1 coverage table that means we get 2 bytes per extra lookup. When a format 2 can be used it is less and in theory it could be 0.
So splitting up may take more space, or less space, but it seems unlikely it takes much more space. The worst case for not splitting up results in a larger table increase as the worst case for splitting up. And splitting up means that we do not risk marks showing up in strange places, which would happen when adding anchors in arbitrary places.
For example with 2 mark classes: if a quarter or more of the base glyphs has 1 anchor, splitting up creates a smaller table.
I tried this and in my test case, it produced a bigger table. I presume the coverage part is duplicated. If there are only a few glyphs that miss an anchor, then it is better to have empty enactors, if more glyphs end up with empty anchors, it would be better to split.
Slightly off-topic: To fix some OTL issues in the font I am still trying to understand what I see in GlyphData.xml, the Glyphs file, the feature file and the final fonts. I did notice that when I generate a TTF and an OTF, there are e few more base anchors in the GPOS of the OTF. I spotted in a diff of the feature files. It happens with composites that do not have anchors themselves, but inherit them from component glyphs. I am not yet done investigating. But I suspect I will have to send you the files to look at some time next week. (To reproduce the issue I found out that I have to make a bogus change and save the Glyphs file after generating the first font, otherwise it uses the same feature file for the second font.)
I’ll continue documenting some mark attachment issues. It is somewhat specialist.
Some non-spacing marks have both an underscore anchor and a plain anchor. I believe the intend is to use the one to position the mark on the base and the other for a subsequent mark to mark. But I see a reph mark appearing in a mark-to-base lookup as mark and as base. I guess I will have to remove the plain anchor anyway as I don’t think I there is anything to anchor there yet. (But looking forward, we will have to anchor some vedic signs there.)
There is a contextual variant of the candrabindu as a one glyph mark class. It is intended to attach to 3 independent vowels and a spacing vowel sign in a mark-to-base, which works. And to attach to two non-spacing vowels in a mark-to-mark lookup. That does not work: the lookup uses a MarkAttachmentType. With a mark from one class and the base-mark from another, this lookup will not be applied. Because the alternate is in a mark-to-base with practically all base glyphs, it is anchored on the bogus origin anchor of the base consonant instead. I am not sure in which circumstances one would use MarkAttachmentType in mark attachment lookups.
Normally I expect any glyph that is touched in OTL tables to be classified in the GDEF as base, ligature or mark. There is quite a few that is still not classified. Most odd to see a iMatra and iiMatra, the second as a base, the first not present at all. And none of the ligatures and context variants of these are classified. But because they have anchors, for some reason they appear in mark-to-mark lookups. These anchors may be there because the designer tried a scheme of sorts that was abandoned. But I hope it is possible to figure out how to get them into the GDEF end into mark-to-base lookups for vedic signs.
I did my best to simplify mark attachment, remove unnecessary anchors, to improve the GlyphData. Two items I don’t know a work around for: MarkAttachmentType being used with mark to mark lookups. The other is a new discovery: most of the kerning is assigned to the “dist” feature. But in the script table this feature is assigned to the default script only, not the language specific entries. As it seems the app decidesd where to put what in the GPOS, there doesn’t seem anything I can do about it…
I’ll send out the file to test.