source-foundry
Version not set in Unique ID field
Similar to #104 I found another place font versions frequently show up that isn't being normalized:
Somehow nameID=3 (Apple docs: "Unique subfamily identification", Microsoft docs: "Unique font identifier") has come to be frequently filled with a fallback value (probably popularized by ufo2ft precedent) composed of the font version, the short foundry name plus the font name.
Here is an example, the original being straight ufo2ft output where it knew the major/minor version at build time, the update being a run where no version was available to ufo2ft and instead an attempt was made to normalize the font version after the fact with font-v:
--- /home/caleb/scratch/Libertinus-6.12/LibertinusSans-Italic.otf 2020-06-28T15:56:49+03:00
+++ LibertinusSans-Italic.otf 2020-08-18T12:47:49.742210+03:00
@@ -2540,13 +2540,13 @@
Italic
</namerecord>
<namerecord nameID="3" platformID="3" platEncID="1" langID="0x409">
- 6.120;ALIF;LibertinusSans-Italic
+ 1.000;ALIF;LibertinusSans-Italic
</namerecord>
<namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
Libertinus Sans Italic
</namerecord>
<namerecord nameID="5" platformID="3" platEncID="1" langID="0x409">
- Version 6.120
+ Version 7.001;RELEASE
</namerecord>
<namerecord nameID="6" platformID="3" platEncID="1" langID="0x409">
LibertinusSans-Italic
Obviously nameID=5 got set properly. Name №3 is a little trickier, but it might be worth looking at the string and seeing if the first segment looks like an OpenFV version string, and if it does update it.
Not ignoring these reports just have not had time to look into / address them. Something that you would like to PR in?
the original being straight ufo2ft output where it knew the major/minor version at build time, the update being a run where no version was available to ufo2ft and instead an attempt was made to normalize the font version after the fact with font-v
You are not using valid version data in your source files in your build workflows? We could certainly match on that nameID 3 string with a regular expression and edit it. I think that the question is whether the version number in nameID 3 approach is desirable. I'm not sure about this.
Microsoft Typography OT spec docs lists this example for nameID 3: Monotype: Times New Roman Bold:1990 and the spec documentation is extremely vague.
The use of a version number doesn't necessarily identify unique builds within versions and it isn't clear to me if/how nameID 3 is used to distinguish different fonts across platforms. You can imagine that this is something that might be linked to a font caching mechanism in which case it would be useful to make each build different, including each build that might be installed and used for testing across a "version".
Thoughts?
You are not using valid version data in your source files in your build workflows?
Nope. I don't expect the version string(s) in source files to be anything but garbage filler strings if they even exist. Some editors forcefully add them or require them as part of their source file format specs, but I'm doing my best to ignore that data on build and version font builds in a normalized way.
Fonts are generated from repositories and automatically versioned via Git meta data including whether or not the commit being built is directly on a tag (release) or not (dev build). The goal is to be able to cut releases just by tagging without having to monkey with sources at all (something that is error prone across different editing software, multiple designers, and especially by having many source files involved in a single build.
The use of a version number doesn't necessarily identify unique builds within versions and it isn't clear to me if/how nameID 3 is used to distinguish different fonts across platforms.
Having just checked out the spec (gag) I see what you mean about extremely vague. I have no idea what that field is actually for, but I do know I want to normalize it so it doesn't have cruft version number strings from outdated builds!