Re: The current state of rendering and overlap

[Alexei Podtelezhnikov]

> 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 is partly correct. The genesis of rasterizers is not that broad.
There are only so many methods for calculating the pixel coverage. (1)
Microsoft, reading between the lines in TrueType specifications, is
oversampling using their original bi-level rasterizer. That is using a
4x4=16 grid in each pixel and counting how many pixels are inside a
contour. This is slow but immune to the overlap artifacts. They do not
care about this issue because it is not their problem and they let the
SIMPLE_OVELAP flag go too easily in the variation fonts. (2) Rather
accurate trapezoid integration of coverage originated in LibArt and
adopted by FreeType, but not only FreeType. There are some hints that
Apple uses it as well. That is about it. I don't think Adobe does
something completely different. The integration methods need
oversampling (or, rather, resolution increase) only when it is needed
for the overlaps. Otherwise they are pretty accurate and much faster
than sampling. So when I advocate for taking into account the
integration rasterizer, I don't just mean FreeType, but even that is a
huge market share (Android, etc.).

> 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.

I tried to give more justice to the OVERLAP flags in the specs:
https://github.com/MicrosoftDocs/typography-issues/issues/626
For what it is worth there is only two viable methods for the font
rasterization, one of which needs the overlap flags explicitly when
needed.

> 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?

I would not do it by default.