Bug 44023 - Combining diacritics drawn too low on capital letters
Summary: Combining diacritics drawn too low on capital letters
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.4.4 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2011-12-21 10:07 UTC by Yao Ziyuan
Modified: 2016-10-02 13:04 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:

LibreOffice Writer in a Fedora 16 virtual machine showing Á À Â Ã Ā (66.12 KB, image/png)
2011-12-21 10:07 UTC, Yao Ziyuan
AbiWord in a Fedora 16 virtual machine showing Á À Â Ã Ā (51.74 KB, image/png)
2011-12-21 10:14 UTC, Yao Ziyuan
ODT and screenshots showing rendering under v3304 through v4132. (405.32 KB, application/zip)
2013-11-22 23:11 UTC, Owen Genat (retired)
Screenshot showing rendering under LOv4304 (same for LOv4162, LOv4263, and LOv4400 2014-09-05). (56.16 KB, image/png)
2014-09-06 05:15 UTC, Owen Genat (retired)

Note You need to log in before you can comment on or make changes to this bug.
Description Yao Ziyuan 2011-12-21 10:07:34 UTC
Created attachment 54647 [details]
LibreOffice Writer in a Fedora 16 virtual machine showing Á À Â Ã Ā

In LibreOffice Writer under Linux, if you type the capital letter "A" and then a Unicode combining character (e.g. U+0301 which draws an acute mark above the preceding character), you will see the acute mark drawn too low, overlapping with "A".

To reproduce this bug, start "charmap" in GNOME or "kchar" in KDE, type "A" in the charmap program's "Text to copy" field, and then go to the combining character U+0301 and insert it to the "Text to copy" field. Now you should have an Á (A with an acute mark). Now copy this text into LibreOffice Writer, and now you see, whatever font you use, the acute mark is always drawn too low, crossing with "A".

This is caused by LibreOffice/OpenOffice's Linux font rendering engine, I think. Windows versions of LibreOffice/OpenOffice don't have this bug at all.

The attached screenshot is a LibreOffice Writer in a Fedora 16 virtual machine showing Á À Â Ã Ā. Each of them is the capital letter A plus a combining character (U+0301, U+0300, U+0302, U+0303, U+0304). You can see the diacritics are drawn too close to "A". The font used is Liberation Serif, but this bug applies to all fonts.
Comment 1 Yao Ziyuan 2011-12-21 10:14:40 UTC
Created attachment 54648 [details]
AbiWord in a Fedora 16 virtual machine showing Á À Â Ã Ā

In contrast, AbiWord running in the same Fedora 16 virtual machine can show the same text much better.
Comment 2 Christian Lohmaier 2011-12-21 17:01:42 UTC

Although Libreation Sans is a very bad example, as it doesn't contain combining diacritics and LO has to fall back on another font and thus mix fonts with very likely different metrics (one font for the base letter, and a different font for the diacritic).

Works fine with graphite-based fonts like Gentium

Not sure whether Abiword "cheats" by replacing the combining sequence by the respective single letter...
Comment 3 Yao Ziyuan 2011-12-21 18:01:26 UTC
Christian Lohmaier: Now I tested Gentium fonts. "Gentium" and "GentiumAlt" still have this problem; "Gentium Basic" and "Gentium Book Basic" don't have the problem.

Also, I don't think AbiWord cheats, because from my AbiWord screenshot you can see the third A's diacritic (^) is a little left to where it should be.
Comment 4 Yao Ziyuan 2011-12-23 17:25:25 UTC
Christian Lohmaier: If "mix fonts" as you said is the case, maybe LO should force the base letter to use the diacritic's font.
Comment 5 Yao Ziyuan 2012-01-22 09:38:34 UTC
*** Bug 27977 has been marked as a duplicate of this bug. ***
Comment 6 Yao Ziyuan 2012-01-22 09:41:18 UTC
As a suggestion, if Graphite/SIL fonts are so crucial for LibreOffice/Linux's proper text rendering, why doesn't LibreOffice ship with SIL fonts and choose one SIL font as LO's default document font?
Comment 7 Owen Genat (retired) 2013-11-22 23:11:29 UTC
Created attachment 89657 [details]
ODT and screenshots showing rendering under v3304 through v4132.

This report basically deals with the Unicode FAQ "Q: Yes, I can represent (for example) X with circumflex by use of X with a combining circumflex: <U+0058, U+0302>. But it doesn't display correctly. The circumflex comes out misplaced, not properly over the “X”.":


There has been steady improvement in LO (and possibly the fonts shown in the attached) with respect to the handling of combining characters. The attached ODT was created under Ubuntu 10.04 x86_64 running v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a and provides an example in 36pt of A (U+0041) combined with these combining marks indicated in the description:

- Combining grave accent (U+0300) 
- Combining acute accent (U+0301) 
- Combining circumflex accent (U+0302) 
- Combining tilde (U+0303) 
- Combining macron (U+0304) 

... using the main fonts (not all variants e.g., condensed, mono, etc.) that are distributed with LO v4.1.3.2 as well as Arial and Times New Roman. This document was then viewed under the same OS using these versions of LO (not ideal I know, but still indicative):

- v3.3.0.4 OOO330m19 Build: 6
- v3.4.6.2 OOO340m1 Build: 602
- v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v3.6.7.2 Build ID: e183d5b
- v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a

Screenshots from each are shown. Obviously the earlier version are not going to render all fonts well as many were not included until a later version (thus there is some font substitution). Even so the results are encouraging. Here is a summary:

v3.3.0.4 - Gentium Basic, Gentium Book Basic OK
v3.4.6.2 - no change
v3.5.7.2 - Linux Libertine G OK, Linux Biolinum G partially OK (tilde and macron display incorrectly)
v3.6.7.2 - Liberation Sans, Liberation Serif both have regression in tilde
v4.0.6.2 - DejaVu Sans, DejaVu Serif, Arial, Times New Roman OK, Source Code Pro error in general display
v4.1.3.2 - Liberation Sans, Liberation Serif, Open Sans, PT Serif, Source Code Pro OK

The only outstanding rendering issue as at v4.1.3.2 is with Linux Biolinum G for the tilde and macron characters indicated. Obviously this is not a comprehensive combining character test and so other (untested) fonts and character combinations may render differently.
Comment 8 Owen Genat (retired) 2013-11-22 23:12:58 UTC
Laszlo Nemeth added to the CC list for this bug as Linux Biolinum G is one of his fonts, so he may be able to indicate if I have made a mistake somewhere in my testing or if this is a known problem with the font or LO.
Comment 9 Paul Hsieh 2014-09-03 14:27:30 UTC
In v4.2.5.2 for Windows it looks almost completely corrected except for:


in the Linux Biolinum G font.
Comment 10 Owen Genat (retired) 2014-09-06 05:15:11 UTC
Created attachment 105825 [details]
Screenshot showing rendering under LOv4304 (same for LOv4162, LOv4263, and LOv4400 2014-09-05).

I can confirm comment 9 that in the Linux Biolinum G font these characters:

- Combining tilde (U+0303) 
- Combining macron (U+0304) 

... are still not rendered correctly. Tested under GNU/Linux using:

- v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a
- v4.2.6.3 Build ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21
- v4.3.0.4 Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0
- v4.4.0.0.alpha0+ Build ID: 652b807658a54cd2ccd04ebc6900d2cf1ce85015 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-09-05_01:32:46

All versions render the same as shown in the attached screenshot.
Comment 11 QA Administrators 2015-10-14 19:57:47 UTC Comment hidden (obsolete)
Comment 12 Buovjaga 2016-01-30 14:26:26 UTC
Still repro.

Note: in character map program, you can search (ctrl-f) for U+0303 and U+0304 to quickly locate them.

Win 7 Pro 64-bit Version:
Build ID: 9784ff3d878eaa21491fbd779e57d7d4710f5449
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-01-30_01:31:57
Locale: fi-FI (fi_FI)
Comment 13 Khaled Hosny 2016-10-02 13:04:24 UTC
There is nothing for us to fix here, all are font bugs.