GNOME Bugzilla – Bug 360189
incorrect rendering of combining character(s) with some fonts
Last modified: 2013-05-22 10:45:40 UTC
please see the description of the bug that I originally filed for firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=354475 especially comments #5 and #4 and attached screenshots and testcase. I am filing this bug for pango as I see the problem with all GTK2 applications and only with them. Maybe this is a more general GTK2 problem. Originally I thought that GVim compiled with GTK2 was not affected, but I was wrong, it has the same problem only combined with another problem of its own, which possibly was meant as work-around for this bug. I will attach some screenshots to demonstrate GVim issue. I will also copy the testcase and relevant screenshots from the firefox bug entry to this one.
Created attachment 74142 [details] test-case a test case for this bug you can test through your browser by simply viewing the attachment and you can copy/paste the test word into input/edit field of GTK2 applications
Created attachment 74143 [details] incorrect rendering in GTK2 firefox using bitstream vera font
Created attachment 74146 [details] correct rendering with Charis SIL font in GTK2 firefox
Created attachment 74148 [details] correct rendering in opera with Bitstream Vera font
Created attachment 74149 [details] GVim rendering with Bistream Vera font
Created attachment 74150 [details] GVim rendering with Charis SIL font this example shows that while with Vera font a stress mark appeared to be close to proper position (it was still slightly off), with Charis SIL font (and Arial) it is placed way wrong
Please reopen only if you can reproduce in gedit. It's not a Pango/Gtk+ bug if it only happens in Firefox and GVim.
Created attachment 74344 [details] bug demonstrated in gedit with bitsream vera sans font I don't mean to sound counter-productive, but it took me less than a minute to start gedit, copy/paste the tescase string from attachment (id=74142) and grab a screenshot. BTW, I see that renderring with Bitsream Vera Serif is much closer to expected than with Bitsream Vera Sans.
re-opening as requested
(In reply to comment #8) > Created an attachment (id=74344) [edit] > bug demonstrated in gedit with bitsream vera sans font > > I don't mean to sound counter-productive, but it took me less than a minute to > start gedit, copy/paste the tescase string from attachment (id=74142) [edit] and grab > a screenshot. And guess what? my gedit shows it properly. > > BTW, I see that renderring with Bitsream Vera Serif is much closer to expected > than with Bitsream Vera Sans.
> > And guess what? my gedit shows it properly. Do you have the same version of GNOME2/GTK2 ? This bug may be version-specific. Did you configure the same font in gedit (Bitstream Vera Sans) ? This bug is font-specific. What additional environment information can I provide to track this issue ? OS: FreeBSD 6.1-RELEASE-p2 i386 Software (all is built from sources using FreeBSD ports): gedit-2.14.4 gtk-2.8.20 pango-1.12.4 png-1.2.12_1 libiconv-1.9.2_2 freetype2-2.1.10_5 expat-2.0.0_1 gettext-0.14.5_2 glib-2.10.3 fontconfig-2.3.2_5,1 XFree86-libraries-4.5.0 libXft-2.1.7_1 glitz-0.4.4_1 bitstream-vera-1.10_2 cairo-1.0.4_1
Created attachment 75368 [details] bug demonstrated in gedit with bitsream vera sans font after upgrade to gnome 2.16.1 I have upgraded to the latest GNOME version offered through FreeBSD ports: gedit-2.16.1 freetype2-2.2.1_1 fontconfig-2.3.2_6,1 libXft-2.1.7_1 XFree86-libraries-4.5.0 bitstream-vera-1.10_2 cairo-1.2.4 pango-1.14.7 gtk-2.10.6_1 libgnome-2.16.0 The problem is still there.
Created attachment 77031 [details] Python program demonstrating the rendering bug The attached program demonstrates the rendering of я́ in different fonts. On my machine, Bitstream Vera Sans Mono and Verdana renders the glyph wrong. Most other fonts render it correctly.
the bug is still here. I have: gtk+-2.10.9 pango-1.14.10 libXft-2.1.12 freetype-2.3.1 Accent is rendered above the incorrect letter in most of the fonts with several exceptions (works ok with Arial, Tahoma and few other fonts). Tested in gedit, evolution and firefox. tested string: "Сла́вянск (укр. Слов'я́нськ)" accent should be above third letter in 1st word and after 5th (not counting apostroph sign) letter in second.
With GNOME 2.18.2 and pango 1.16.4 (built from FreeBSD ports, again) situation is much better. Using python demonstration program in attachment (id=77031) I now get the following results: 1. all proportional fonts except for Verdana are rendered correctly; 2. Verdana seems to be a very special case, maybe some specific work-around should be hardcoded. see details in this wikipedia article: http://en.wikipedia.org/wiki/Verdana 3. with monospace fonts a character is rendered in one place and a combining mark is rendered in the next place, not sure if this is an expected behavior with such fonts and such a test program. at least the behavior is consistent between latin and cyrillic characters unlike the old times. BTW, I am not sure how status of this bug should be updated now, but it really should not be "unconfirmed" given how many confirmations are given in the followups.
The monospace behavior is also font-dependent: I see the accent on the correct character in DejaVu Sans Mono, and the accent on the next character in Liberation Sans Mono (perhaps because its metrics were cloned from Courier New?).
Just in case, about the Verdana font issue: http://en.wikipedia.org/wiki/Verdana#Combining_characters_bug