After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704458 - Accent printed on next letter with Liberation Mono font
Accent printed on next letter with Liberation Mono font
Status: RESOLVED OBSOLETE
Product: pango
Classification: Platform
Component: general
1.36.x
Other Linux
: Normal normal
: ---
Assigned To: pango-maint
pango-maint
Depends on:
Blocks:
 
 
Reported: 2013-07-18 11:47 UTC by Pravin Satpute
Modified: 2018-05-22 13:10 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
comparing pango-view, gedit, fontforge-view and hb-view (140.98 KB, image/png)
2013-10-29 06:07 UTC, Pravin Satpute 		Details

Description Pravin Satpute 2013-07-18 11:47:02 UTC 
Description of problem:
Output of gedit differs than pango-view

Version-Release number of selected component (if applicable):
gedit-3.8.3-1.fc19.x86_64

How reproducible:
everytime

Steps to Reproduce:
1. $printf "áe\n"  >> out
2. $pango-view   /usr/share/fonts/liberation/LiberationMono-Regular.ttf out
3. Now type same sequence in gedit, apply Liberation Mono fonts and observe the difference

Actual results:
acute is appearing on next character. 

Expected results:
It should be on "a". Character composition not happening properly. a+ acute = aacute (U+00E1)

Additional info:
Pango and harfbuzz-ng doing this properly. But problem comes with gedit.
Comment 1 Sébastien Wilmet 2013-10-06 14:50:24 UTC 
Thanks for the bug report.

I reassign to pango. On my system:

$ printf "áe\n" > out
$ pango-view out
$ pango-view --font="Liberation Mono" out
$ pango-view --version
pango-view (pango) 1.36.0

With the first pango-view command, the accent is on the 'a'.
With the second pango-view command, the accent is on the 'e'.
Comment 2 Behdad Esfahbod 2013-10-28 20:15:37 UTC 
Perhaps gedit is running against an older Pango?!
Comment 3 Pravin Satpute 2013-10-29 06:07:31 UTC 
Created attachment 258407 [details]
comparing pango-view, gedit, fontforge-view and hb-view

While checking again now pango and gedit gives same output.

But character composition is not happening as it is happening with hb-view. 
Liberation Mono does not have U+0301 but it does has U+E1.

Presently in pango, if character is not present in fonts it is rendering it with fallback font that is Dejavu.

i think hb-view is more intelligent as it looks like if character is not present it is checking for composition form and providing that in output.

./hb-shape /usr/share/fonts/liberation/LiberationMono-Regular.ttf "áe"
[aacute=0+1229|e=2+1229]
Comment 4 Behdad Esfahbod 2013-10-29 09:06:04 UTC 
You are correct.
Comment 5 GNOME Infrastructure Team 2018-05-22 13:10:06 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pango/issues/221.