Re: The current state of rendering and overlap

[Hin-Tak Leung]

I think I agree with this - the spec should not bend on limitations/quirks/bugs in freetype. It isn't the role of the spec to recommend fonts to be built in with special "hints", just because one implementation, in its current state, can't render satisfactorily without those "hints".

And, we must stress, "in its current state". Who knows, somebody might decide to ripe it all out and rewrite it differently, etc. :-).

On Tuesday, 19 December 2023 at 23:55:42 GMT, Skef Iterum <iterumllc@skef.org> wrote:

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.