Multiple masters and glyphs requiring remove overlap on export

Ori Ben-Dor
Ori Ben-Dor Posts: 386
in Technique and Theory
In order to interpolate properly, different masters have to be compatible (same number of nodes, same order, etc.).

On the other hand, type designers usually construct glyphs with overlapping contours and let the font editing software remove those overlaps on export.

How do you solve (in practice, workflow wise) the problem that arises—that if you don't control the remove overlap process, then the resulting masters might not be compatible?
Tagged:

Comments

  • Paul Hanslow
    Paul Hanslow Posts: 175
    Im simplifying this a great deal but lets say a file contains a Light and Bold master and an interpolated Regular weight. The glyphs in the Light and Bold masters contains the same amount of nodes and the same path direction etc. Therefore the interpolated Regular instance will be accurate as its position is defined between the Light and Bold master weights.

    Upon export this data is compiled so three files are exported: the Light, the Bold and the Regular. You're left with three files which have most likely had their overlaps removed. The overlaps in the working file will remain though, and exporting the file will not remove the overlaps. However this hasn't always been the case as I believe FontLab4 or 5 use require 'removing overlaps' in the master weight before export. 

    Hypothetically, if you were to import the three separate files back into a a font design application their interpolation may be broken as the number of nodes for each glyph may no longer be consistent due to the removable of overlaps. 

    You can export a Variable font file (TTF?) without removing overlaps, but this will only interpolate correctly if the nodes and contours of each glyph is constant in the masters.

    To summarise, the working file should have consistent start nodes, path direction orientation, and contour ordering in each master within to achieve accurate outlines for the interpolated instances when exporting the font.

    I hope this makes sense.
  • James Puckett
    James Puckett Posts: 1,998
    Paul Hanslow said:
    To summarise, the working file should have consistent start nodes, path direction orientation, and contour ordering in each master within to achieve accurate outlines for the interpolated instances when exporting the font.
    Yes.
  • Ori Ben-Dor
    Ori Ben-Dor Posts: 386
    1. If the end product is some predefined specific intermediate(s), such as the Regular in Paul's example, then the export process can first interpolate, then remove overlap. That would solve my problem, as far as I see. Is that how FL VI, Glyphs and RoboFont behave?

    2. But what if the end product is a variable font? In this case there's no interpolation step as part of the export process. So does a variable font basically mean bye bye to working files with overlaps?
  • Jens Kutilek
    Jens Kutilek Posts: 364
    Yes, I think all three editors can (optionally) remove overlaps automatically before exporting a font.

    For variable fonts, there has been a discussion about the same issue recently.
  • Mark Simonson
    Mark Simonson Posts: 1,739
    2. But what if the end product is a variable font? In this case there's no interpolation step as part of the export process. So does a variable font basically mean bye bye to working files with overlaps?
    You can have overlaps in variable fonts. No need to remove them.
  • Ori Ben-Dor
    Ori Ben-Dor Posts: 386
    Very interesting! I didn't even consider the possibility that variable fonts just left all those overlaps there.

    Do rasterizers usually remove overlap on the fly when they lay out text? If not, outline effect is no longer possible (at least with live text), for instance. Isn't that a problem? Aren't there other problems like that?
  • Thomas Phinney
    Thomas Phinney Posts: 2,896
    Yes, that is how rasterizers work on variable fonts.

    Yes, it creates problems for outline effects, if the machinery doing the effect isn't smart enough to remove overlap first. This is in essence a new requirement for variable fonts, that not all the infrastructure deals with smoothly, as yet.
  • Paul Hanslow
    Paul Hanslow Posts: 175
    Yes, it creates problems for outline effects, if the machinery doing the effect isn't smart enough to remove overlap first. This is in essence a new requirement for variable fonts, that not all the infrastructure deals with smoothly, as yet.
    Which is a bit of a pain in the butt.   :s

Categories