mattlag
commented
3 years ago Hello! Thank you for the detailed bug - I will look into it. But, without doing any investigation, I can tell you for sure that there may be some issues here. And ones we may not be able to fix.
We use opentype.js to read and write OTF files. It's a fantastic library, but one thing that it does is interpret OTF metadata and table information, then makes it available through a condensed API as a JSON object. So reading a project in, Glyphr Studio does not have access to much of the raw table data within a OTF or TTF file.
Same with export - Glyphr Studio writes a very small subset of font metrics to an opentype.js object, then opentype.js does a lot of work to create the binary OTF file. There are certain opentype.js properties that map to multiple OTF properties. And, many OTF properties are not available to write from opentype.js.
So, like I said, I'll investigate the details here to see if there is something fixable within Glyphr Studio. But, chances are there will be nothing I can do. This scenario of importing to Glyphr Studio and immediately exporting back to OTF will always result in changes... it's not a perfect mapping. I'd actually recommend using a different typeface design tool, like Font Forge which is open source. And it will maintain the exact table and metadata within your OTF project.
Thank you, and apologies!
When loading a font and exporting it without any modification, it still changes some header attributes. This can change the behavior of the font in certain applications.
As an example, when importing SourceCodePro-Regular.otf and exporting it as an OTF, then looking at the attributes (using fontdrop) we can see that the Horizontal Header Table (hhea) has been modified (minLeftSideBearing and minRightSideBearing changed from -193 to 0, and xMaxExtent changed from 793 to 0) and the OS/2 attributes are also modified (for instance, ySubscriptYSize changed from 600 to 699, ySubscriptYOffset changed from 75 to 140, sTypoAscender changed from 750 to 984, sTypoDescender changed from -250 to -273, usWinAscent changed from 984 to 1060 and usWinDescent changed from 273 to 400).
To see how this can affect the behavior of the font, here are screenshots from Office Word and Fluent Terminal with the original SourceCodePro and the one imported and exported in GlyphrStudio. (font size and font weight are the same).
In Microsoft Office Word
In Fluent Terminal
As you can see with the box drawing characters, the line spacing (and thus line height) is different and the box drawing characters don't connect anymore.
I've tried to disable overshoot and tweak the glyph proportions in the font settings but apparently it did not change the correct attributes. This might be a very niche issue.