DejaVu, Liberation Mono, Noto Mono, Tlwg Mono, Oxygen Mono, Bitstream Vera Mono: Combining diacritics out of place

This also affects Droid Sans Mono.

This bug also affects Courier New and Andale Mono provided by the ttf-mscorefonts-installer package, and DejaVu Mono has other buggy behavior (see http://web.mit.edu/keithw/www/badcombine3.html), so there may be a more general problem with TrueType rendering of Unicode combining characters.

I tried with all the mentioned fonts in Ubuntu 10.10 and only Andale Mono shows the behaviour reported. Courier New, Droid Sans Mono and Liberation Mono display the combination as: "a´e", i.e. the accent is not combined with either character.

msttcorefonts is under a license that doesn't permit modification.

While going through this issue. I found though Liberation Mono does not have U+301 character in font. But it still has combined character i.e. aacute U+00E1

harfbuzz-ng and pango-view renders it perfectly. So this should be fixed in gnome-terminal.

$./hb-view /usr/share/fonts/liberation/LiberationMono-Regular.ttf "áe"

$printf ""áe"\n" > out
$ pango-view --font=/usr/share/fonts/liberation/LiberationMono-Regular.ttf out

both this gives me perfect rendering.

I’m on Ubuntu 13.04, for me, pango-view --font='Liberation Mono' test-diac renders incorrectly (with the acute over e, not a). It’s not only gnome-terminal that is affected — gedit, mousepad, xterm, firefox too.

Precomposed letters with accents are a workaround, but it only works for Latin and Greek letters. For Cyrillic and other scripts, precomposed forms do not exist in Unicode. For consistency, I prefer using combining accents exclusively, and reporting any bugs that arise.

I believe, when a character is absent in a font, pango takes it from another font that does have it. Does this behavior extend to combining diacritics? If so, reproducibility of this bug depends on which other fonts are installed, and which font gets selected to provide the incorrectly positioned combining acute accent as fallback.

How would I go about tracking down that font?

Status changed to 'Confirmed' because the bug affects multiple users.

I tested this on Ubuntu 14.10 running gnome-terminal version 3.6.2 (with UTF-8 encoding). I tried producing a captial "I" with strikethrough:

echo -e 'I\U0336'

The following font worked correctly:
 - Ubuntu Mono
 - Courier 10 Pitch
 - Droid Sans Mono
 - Free Mono
 - TlwgMono
 - TlwgTypo
 - Ubuntu Mono

The following fonts displayed the strikethrough incorrectly on the following character:
 - Dejavu Sans Mono
 - Liberation Mono
 - Monospace
 - Nimbus Mono L

See also this question:

http://askubuntu.com/questions/643568/displaying-unicode-strikethrough-in-gnome-terminal

For the Droid fonts, use fonts-noto instead, as it supersedes the earlier Droid project.

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854149.

This is still broken in Ubuntu 18.04 bionic. It's notoriously annoying with text or filenames coming from OSX, which keeps diacritics separate from the character they're combined with, also for characters that have a distinct unicode code point for the combined variant.

My test case: echo -e 'a\u0308a'

Correct rendering: äa
(That's what I see with: Courier, Cousine, DejaVu Sans Mono, FreeMono, Hack, Monospace)

Incorrect rendering: aä
(That's what I see with: Andale Mono, Bitstream Vera Sans Mono, Courier 10 Pitch, Courier New, Liberation Mono, Mitra Mono, Nimbus Mono L, Noto Mono, Oxygen Mono, Tlwg Mono, Tlwg Typo, Ubuntu Mono)

Correction: "Hack Bold" renders correctly, "Hack Regular" doesn't.

Maintainer of the fonts-hack Debian package here. I can't reproduce the issue with fonts-hack 3.003-3 on Eoan, I get the expected result, i.e.:

* Two grapheme clusters are displayed: Latin small letter a with acute accent, Latin small letter e.

On which Ubuntu release are you observing it?

Vera fonts won’t be developed further — see DejaVu

Status changed to 'Confirmed' because the bug affects multiple users.

This is a problem even at the desktop level. With the gnome desktop font set to the default 'Ubuntu 11' if I use an app (gImageReader in my case, see also https://github.com/manisandro/gImageReader/issues/613) to write certain decomposed characters (e.g. \u0069\u0300), they are not properly combined on the screen. This is a bad user experience. I've switched to 'DejaVu Sans 11' as a workaround, as it seems to handle everything correctly so far. However, the related DejaVu Sans Mono Book still messes this up (e.g. in gnome-terminal and gedit), but on different combined characters. So for monospace needs I've found FreeMono to cover the most ground (pkg: fonts-freefont-ttf). Try this, while switching between the default gnome-terminal font (Ubuntu Mono?) and DejaVu Sans Mono Book:

$ echo -e '\u0069\u0300\u0020\u0254\u0327'
ì ɔ̧

The ì renders correctly while the open o + cedilla doesn't, both here and with the terminal font set to DejaVu Sans Mono Book, but if you switch to the default font in the terminal the open o + cedilla renders correctly while the ì renders with both the dot and the grave accent on top of each other, rather than the dot disappearing like it should.

I would guess that the related font definitions (Ubuntu Regular/Mono, DejaVu Sans Mono, possibly others) are simply incomplete when it comes to these less common character combinations.

font-manager has been very helpful for side-by-side comparisons of sample text in multiple fonts.