Version string without added Glyph version

Is it possible to get Glyphs to not add its own version number, while generating the version string from the “Version” field in the font info?

I know about the “versionString” custom parameter but having to update data in two places manually is a source of errors. Redundancy is a no-go for me.

You can use placeholders as described in the custom parameter description:

Excellent, thanks! I had only looked at the “Version” section of the handbook.

Yes, might be worth mentioning/linking to the custom parameter docs as well.

You’ll see the same description when adding a custom parameter, but currently we don’t have a good way to show it again in-app once it has been added. That will improve.

1 Like

To follow up on this, it would be very helpful to include the Glyphs build number somewhere in the font (anything that can be seen in ttx would be fine) but not in the official version string. It’s not a secret that I am using Glyphs but I’d prefer a clean version string. Is that possible?

1 Like

The version string was done like this by makeOTF and we copied that. You can add a custom versionString to overwrite it.

That’s not the question. Apart from the custom (clean) version string, is there a way for Glyphs to write the version number somewhere into the font? What would be a sensible place to do that?

I should have added that writing the build number would have to be automated on export so it is absolutely safe from writing the wrong number into the font.

A small glyphsFilter, added as a custom parameter to each export, to read the Glyphs version and then write it into, say, a custom name record, could be a solution but it’s rather clumsy.

At LucasFonts, we write tool versions and build-time options into a custom LUFO table in the font (but not with Glyphs). Making up a simple table format, like a couple of numeric fields, and adding it to the Python FontTools is relatively easy. Adding the table to the font on export could be done with a Corretto plugin for example.

Or a custom name table entry. I just added token support for “Name Table Entry” parameters. So you can do now:

345; {{{buildNumber}}}

this will result in

    <namerecord nameID="345" platformID="3" platEncID="1" langID="0x409">
      4104
    </namerecord>

Pick a name id that is not used otherwise. Above something like 255 is open for custom use.

2 Likes

This seems like the best solution. Which Glyphs versions will (or do) support it?

You mean the “Name Table Entry” parameter? That works for many years already (probably in Glyphs 2).

This sounds like it will work in a soon-to-be released Glyphs version.

Yes. The token support is new. That is true.