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