Ok, let's use the big guns... I run ttx on the current MuseScore FreeXxxx.ttf fonts and on your Mac and non-Mac variants (downloaded from your github PR). Leaving aside for the moment being the bold variants, these are the results.
*1) Common tables*: All fonts contains the following tables (which are more or less mandatory): 'GlyphOrder' 'head' 'hhea' 'maxp' 'OS/2' 'hmtx' 'cmap' 'cvt ' 'loca' 'glyf' 'name' 'post' 'gasp' 'FFTM' *2) The current MuseScore fonts* in addition contain: *) FreeSans.ttf Tables: 'fpgm' 'prep' 'kern' for Cyrillic only 'GDEF' 'GPOS' kern for Cyrillic, Latin and 'bn'(?), but only Cyrillic is linked to main lookup table 'GSUB' *) FreeSerif.ttf Tables: 'fpgm' 'prep' 'kern' for Cyrillic and Latin (and several others) 'GDEF' 'GPOS' kern for Arabic, Cyrillic, Devanagari, Latin, Thai all properly linked 'GSUB' Note that: 2.1) *both* 'kern' *and* 'GPOS'/'kern' are present 2.2) 'GPOS'/'kern' for FreeSans.ttf is bogus; in fact FreeSans.ttf lacks any usable kerning data for Latin. 2.1) is in general not good, as the presence of both tables may confuse some font stack and/or make unpredictable which table a given font stack will use. The cure for this is to have *only one* of the 'OpenType' and 'Old-style kern' check boxes checked at a time. 2.2) is also obviously not good! There is a cure for this which I gave in my previous post and will repeat below. *3) Your font variants* in addition to the common tables also contain: *) FreeSans.ttf Tables: 'kern' for Latin only *) FreeSans-Mac tables: 'GDEF' 'GPOS' kern for Latin only 'GSUB' *) FreeSerif.ttf Tables: 'kern' for Latin only *) FreeSerif-Mac.ttf Tables: 'GDEF' 'GPOS' kern for Latin only 'GSUB' Note that: 3.1) non-Mac versions have the 'kern' table and lack the OpenType tables (as you turned off the OpenType check box) and that Mac versions have the OpenType tables and lack the 'kern' table (as you turned on the OpenTypeType check box and possibly kept off the Old-style kern check box). Having only one of the two tables is generally positive, as I said above. 3.2) Having different sets of tables for different fonts is sub-optimal, as it complicates maintenance and development and might be a source of problems difficult to track. My opinion is that there should a very good reason for this. 3.3) All fonts lost the non-Latin kern data. This may be secondary right now, but has to be kept in mind, given the international coverage of MuseScore. It would be nice to know from which editing / choice of settings this happened. 3.4) All fonts lack the 'fpgm' and 'prep' tables. They are not related with kern (at least, they should not be), but with font instructing: loosing these tables is generally not good, as very few (and usually rather simple) fonts can have instructing without them. We probably do not want to loose them. __________________________ *4) Some conclusions?* 4.1) Of the two possibilities surfaced above: 'kern' table only without 'GPOS'/'kern' vs. 'GPOS'/'kern' (and in general OpenType) tables only without the 'kern' table, I believe the latter is generally preferable, because the former is a rather outdated setup and because other OpenType tables may contain useful data; for instance the FreeType-based font stack in (most) Linux automatically recognizes the 'GSUB'/'liga' sub-table for ligature substitution. 4.2) Of course, this implies that data in OpenType tables are correct. In current MuseScore FreeSans.sfd font, 'GPOS'/'kern' data are inconsistent, this is why it does not behave correctly. 4.3) Fixing FreeSans.sfd is easy: it is enough to add the missing 'kern' feature in the 'GPOS'/'kern' sub-table. With this change, the rebellious "VA" pair -- among others -- kerns correctly! 4.4) IMHO, until something solid surfaces against, the way to go is to generate all fonts from FontForge with: *) Correct table data! *) "OpenType" turned ON *) "Old-style kern" turned OFF *) "TrueType hints" turned ON in order to have 'GPOS'/'kern' sub-table (and other potentially useful OpenType tables) without the 'kern' table messing in. If helpful, I can submit a PR along 4.3) and 4.4) guidelines. If this would be more messy than helpful, I'll happily leave it to someone else. 4.5) For Mac/OSX, the impact of the "Apple" generation option possibly requires some investigation. I cannot do that; if someone is willing, is welcome! I would start with the options listed above, though. Hoping it helps... Maurizio -- View this message in context: http://dev-list.musescore.org/Kerning-tp7579040p7579045.html Sent from the MuseScore Developer mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Mscore-developer mailing list Mscore-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mscore-developer