U+0333 and U+0347

[DLasher106]

The glyph for U+0333 should be substantially wider than U+0347. In the Noto fonts, they are currently the same width.

See http://www.unicode.org/versions/Unicode5.1.0/erratafixed.html.

[moyogo]

In fact 0305 0332 0333 033F should have the same behaviour. Each should connect if attached to several base letters in a sequence. For example, with 0333 "a̳m̳i̳" should look like a double underline under the whole word "ami", 0305 with an overline, 0332 with an underline, 033F with a double overline. When used alone, each should roughly be as wide as the base letter it is attached to whereas 0347 should have the same width (or it can have variable width but should never connect).

[TidharC]

I can confirm that U+0333 and U+0347 look essentially the same (see screenshot). Combining overlines (U+0305, U+033F) are sometimes not joined, and neither are combining underlines. The issue becomes apparent with wider glyphs, and with glyphs having extenders above (b, d, ...) or below (q, y, ...).

[nizarsq]

U+0333 and U+0347 currently the same width U+0305 U+0332 U+0333 U+033F Not connecting if attached to several base letters in a sequence I can see the issue reproducible on NotoSerif as well.

[simoncozens]

OK, that's going to be an interesting challenge! Obviously one way to fix it is:

• Remove all the anchors from these glyphs so they appear at a fixed height
• Create ten or so different width variants
• Bin each base glyph by width and sub @width1 uni0333' by uni0333.width1 etc.

But it feels a pretty "heavy" fix for a pretty rare issue. I wonder how other fonts handle it?

[simoncozens]

The only font (at least in the GF catalogue) which handles this nearly correctly is Andika. It has a uni0333 glyph which is wide enough to cover the widest character that it's likely to go under (m), and anchors it underneath the centre of each glyph. You can still trick it, but the solution is probably good enough.

[dscorbett]

See also how Brill handles U+0333 and Amiri handles U+0305.