Open felipesanches opened 2 years ago
You mean "prep"?
Ha! "prop" the AAT table => https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6prop.html
Yeah, prop is bad because it's AAT; AAT was the Apple pre-OpenType way of doing font cleverness. It's OS X specific (although Harfbuzz now has optional AAT support), and it's old, so new fonts should not be doing that.
There are a lot more AAT tables, why signal this one out?
I guess once one is flagged, the message has been successfully delivered to the user ;-)
Please open an issue with a longer list of tables to be rejected and we'll do so (only when reasonable, of course!).
But it is not a particularly important AAT table, I can drop it and keep, say, morx
or kerx
tables and it would still be an AAT font that only works where AAT is enabled (or works differently).
Case in point this font is broken when AAT is supported and it does not have a prop table (only morx
and feat
).
Code moved like a million times, but here is the commit that introduced this table and the issue that requested it. Nothing is mentioned about AAT and I doubt that ever was the reson, either the table was mistaken for another table or because FontTools didnât support this table in 2016 someone checked a font with ttx and thought it is some junk table.
Thanks! That's right. Reading the issue, I see that @davelab6 thought it was a FontForge properties table (which is not the case). And even made it clear he was not sure by saying "(I think)". I blindly trusted him then, just like I am trusting you guys here this week.
We started rejecting that table for the wrong reason, but it turns out that we might really want to reject all AAT tables. Is that really the case?
Google Fonts profile might want to reject them, but it shouldnât be a universal check since there might be valid uses for such a font (and thanks to HarfBuzz support, AAT font are now more widely supported than they ever have been).
I just don't want to trust blindly anymore. That's why I've been going after better rationales for the checks. And that's what made me touch this issue this week. I could not accept that a table being rejected without a clear justification.
It might be worth a WARNING though, even in universal profile, since people often generate morx
table from FontForge by mistake and it is almost always a non-functioning table as well.
Google Fonts profile might want to reject them, but it shouldnât be a universal check
Yeah, I was wondering about that. Is FontTools support meant to facilitate working mostly with legacy fonts that happen to use AAT ("old / OSX-only" stuff in @simoncozens' words)? Should we discourage AAT usage in new fonts unless the designer is really sure about what's being done? I would consider keeping a universal check for all AAT tables at WARN level and making it a FAIL on googlefonts
profile check. Would that be OK?
FontTools got AAT support when Sascha was making test AAT fonts when Behdad was adding AAT support to HarfBuzz, and HarfBuzz got AAT support because Chrome wanted to stop using the CoreText bridge in HarfBuzz as it was slow and AAT fonts are still common in macOS.
Whether AAT fonts are still relevant or not, is not something I can answer. Some AAT tables might still be useful, and both HarfBuzz/CoreText seem to allow for a hybrid model where OpenType and AAT tables can be mixed. Someone might find this useful (for example, IIRC, kerning using kern
table is faster then GPOS
and AAT kern
and kerx
tables are more capable than legacy kern
table, so someone might legitimately want to use them).
Thanks for all that background info, @khaledhosny!
@davelab6, what's your opinion on checking for the presence of AAT tables both on googlefonts
profile (as a FAIL) as well as on universal
(as a WARN)?
Also, who else should I be asking this question?
ping @davelab6
The check com.google.fonts/check/unwanted_tables suggests removing 'prop' tables. What's the reason for this? The code currently does not report a reason for that. We should at least figure it out and clarify the message.