The better angels of my nature tell me to just leave this as it is, as
this is archived and may be referenced in the future ...
What you're suggesting, if I understand correctly, is that the existing
flags available in the glyf implementation, and a new flag made
available in the CFF2 implementation, be maintained not on the basis of
whether a glyph has overlap, but by the designer based on whether the
FreeType renderer in particular does a good job at rendering the glyph
without the flag.
This isn't unimaginable, but it comes close. What I would say is: If
this is how those flags should be used, that convention should
presumably be included in the portions of the OpenType/Open Font Format
specification that document such flags. And this is just not how
contemporary specifications work, and any such suggestion would almost
certainly be rejected. It's the job of the downstream stacks to either
deal with things as they come or filter up ideas that can be generalized
-- and bought into -- by all the various parties, including the various
other implementations. It is not the job of the specification to bend to
the unilateral decisions of given implementations.
Anyway, given that there will be CFF2 fonts that have no such flag, any
of which could have glyphs with overlap, what should be done about
those? Should I add FT_OUTLINE_OVERLAP to outlines extracted from such
fonts or not?
Skef
On 12/19/23 11:26, Alexei Podtelezhnikov wrote:
Practically speaking I don't think this could wind up being a "this glyph has overlap"
flag, as in CFF2 overlap is valid anywhere. If something were added it would be more like a
"this glyph doesn't have overlap, you can optimize the rendering" flag.
The 4-fold speed difference is not an optimization it is a liability which
should be taken explicitly. Some overlaps at single points are not that
noticeable. Only long runs along the axes are bad. So I disagree with default
oversampling even for variation fonts.
