Question — Has the Name Table Entry parameter been made functional? It’s something that we would be keen to implement on some of our font files here, specifically with regards to preserving legacy name tables for older, but still widely used fonts that were previously built in Fontlab. Having to run additional checks and changes via OTM on export is something we are trying to avoid doing. Handling these changes directly in the glyphs source file would be ideal. Any plans for this activating this feature in the future?
Also, another related query with regards to name entry: 3, 1, 1033, 4 (MS Full Font Name). I noticed that around V1 – 2.1-ish Glyphs used to export this name identical to entry: 1, 0, 0, 4, (Mac Full Font Name). I’m currently running Glyphs 2.2.2 (827), so not the cutting edge version but it appears there has been a change to the MS Full Font Name entry. Previously an exported font name here would read with spaces i.e ‘FS Emeric Light’ (matching the Mac name) but now a font exported in 2.2.2 is named as ‘FSEmeric-Light’. Are you aware of any specific reason for this change?
Many thanks for implementing the feature Georg, this is great news!
With regards to the Win ID4, from what I have researched across various other blogs and from speaking with other designers, the hyphenated naming convention was developed as a bit of a hack to resolve some font menu listing issues in MS Word 2011 for Mac and whilst it is worth preserving this naming convention in legacy font builds it appears to be less essential to do so now, or least that is my understanding.
Also I have noticed that the embedding of TTF font files will suffer / become irregular in MS Word/Powerpoint on a PC if the ID 4 font name does not match the Mac full font name. Perhaps there are others on the forum that have further info on this.
Question — Is Name Table Entry active for other Name Fields right now or just ID 4? Also does this parameter compile into all font formats, specifically EOT?
My reason for asking is that I am engineering a particularly large font file which has multiple style names within the ‘Weight Name’ instances field. Can I write multiple Name Table Entry parameters for all of name adjustments that I need for this specific project? Are multiple Name Table Entries permitted?
@mekkablue Not quite — I experienced a situation where only the ID4 parameter is respected. I will do another test this evening and report back to confirm.
I have tested and in order to clearly test the functionality, I created the string ‘CRAFTBEER’ as the entry, purely so that it would stand apart from all of the other generic looking info.
Here’s a screen shot of the parameters and what is displaying otm:
The name ‘Name Table Entry’ should be used to set non standard name table entries, like localisations. With name ID 1 and 2, makeOTF is quite persistent and might ignore manually set values. Please check the feature.fea file in the temp folder for debugging.
OK, we’re making progress, but things are not yet correct.
Using Glyphs 2.3.1, build 905, the temp feature file is now correct in those entries that were incorrect:
so thanks for fixing that.
However, the name table in the genereated ttf still has the inconsistent data for the subfamily name (ID 2):
For PlatformID 1 (Mac) the subfamily is “Light”,
For PlatformID 1 (Windows) the subfamily is “Regular”
For reference, here is a screenshot from OTMaster showing several key namestrings for both platforms:
Note the nameID 2 values.
For what it is worth, the OS/2 table in the generated font has usWeightClass = 300 which I believe is correct.
I tried compiling the temporary features file against the font using AdobeFDK’s makeotf and got these errorr:
makeotfexe [WARNING] <Alkalami-Light> name id 1 cannot be set from the feature file. ignoring record
makeotfexe [WARNING] <Alkalami-Light> name id 1 cannot be set from the feature file. ignoring record
makeotfexe [WARNING] <Alkalami-Light> name id 2 cannot be set from the feature file. ignoring record
makeotfexe [WARNING] <Alkalami-Light> name id 2 cannot be set from the feature file. ignoring record
makeotfexe [WARNING] <Alkalami-Light> name id 4 cannot be set from the feature file. ignoring record
so presumably Glyphs is setting name IDs 1, 2, and 4 by some other mechanism.
No, I disabled the warring in my version of makeOTF. The problem might be that the file FontMenuNameDB has to say something, to. I wanted to get rid of it already…
Does this mean we should try defining a FontMenuNameDB for our project and, if so, where do we put it so that it will be found when Glyphs compiles the font?
