freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The current state of rendering and overlap


From: Cosimo Lupo
Subject: Re: The current state of rendering and overlap
Date: Tue, 19 Dec 2023 17:12:21 +0000

Note that freetype does not use the overlap flags to determine the path fill rule (winding vs even-odd), it always uses winding for TT or CFF2 variable fonts, as the spec mandates; the discussion here is about freetype using the (TT glyf only) overlap flags to enable what Alexei calls "4x4 bilevel oversampling" in order to mitigate the effects of increased pixel coverage where paths overlap inside a glyph. I'm just summarizing the above linked fonttools issue, but I don't fully understand the technical details of this rendering technique.
CFF2 doesn't have an equivalent mechanism to say "this glyph may contain overlaps", which prompted this specific email thread.

On Tue, Dec 19, 2023 at 5:03 PM Behdad Esfahbod <behdad@behdad.org> wrote:
CFF was even-odd. CFF2 is non-zero winding.



On Tue, Dec 19, 2023 at 9:50 AM Hin-Tak Leung <htl10@users.sourceforge.net> wrote:
This is the same as the winding rule concept (overlap _once_ = wounded twice) ... I seem to remember one of them is even-odd and the other is non-zero, and quite fundamental difference between truetype and cff. 

On Tuesday, 19 December 2023 at 13:54:21 GMT, Alexei Podtelezhnikov <apodtele@gmail.com> wrote:




It's easy enough to add FT_OUTLINE_OVERLAP to any glyph loaded from a
CFF2 font. Whether that makes sense is one thing I'd like advice about.
There's currently no such code.

I would suggest that CFF2 invent a special charstring to mark overlaps
with FT_OUTLINE_OVERLAP only when necessary. Let us know to implement
it in FreeType.



WOFF2 is moving towards accepting explicit overlap flags. Perhaps CFF2 can spare  a reserved operator or a two-byte operator.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]