Are overlaps ok in VF fonts ?

[WeiH]

Last I remember, having overlaps would show up as a thin white line in some environments... It would make certain situations a lot easier to handle to have overlaps in place... (thinking especially when diagonals meet, like in 'k'). What's the latest on having overlaps for variable TTFs?

[Stephen Nixon]

Overall, issues around rendering with overlaps have gotten much better. I very rarely see problems anymore.

In some scenarios, it may be nice to avoid overlaps. For instance, if you want users to easily be able to use fonts as outlines in apps like Sketch or with CSS like -webkit-text-stroke, you may want to avoid overlaps in common letterforms.

However, it is basically impossible to avoid overlaps entirely in drawing, and FontMake keeps them in output variable fonts so as not to break interpolation compatibility. Beyond diagonals like the k & x, there are bigger reasons. Any diacritics with multiple components or contours that overlap, like ø, ł, ç, etc, would be fairly silly (or potentially impossible, depending on the design) to draw for interpolation without any overlaps. This also extends to currencies ($, €, etc) and probably many other symbols. It would probably be possible to draw a variable font with few or no overlaps, but probably not worth it, most of the time. It would reduce the possibility of using components, which would in turn dramatically increase filesize (as one example, I helped reduce the woff2 filesize of Inter by about 25%, just by keeping components in the built VF).

I do recommend removing overlap in static fonts, so if a user wants a design using outlines, they can use your static fonts. But for drawing a variable font, I say go wild. :)

[Stephen Nixon]

Oh, one thing I forgot to mention: exterior overlaps should probably be avoided, as these render poorly in many situations.

That is, contours can be overlapped, so long as this overlap has a "corner," rather than an overlap that is on the outside of the overall letter shape.

Below, pink arrows point to the "blobs" that come from exterior overlaps in a variable font. These are due to antialiasing "doubling up" on two contours. Basically, a pixel of 50% black + another pixel of 50% black = a pixel of 100% black.

On Thursday, October 3, 2019 at 3:14:14 AM UTC-4, WeiH wrote:

[Stephen Nixon]

Final thing: a very helpful tool to test work-in-progress (or complete) fonts in Chrome browser, across any website, is Type-X (https://github.com/arrowtype/type-x). 

You could make one test version of a font with overlaps, and try another without overlaps. With Type-X, you could then apply those fonts to different websites, to test a variety of font sizes, colors, and styles for rendering differences (and other things, like readability, spacing, etc).

On Thursday, October 3, 2019 at 3:14:14 AM UTC-4, WeiH wrote:

[WeiH]

Thank you once again for you thorough answer. This very helpful. I'm still not sure what exactly external overlap means? is it that that section is just covering the entire shape, rather if it had been just a small corner overlap it would be ok?

[Adam Twardoch (Lists)]

I think "external" means overlaps between two different contours, while the other ones mean overlaps within one contour.

I consider this a bug in rendering, still. There was wide agreement that overlaps need to be permitted in VF. Overlaps between contours are just as important as overlaps between contours. If you have an "a" or "n", you'll want to make it from two contours so you can make precise changes in positions of BCPs (handles). Also, sometimes as weight increases, a node or handle of one such contour (e.g. top left of the right part of "n") ends up inside the other (left stem). 

If these contours are still drawn separately, that's a bad rendering bug that needs to be reported to the makers of the renderer.

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/d3d1e52a-d6f4-4a56-996e-668c7e55b066%40googlegroups.com.

[Stephen Nixon]

Wei: "I'm still not sure what exactly external overlap means?"

Thanks for asking for clarification, Wei! When I say exterior overlap, I am referring to overlaps that happen between two contours, which overlap along a smooth part of the outer edge of a glyph. 

Exterior overlap probably isn't the best term for this, but I can't think of anything better. I'm happy for someone to suggest something more clear. Perhaps "edge overlaps" might be the better term...?

In any case, some diagrams will help clarify what I am referring to:

I was drawing glyphs like this, and eventually noticed issues.

These issues seem to be resolved by removing overlap along smooth edges.

This happens in other fonts, too. Here is Markazi Text. The problem is worse on "normal" pixel density screens, around 144 DPI.

Here's a look at the construction of the /M in Markazi Text, showing problematic and fine overlapping. The "Exterior Corner" overlap is something that may or may not cause problems, but which I mostly try to avoid and/or minimize.

Here's a diagram trying to show a very zoomed-in look at why antialiased pixels "double up" like this, to cause those rendering issues.

Adam: "that's a bad rendering bug that needs to be reported to the makers of the renderer."

I agree, though I'm not sure how long this sort of rendering issue will take to resolve. I think I was told once that it may significantly slow down text rendering if contours have to be interpreted before rendering, and because speed is so highly prioritized by text renderers, that may mean that this issue goes unresolved for some time. So, for now, I'm avoiding exterior overlaps / edge overlaps.

I'm on macOS, so that's where I see this issue. It is less noticeable in large text and on high-DPI screens, but for body text and especially on normal-DPI screens, these edge blobs really distort text shaping and are very distracting. A big frustration for me is that Apple's bug reporting system is very closed, so I have no idea whether they know about this issue or not.

Let me know if I can explain anything better, here! 

[WeiH]

Thank you Stephen!! I understand now, this was so helpful, 'edge overlaps' makes more sense I think