[OTVar] Best solution of interpolating inverted glyphs

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

  • use components?
  • Belleve InvisBelleve Invis Posts: 231
    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 HudsonJohn Hudson Posts: 1,398
    edited April 29
    .
  • Belleve InvisBelleve Invis Posts: 231
    An example of complex situations. The topology of the ink changed significantly between weights.
  • Mark SimonsonMark Simonson Posts: 926
    edited May 1
    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 SimonsonMark Simonson Posts: 926
    edited May 1
    I suppose you could swap glyphs at the point(s) where the non-ink shapes begin to overlap.
  • Russell_McGormanRussell_McGorman Posts: 172
    What about adding the enclosing rectangle after interpolating?
  • Mark SimonsonMark Simonson Posts: 926
    That would work if he was generating instances for static fonts, but not for a variable font.
  • Belleve InvisBelleve Invis Posts: 231
    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 HudsonJohn Hudson Posts: 1,398
    Ooh, I like that idea.
  • Thomas PhinneyThomas Phinney Posts: 1,037
    Whatever the solution is, it should apply to both TrueType and PostScript outlines.
  • John HudsonJohn Hudson Posts: 1,398
    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 ConstablePeter Constable Posts: 159
    [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 InvisBelleve Invis Posts: 231
    edited May 2
    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 SimonsonMark Simonson Posts: 926
    edited May 2
    Support for something like this would help with other kinds of designs, such as variable fonts with outline effects.
  • John HudsonJohn Hudson Posts: 1,398
    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 PhinneyThomas Phinney Posts: 1,037
    Each format has unique advantages to its hinting model, as well. So... more than the curve format.
Sign In or Register to comment.