Overlap in variable fonts

Should I remove overlap and perform other ordinary clean up operations before exporting a variable font? It seems a sane thing to do, however FontLab doesn't do it automatically on export despite the proper checkboxes being checked.

Comments

  • Hrant H. PapazianHrant H. Papazian Posts: 1,528
    I would be paranoid to the moon letting it do it automatically anyway.
  • Adam JagoszAdam Jagosz Posts: 351
    It seems reasonable as it might ruin master compatibility. So, shortly: yes?
  • Mark SimonsonMark Simonson Posts: 1,137
    Variable fonts are allowed to have overlaps. No reason to remove them.
  • Thomas PhinneyThomas Phinney Posts: 1,584
    Quite right.

    There are times when things can be made to interpolate nicely with overlapping paths, but removing the overlaps will create problems. That's why overlaps are completely legal in variable fonts, and FontLab VI does not remove them by default.
  • Hrant H. PapazianHrant H. Papazian Posts: 1,528
    edited June 6
    Are they removed at some point internally, or are they simply all rendered? If the latter, what happens with contours of opposite directions overlapping? (I sort of remember having this discussion way back, but can't remember the conclusion...)

    BTW no risk with older RIPs? (I'm guessing they can't handle varfonts anyway?)
  • Thomas PhinneyThomas Phinney Posts: 1,584
    The OS-level support for variable fonts must be sending flattened instance-fonts to the printer drivers, with the result that old RIPs are just fine. It may also remove overlap as part of this process.
  • Hrant H. PapazianHrant H. Papazian Posts: 1,528
    It may also remove overlap as part of this process.
    I don't trust that.
  • John HudsonJohn Hudson Posts: 1,652
    edited June 6
    Are they removed at some point internally, or are they simply all rendered? If the latter, what happens with contours of opposite directions overlapping?

    The winding rules specified to be used with OT variable fonts should not be a problem in this respect. This is one of the key reasons for the CFF2 table spec, because Adobe's CFF format couldn't handle the overlaps. In a variable font, you typically want an overlaps whenever a curve or diagonal is intersected by another stem, e.g. the crossbar of A or the slash of Ø, in order to get smooth interpolation of the curve or diagonal.

    There's one case that turns out to still present problems, which is when you have overlapping elements of a glyph knocked out of a solid, e.g.

    This issue is being looked at.

    I don't trust that.
    I trust a system that knows about variable fonts and can instantiate them for download to a printer to remove the overlaps more than I trust the printer to correctly interpret overlaps.

  • Hrant H. PapazianHrant H. Papazian Posts: 1,528
    edited June 6
    My instincts tell me this is a topological Pandora's Box...
    Whoever is looking at it, good luck.
    I trust a system that knows about variable fonts and can instantiate them for download to a printer to remove the overlaps more than I trust the printer to correctly interpret overlaps.
    Sure.
    Neither holds a candle to a human finessing a grid that I think we agree is quite coarse.
  • Jens KutilekJens Kutilek Posts: 230
    I usually draw glyphs with lots of overlaps. It would be silly to leave all of them in the shipped font, because the contours would contain a lot more points than necessary. I would remove all overlaps that do not influence interpolation before exporting the font.

    Overlaps that influence interpolation are usually crossing diagonals (as in A), or lines crossing curves, as in Ø.

    There is no readymade way to automate this, though. It could be done by a machine: Make a copy of the glyph, and compare the two versions 1) interpolate, then remove overlaps and 2) remove overlaps, then interpolate. If they are identical, or sufficiently similar, overlaps can be removed in the variable font.

    Of course, there are some glyphs which don't interpolate anymore if you remove overlaps. They need to be kept as is, too.

    None of these are necessary for interpolation:



    32 points, versus 28 when overlaps are removed.
  • Hrant H. PapazianHrant H. Papazian Posts: 1,528
    edited June 6
    Jens Kutilek said:
    there are some glyphs which don't interpolate anymore if you remove overlaps.
    My concern is exactly that the desire/need to interpolate could end up degrading another dimension of quality. But it could be an incorrect hunch.

    Digression:
    That said, allowing overlapping contours and/but rendering them faithfully according to direction, along with supporting boolean operations, enables a very powerful new way to implement notan. What I'm getting at is, imagine a black countour with a white one cutting into it (while not itself appearing black outside the overlap). What boggles the mind a bit more is contemplating how layering should factor in... This is something I've been "working on" :-) since 2013, and I know it sounds a bit sci-fi, but it would be the final emancipation of notan from the black.
  • John HudsonJohn Hudson Posts: 1,652
     imagine a black countour with a white one cutting into it

    That's doable in a colour font, if you're talking about actual black and white, but presumably you want the 'white' to be the background colour of whatever ground to which you apply the font.
  • Hrant H. PapazianHrant H. Papazian Posts: 1,528
    Indeed.
Sign In or Register to comment.