I often read about people interpolating and then making small corrections/tweaks to the resulting weights. Since there’s no way to directly edit an Instance, are people just exporting and then opening up the resulting .otfs to edit? That seems like it would pretty quickly turn into a file-management nightmare.
If you are someone who works this way, what do you do?
Every published style is manually checked in my workflow.
Could you expand on what you mean? After manually checking, if you’re not happy with something, what do you do next? Do you go back and change your masters in the hopes of getting a better result, and then re-interpolate? Or are you making changes directly to the exported style and re-exporting it?
@CatharsisFonts, thanks for this! How many glyphs do you typically find yourself needing to use this trick on? I almost feel like it would make more sense for any Instance to be immediately editable within the .glyphs file, rather than having to use this trick a glyph at a time.
I always advise against editing the instances. As you realized already, that makes it very difficult to keep track of your changes. You always need to do bigger changes later on so you will need to re-interpolate and then fix the instances again? How does one know what changes he did the last time?
For the most part, the latter. The exported intermediates from Glyphs tend to have rounding errors. I also add TrueType hinting outside of Glyphs. If the tools were better, I would love to keep it all in one master source file.
Can you show me some examples of the rounding errors and whatever else you need to fix?
I’ll be happy to send you something the next time I run into one, but rounding errors are rampant. Additionally, the add extrema parameter is not very reliable.
I don’t know if interpolation rounding errors are avoidable as I’ve experienced the same in Superpolator and UFO Stretch even with perfect masters. In an OCD manner, I typically check all instances and correct rounding errors that are typically only 1 unit errors, sometimes 2 units which occur in stem widths and sidebearings. I don’t know if Frode is seeing more significant rounding errors. These are more obvious in symmetrically designed or spaced glyphs.
I’ve always wished for a feature that would scan all glyphs and colorcode/flag inconsistencies in horizontal and vertical stem widths or symmetrically designed/spaced glyphs by group. Meaning uppercase stems would be checked against each other separate from lowercase etc. Of course sometimes those inconsistencies are intentional and they could be ignored.
Generally, 1u differences are not displayed by rasterisers. The difference between e.g. 59 and 60 units is evened out by hinting algorithms that try to unify similar things.
Nice, that looks excellent and definitely along the lines of what I was thinking. Thanks for the link!