Re: The current state of rendering and overlap

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.