Fix bad OS X overlaps

[m4rc1e]

When we instantiate the static fonts from the VF, we keep the glyph overlaps. We do not remove them because we'd end up breaking the VTT hinting. In certain versions of OS X, some overlaps appear to be filled incorrectly. This is due to the rasteriser.

To solve this issue, I used Browserstack to check which glyphs had the overlap issue. I've then removed the overlaps for these glyphs and rehinted them with VTT.

For more info on the rasteriser issue, https://github.com/twardoch/test-fonts/blob/master/varia/160413-EvenOddTT/README.md

[dberlow]

I’ve added what’s below to Twardoch’s post, from discussion here; twitter.com/arrowtype/status/1312023807939444736?s=21

Solutions look like the far right below:

Would you like us to look at the 4 Roboto glyphs and test?

Beyond quality rendering everywhere the file size issue is my other concern.

[m4rc1e]

Would you like us to look at the 4 Roboto glyphs and test?

If you'd like to test this PR, Github actions has just finished generating the fonts for this PR, you can download them here

[dberlow]

Sorry not to be clear, there was only one solution, (the far right column), bringing solutions to all the glyphs.

[m4rc1e]

I'm a bit lost here.

You're looking at a pull request where I've fixed the OS X glyph overlap issue by simply removing the offending overlaps and retaining the MM compatibility.

Another solution is to use the technique which is shown in the image, furthest on the right, as you pointed out. However, what possible side effects does it cause? how do different rasterisers treat it? can we risk using this technique when the family is requested 40 billion times a week?

The reason I opted for simply removing the overlaps is because it's the safe choice. We know how rasterisers are going to treat it.

[dberlow]

Mark,

I agree completely with you on this for Roboto. “The reason I opted for simply removing the overlaps is because it's the safe choice. We know how rasterisers are going to treat it.”

“However, what possible side effects does it cause? In the case of the four glyphs shown here, there would be no side effects using this technique beyond the need to rehint.

“…how do different rasterisers treat it?” For future reference, rasterisers will treat the split overlapped bar the same as the existing “A” in Roboto, as it has the same topology — instead of two contours intersecting twice, one contour is intersecting two other contours once. Roboto’s “A” confirms proper rendering, as splitting the “Lambda” into two diagonals does the same thing in all rasterizers as splitting the bar and leaving the “Lambda” as a single contour.

Amstelvar was where this was discovered, by splitting the crossbar.

“…can we risk using this technique when the family is requested 40 billion times a week?” Yes, and future fonts we are working on take further advantage of this contour structure and composites to keep file sizes smaller x 40 billion. In the case of “Theta”, e.e. we’ll be using the “O”, compositing the bar, and saving on glyph, hint and gvar data.

[mikedug]

Hi Mark, I proofed the fonts that you linked to above, in VTT. There are two broken glyphs. GID 2683 and 2684. This problem is in both the VF and all of the static fonts.

GID 2683 and 2684 are both composite glyphs, which use as a reference, glyphs where you removed overlaps. By removing the overlap, the point numbers changed. The composite glyphs GID 2683 and 2684 still use the old reference points.

this is how the updated code should read for these two glyphs. The hinting I assume should be corrected in the VF first.

GID 2683 / UNICODE 04EA

REFERENCES GID 685 / UNICODE 0472

existing composite code using incorrect reference points USEMYMETRICS[] OFFSET[R], 685, 0, 0 OFFSET[R], 107, 296, 317 SVTCA[Y] CALL[], 73, 22, 1, 1, 106, 86 SHC[2], 3 SHC[2], 4

new Code with updated reference points. USEMYMETRICS[] OFFSET[R], 685, 0, 0 OFFSET[R], 107, 296, 317 SVTCA[Y] CALL[], 79, 0, 1, 1, 106, 86 SHC[2], 3 SHC[2], 4

GID 2684 / UNICODE 04EB

REFERENCES GID 686 / UNICODE 0473

existing composite code using incorrect reference points USEMYMETRICS[] OFFSET[R], 686, 0, 0 OFFSET[R], 107, 136, 2 SVTCA[Y] CALL[], 69, 10, 1, 1, 165, 86 SHC[2], 3 SHC[2], 4

new Code with updated reference points. USEMYMETRICS[] OFFSET[R], 686, 0, 0 OFFSET[R], 107, 136, 2 SVTCA[Y] CALL[], 65, 0, 1, 1, 165, 86 SHC[2], 3 SHC[2], 4

[m4rc1e]

Thanks Mike. I'll update the VTT instructions.

[m4rc1e]

Thanks Mike, I've just pushed a fix. Here's how it now looks on Win 10 Chrome

---

@dberlow, I'd personally love us to use the cut cross bar technique since it will be much quicker. However, we've had issues with the Blink renderer when points share the same x,y coordinates. We pushed DeepMind Serif a year back which ended up looking like this in Google Slides

https://github.com/googlefonts/dm-fonts/issues/6

This "k" consists of two paths, one for the stem, the other for the diagonal. When the diagonal and the stem touch, it produces the above artefact. Our solution was to nudge the diagonal one point to the right so it no longer touches the stem.

I'm concerned that cutting the crossbar may produce similar results.

[mikedug]

thanks Marc, could you point me to the fonts, so I can do a sanity check/proof?

[m4rc1e]

@mikedug You can find them here, https://github.com/TypeNetwork/Roboto/suites/1472009082/artifacts/25340555

The fonts are built by Github actions. Each time we submit a PR or a commit is pushed to an open PR, the fonts are rebuilt automatically. This stops us from uploading fonts that may be out of date or faulty. If you click on the "Checks" tab at the top (next to the commits tab), you'll see the results from Github actions.

Also, thank you so much for reviewing this PR!

[mikedug]

thanks Mark. Can confirm the offset fixes in both VF and Static fonts. thanks. In addition proofing looks ok.

Mike

[dberlow]

Hey Mark,

....that’s a very, very unusual “k”. Is this repo available, or can you tell me if this Is a quadratic or cubic bezier? I would like to see what Amstelvar “A” looks like In that environment.

Shared coordinates are not allowed in cubics, but are in quadratics. Also, we’ve been making these particular glyphs from composites to save space, and because the overlap issues don’t effect composite rendering. Even across weights, where the counter of “o” is more open to accommodate the bar, we’re making two contours and composing. So we’re not splitting the bar in these glyphs.

But we’re definitely on the lookout for this issue going forward, so I’d like to see as many possibilities thrown at this one machine that’s doing that “k”, cause that’s how we find out what’s wrong.

On Nov 9, 2020, at 5:31 AM, Marc Foley notifications@github.com wrote:

 Thanks Mike, I've just pushed a fix. Here's how it now looks on Win 10 Chrome

@dberlow, I'd personally love us to use the cut cross bar technique since it will be much quicker. However, we've had issues with the Blink renderer when points share the same x,y coordinates. We pushed DeepMind Serif a year back which ended up looking like this in Google Slides

googlefonts/dm-fonts#6

This "k" consists of two paths, one for the stem, the other for the diagonal. When the diagonal and the stem touch, it produces the above artefact. Our solution was to nudge the diagonal one point to the right so it no longer touches the stem.

I'm concerned that cutting the crossbar may produce similar results.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.