[OTVar] Best solution of interpolating inverted glyphs

Belleve Invis
Belleve Invis Posts: 269
in Technique and Theory
Hi all.
It might look stupid but I am wondering what is the best way to interpolate inversed glyphs like these (taken from Adobe-Japan1-6).

Dealing with the inverted glyphs looks non-trivial, considering that when designing an MM font we use a lot of stroke overlaps, so how the negative space changes during interpolation may be really complex.

Comments

  • Gustavo Ferreira
    Gustavo Ferreira Posts: 8
    use components?
  • Belleve Invis
    Belleve Invis Posts: 269
    Gustavo Ferreira said:
    use components?
    It does not work directly since the "hole" may be constructed from overlapping contours (for variations, of course). Under the non-zero filling rule, directly combining the "hole" and the outer contour would result in a situation that the overlapping parts of the "hole" component being visible. Removing overlaps for the "hole" would make it non-interpolable if there are complex topology changes.
  • John Hudson
    John Hudson Posts: 3,186
    edited April 2018
    .
  • Belleve Invis
    Belleve Invis Posts: 269
    An example of complex situations. The topology of the ink changed significantly between weights.
  • Mark Simonson
    Mark Simonson Posts: 1,734
    edited May 2018
    This is an incredibly interesting problem, and surprising that I've not seen it discussed before. I'm not sure what the solution could be other than fundamentally changing the way fill/non-fill works in digital outlines (edit: that is, allowing overlapping paths).

    Short of that, the only thing I can think of is using a pair of layered fonts. Color variable fonts are not a thing yet, are they?
  • Mark Simonson
    Mark Simonson Posts: 1,734
    edited May 2018
    I suppose you could swap glyphs at the point(s) where the non-ink shapes begin to overlap.
  • Russell McGorman
    Russell McGorman Posts: 262
    What about adding the enclosing rectangle after interpolating?
  • Mark Simonson
    Mark Simonson Posts: 1,734
    That would work if he was generating instances for static fonts, but not for a variable font.
  • Belleve Invis
    Belleve Invis Posts: 269
    Mark Simonson said:
    This is an incredibly interesting problem, and surprising that I've not seen it discussed before. I'm not sure what the solution could be other than fundamentally changing the way fill/non-fill works in digital outlines (edit: that is, allowing overlapping paths).

    Short of that, the only thing I can think of is using a pair of layered fonts. Color variable fonts are not a thing yet, are they?

    I think supporting Boolean operations in GLYF would be a better solution to this kind of problems. I've read the Spec and there are some unused bits in GLYF, so I wrote this, and it could be a starting point: https://gist.github.com/be5invis/5df85378b02e8bb955309f1e59ceb041

  • John Hudson
    John Hudson Posts: 3,186
    Ooh, I like that idea.
  • Thomas Phinney
    Thomas Phinney Posts: 2,886
    Whatever the solution is, it should apply to both TrueType and PostScript outlines.
  • John Hudson
    John Hudson Posts: 3,186
    Whatever the solution is, it should apply to both TrueType and PostScript outlines.
    The latter would be Adobe's responsibility within CFF2 (or CFF3?). The approach @Belleve Invis suggests, for example, could be applied to either outline format, but couldn't be done at a level above the glyph definition, which means in the glyf table for TTF and in the CFF* table for CFF OTF.

    [For the record: I think we should stop calling CFF outlines 'PostScript'.]
  • Peter Constable
    Peter Constable Posts: 161
    John Hudson said:
    [For the record: I think we should stop calling CFF outlines 'PostScript'.]
    Or keep using statements like the following?

    "One good source for sTypoAscender in Latin based fonts is the Ascender value from an AFM file."
  • Belleve Invis
    Belleve Invis Posts: 269
    edited May 2018
    Thomas Phinney said:
    Whatever the solution is, it should apply to both TrueType and PostScript outlines.
    For CFF(3?) we could add new operators to combine layers. Like this:
    <Content layer background> endlayer 
<Content layer hole>       endlayer
001 boole                             // Subtraction
endchar
    But, hey, if we supported cubic curves in glyf, why do we need CFF?
  • Mark Simonson
    Mark Simonson Posts: 1,734
    edited May 2018
    Support for something like this would help with other kinds of designs, such as variable fonts with outline effects.
  • John Hudson
    John Hudson Posts: 3,186
    But, hey, if we supported cubic curves in glyf, why do we need CFF?
    Totally with you on cubic curves in the glyf table, including hybrid glyphs containing both cubic and quadratic curves, so designers can select the best curve type for the design detail. That would be brilliant.

    I wonder if CFF might still provide size benefits in terms of its built-in compression?
  • Thomas Phinney
    Thomas Phinney Posts: 2,886
    Each format has unique advantages to its hinting model, as well. So... more than the curve format.
  • Belleve Invis
    Belleve Invis Posts: 269
    Moved the draft to here → https://github.com/be5invis/ot-cubic-boolean-extension

Categories