Re: The current state of rendering and overlap
On Tue, Dec 19, 2023 at 1:02 PM Skef Iterum wrote: > CFF2 is released, has been for years. As far as I know there's no solid > convention for ignoring unrecognized operators in a CharString, so this > would be CFF2 minor 1 at best. Which would be years out in terms of > support. > > 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. > > Behdad - there's no provision for a relevant flag in VARC currently, > correct? (I'm not sure there was one in the glyf-based system, as I > don't remember a place where the flag would have lived.) > Correct. > Skef > > On 12/19/23 10:53, Alexei Podtelezhnikov wrote: > > Why? The sequence 0x0c 0x40 is reserved and not used for example. > > > > > >> I'm afraid the horse has left the barn as far as that goes. > >> > >> Skef > >> > >>> On 12/19/23 04:23, Alexei Podtelezhnikov wrote: > >>> 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. > >
Re: The current state of rendering and overlap
> > 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". s/freetype/any coverage integration/ ;) AFAIK this bug is present in macOS, but they might use FreeType, but then FreeType is everything except Windows.. Some quirks then. ;)
Re: The current state of rendering and overlap
> 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.
Re: The current state of rendering and overlap
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 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.
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.
Re: The current state of rendering and overlap
> 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. Let me explain that not all overlaps are bad - see attached "X". The middle is acceptable because the contours intersect at single points rather than edges. Therefore the artifacts are isolated at single pixels and barely noticeable. The situation at the top is horrible because the stems extend through the serif bars up to the edge. Multiple adjacent pixels are improperly dark. If only the font designers end the stems in the middle of the serif bars, nobody would even notice anything. The font designers should be aware of this and decide if FT_OUTLINE_OVERLAP is truly necessary. [image: ftgrid.png]
Re: The current state of rendering and overlap
CFF2 is released, has been for years. As far as I know there's no solid convention for ignoring unrecognized operators in a CharString, so this would be CFF2 minor 1 at best. Which would be years out in terms of support. 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. Behdad - there's no provision for a relevant flag in VARC currently, correct? (I'm not sure there was one in the glyf-based system, as I don't remember a place where the flag would have lived.) Skef On 12/19/23 10:53, Alexei Podtelezhnikov wrote: Why? The sequence 0x0c 0x40 is reserved and not used for example. I'm afraid the horse has left the barn as far as that goes. Skef On 12/19/23 04:23, Alexei Podtelezhnikov wrote: 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.
Re: The current state of rendering and overlap
I'm afraid the horse has left the barn as far as that goes. Skef On 12/19/23 04:23, Alexei Podtelezhnikov wrote: 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.
Re: The current state of rendering and overlap
> > CFF2 is released, has been for years. As far as I know there's no solid > convention for ignoring unrecognized operators in a CharString, so this would > be CFF2 minor 1 at best. Which would be years out in terms of support. We can do it in days for FreeType, then it is a matter of upgrading downstream.. Behdad floats cubic outlines in TrueType, which is a much larger undertaking but not impossible. > > 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. > > Behdad - there's no provision for a relevant flag in VARC currently, correct? > (I'm not sure there was one in the glyf-based system, as I don't remember a > place where the flag would have lived.)
Re: The current state of rendering and overlap
Why? The sequence 0x0c 0x40 is reserved and not used for example. > I'm afraid the horse has left the barn as far as that goes. > > Skef > >> On 12/19/23 04:23, Alexei Podtelezhnikov wrote: >> 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.
Re: The current state of rendering and overlap
Hi Behdad >> >>> 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. >> CFF was even-odd. CFF2 is non-zero winding. >> This is about the coverage calculation rather than the fill rule. Suppose >> two contours cover half-pixel each. The integral coverage depends on how >> they overlap over that pixel. The only way to reasonably deal with it is >> oversampling. > > I might be wrong, but I think cairo simplifies the shape, merging the > overlaps. I think some font tools do that then saving static instances from variable fonts. It is a not easy on the fly.
Re: The current state of rendering and overlap
On Tue, Dec 19, 2023 at 11:25 AM Alexei Podtelezhnikov wrote: > > 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. > > > CFF was even-odd. CFF2 is non-zero winding. >> >> This is about the coverage calculation rather than the fill rule. > Suppose two contours cover half-pixel each. The integral coverage depends > on how they overlap over that pixel. The only way to reasonably deal with > it is oversampling. > I might be wrong, but I think cairo simplifies the shape, merging the overlaps.
Re: The current state of rendering and overlap
> > 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. >> CFF was even-odd. CFF2 is non-zero winding. >> This is about the coverage calculation rather than the fill rule. Suppose two contours cover half-pixel each. The integral coverage depends on how they overlap over that pixel. The only way to reasonably deal with it is oversampling.
Re: The current state of rendering and overlap
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 wrote: > CFF was even-odd. CFF2 is non-zero winding. > > behdad > http://behdad.org/ > > > On Tue, Dec 19, 2023 at 9:50 AM Hin-Tak Leung > 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 < >> apodt...@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. >> >> >> https://www.w3.org/TR/WOFF2/#p1 >> >> WOFF2 is moving towards accepting explicit overlap flags. Perhaps CFF2 >> can spare a reserved operator or a two-byte operator. >> >
Re: The current state of rendering and overlap
CFF was even-odd. CFF2 is non-zero winding. behdad http://behdad.org/ On Tue, Dec 19, 2023 at 9:50 AM Hin-Tak Leung 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 < > apodt...@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. > > > https://www.w3.org/TR/WOFF2/#p1 > > WOFF2 is moving towards accepting explicit overlap flags. Perhaps CFF2 can > spare a reserved operator or a two-byte operator. >
Re: The current state of rendering and overlap
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 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. https://www.w3.org/TR/WOFF2/#p1 WOFF2 is moving towards accepting explicit overlap flags. Perhaps CFF2 can spare a reserved operator or a two-byte operator.
Re: The current state of rendering and overlap
> >> >> 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. https://www.w3.org/TR/WOFF2/#p1 WOFF2 is moving towards accepting explicit overlap flags. Perhaps CFF2 can spare a reserved operator or a two-byte operator.
Re: The current state of rendering and overlap
> 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.
Re: The current state of rendering and overlap
> It seemed like the simplest answer to this was to mark all outlines > extracted from a CFF2 font as FT_OUTLINE_OVERLAP, because there's no > inexpensive method of detecting it. And so I added code to do that and > verified it was heeded in ftsmooth.c -- but the ftgrid output didn't > look any different. FT_OUTLINE_OVERLAP mitigates the artifact but does not completely remove it. The 4x4 resolution increase might still have some residual artifacts. Further increasing it is impractical and prohibitive from the performance standpoint. I think this is the issue in your example. The most egregious overlaps which cover half-pixels are dealt with quite successfully. Alexei
Re: The current state of rendering and overlap
I'm not necessarily looking for a "fix", I just want to verify that the CFF2 side is doing what it can and should be. I did run into the thread Cosimo links to in my research, but of course CFF doesn't have either of the glyf flags or any equivalent. 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. Skef On 12/19/23 03:04, Werner LEMBERG wrote: I'm afraid I don't have an exact overlap-less example handy because the equivalent static font also hints a bit differently, hiding the issue. But I'm referring to the fact that the upper serifs cover the upper parts of the stems but the pixels above the stems are darker, so the overlapping area appears to be double-counted. Thanks. I'm not sure that this can be improved at such low resolutions. Alexei? Werner
Re: The current state of rendering and overlap
> I'm afraid I don't have an exact overlap-less example handy because > the equivalent static font also hints a bit differently, hiding the > issue. But I'm referring to the fact that the upper serifs cover the > upper parts of the stems but the pixels above the stems are darker, so > the overlapping area appears to be double-counted. Thanks. I'm not sure that this can be improved at such low resolutions. Alexei? Werner
Re: The current state of rendering and overlap
Hey Skef, This thread might be of interest to you https://github.com/fonttools/fonttools/issues/2059 On Tue, Dec 19, 2023 at 10:58 AM Skef Iterum wrote: > I'm afraid I don't have an exact overlap-less example handy because the > equivalent static font also hints a bit differently, hiding the issue. > But I'm referring to the fact that the upper serifs cover the upper > parts of the stems but the pixels above the stems are darker, so the > overlapping area appears to be double-counted. > > Skef > > On 12/19/23 01:58, Werner LEMBERG wrote: > >> I've been looking into various FreeType issues related to the > >> combination of CFF2 and hinting. As part of that I ran into the > >> phenomenon represented in the attached capture of ftgrid. Which, to > >> summarize, has a rendering artifact caused by overlap. > > What exactly is the artifact? I don't see it. Do you have a > > comparison image of the same outline without overlaps? > > > > > > Werner > >
Re: The current state of rendering and overlap
I'm afraid I don't have an exact overlap-less example handy because the equivalent static font also hints a bit differently, hiding the issue. But I'm referring to the fact that the upper serifs cover the upper parts of the stems but the pixels above the stems are darker, so the overlapping area appears to be double-counted. Skef On 12/19/23 01:58, Werner LEMBERG wrote: I've been looking into various FreeType issues related to the combination of CFF2 and hinting. As part of that I ran into the phenomenon represented in the attached capture of ftgrid. Which, to summarize, has a rendering artifact caused by overlap. What exactly is the artifact? I don't see it. Do you have a comparison image of the same outline without overlaps? Werner
Re: The current state of rendering and overlap
> I've been looking into various FreeType issues related to the > combination of CFF2 and hinting. As part of that I ran into the > phenomenon represented in the attached capture of ftgrid. Which, to > summarize, has a rendering artifact caused by overlap. What exactly is the artifact? I don't see it. Do you have a comparison image of the same outline without overlaps? Werner
