OVERLAP_SIMPLE and OVERLAP_COMPOUND

[apodtele]

OVERLAP_SIMPLE and OVERLAP_COMPOUND may have been used in the past to enforce the non-zero winding rule in the PostScript printer drivers. There is another problem with rendering overlaps that requires oversampling. The flags can be used to alert about the overlaps and trigger oversampling in the totally different context unrelated to the winding rule.

1. The current flag description places too much emphasis on the winding rule interoperability.

The OVERLAP_SIMPLE flag is used by some rasterizer implementations to ensure that a non-zero-fill algorithm is used rather than an even-odd-fill algorithm. Implementations that always use a non-zero-fill algorithm will ignore this flag.

I propose removing the second suggestive sentence and simply say

The OVERLAP_SIMPLE flag is used by some rasterizer implementations to enforce a non-zero-fill algorithm or resolve any other rendering issues.

2. The table specifically references Apple

(See the discussion of “Overlapping contours” in Apple’s specification for details regarding behavior in Apple platforms.)

Other platforms (FreeType) can use it differently. I propose moving this at the end of the paragraph below the table or removing altogether because the description is already self-sufficient.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: b2a9a6a1-a9b9-0864-8982-322da821389e
• Version Independent ID: a42612e3-dc1d-f980-fe4a-4880d1fd0086
• Content: glyf - Glyf data table - Typography
• Content Source: typographydocs/opentype/spec/glyf.md
• Product: typography
• GitHub Login: @PeterCon
• Microsoft Alias: PeterCon

[apodtele]

To properly reflect the FreeType use case, the proposed changes might read like this.

Simple Glyph Flags
0x40 | OVERLAP_SIMPLE | Bit 6: This is an optional warning flag that contours in the glyph description may overlap. When used, it must be set on the first flag byte for the glyph. Some rasterizers might depend on this flag for proper overlap rendering. See additional details below.

Some rasterizer implementations can use the OVERLAP_SIMPLE flag to ensure that a non-zero-fill algorithm is used rather than an even-odd-fill algorithm to avoid wrong overlap appearance. (See the discussion of “Overlapping contours” in Apple’s specification for details regarding behavior in Apple platforms.) In addition, some rasterizer implementations based on cumulative pixel coverage need this flag to mitigate artifacts at the intersection pixels.

Note that variable fonts often make use of overlapping contours and some implementations might only check this flag in non-variable fonts. This has implications for tools that generate static-font data for a specific instance of a variable font. If a glyph has overlapping contours in the given variation instance, then the tool should either set this flag in the derived glyph data, or else should merge contours to remove overlap of separate contours. This flag can be used in order to provide broad interoperability of fonts when glyphs have overlapping contours.

Composite Glyph Flags
0x0400 | OVERLAP_COMPOUND | Bit 10: This is an optional warning flag that the components of the compound glyph may overlap. When used, it must be set on the flag word for the first component. Some rasterizers might depend on this flag for proper overlap rendering. See additional remarks, above, for the similar OVERLAP_SIMPLE flag used in simple-glyph descriptions.

[apodtele]

[reposting from #922]

There are two kinds of rasterizers in use:

• Microsoft, for example, uses 4x4 sampling inside each pixels and counts how many sixteenths are inside of a shape. Overlaps do not mater with this method and, naturally, there is little incentive to take the OVERLAP flags seriously.
• Apple and FreeType, on the other hand, use trapezoid integration inside each pixel while walking along the contour. In this method, overlaps produce incorrect coverage integral and they can benefit from the explicit OVERLAP flags to mitigate the issue.

Importantly, besides the even-odd and non-zero fill rule, this is also about smudging at the overlapping edges. See the macOS issue microsoft/cascadia-code#362. FreeType now actively uses the OVERLAP flags to mitigate the smudging issue.

The issue is especially nasty when two contour edges overlap and produce consecutive runs of incorrect pixels. Overlaps with simple contour crossings are not too bad because a single incorrect pixel is hardly noticeable at the corner. Even though variable fonts frequently use overlaps, the designers should be educated about the nasty edge smudging. Then they could decide if the OVERLAP flag is appropriate or not. Assuming overlaps in all variable glyphs is a bad idea because mitigation is computationally costly and unnecessary if overlaps do not reach edges.

In summary, optional OVERLAP flags at the discretion of a font designer is a good thing in both variable and static fonts. They help the trapezoid rasterizers deal with smudged edges.

I want to hope that the conflict of interest between different rasterizers can be resolved in the specifications.

Cc: @lemzwerg @bungeman

[HinTak]

"...implementations based on cumulative pixel coverage need this flag..." and "...mitigation is computationally costly..." are implementatins details, don't really belong to a specification?

The last sentence "I want to hope that the conflict of interest between different rasterizers can be resolved in the specifications." also sounds a lot like wishful thinking: (1) I am not saying other rasterizers don't adhere to specs, but adhering to specs is not necessarily their main or only concerns... (2) there will always be conflict of interests - vendors will and do intentionally behave differ from each other, as a business advantage...

This sounds a lot like "let's push these restrictions into the spec, and hope others will obey the restrictions (restrospectively, and put in audits, and enhancements to enforce the restrictions)"....

[apodtele]

@HinTak Please do not mix my explanation from Jan 8, 2024 and proposal from Sept 21, 2020. In fact, I propose to remove implementation details and do not add any restriction. I agree that implementation details limit the scope of the flag, which remains optional.

"In addition, some rasterizer implementations based on cumulative pixel coverage need this flag to mitigate artifacts at the intersection pixels."

Anything wrong with this sentence?

[apodtele]

The original language dates back to 90s and focuses on the fill rule only. No one could have anticipated that overlaps may have issues with anti-aliased rendering back then. All I am asking is to modernize the language to reflect the current state-of-the-art.

[PeterCon]

See the OT 1.9.1 alpha for draft revisions addressing this issue.