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 139950 - Handle input text in NFD
Handle input text in NFD
Status: RESOLVED FIXED
Product: pango
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: Big feature
Assigned To: pango-maint
pango-maint
: 165000 169724 322273 354712 397475 (view as bug list)
Depends on: 123406
Blocks:
 
 
Reported: 2004-04-13 17:12 UTC by David Oftedal
Modified: 2012-08-25 17:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Oftedal 2004-04-13 17:12:16 UTC
Display a character followed by a combining character without using a
precomposed form.

What happens is that the character is displayed incorrectly:

If a precomposed form of the character exists in the font it isn't used.

When trying to render the character on its own, Pango only handles one combining
character at a time.

Thus, the character ḗ (e with a macron and an acute) will be rendered as ḗ
(clumsy e with a macron followed by an acute dangling in thin air), because
Pango doesn't use the precomposed variant present in the font.

A character like x̄́ (x with a macron and acute), which doesn't even have a
precompiled variant, should also be rendered as one character and not as two,
but Pango only uses the macron and forgets the second combining character, the
acute.

This is a clear breach with the Unicode standard, which actually tries to move
users away from precomposed characters.
Comment 1 Owen Taylor 2004-06-23 21:09:06 UTC
Making Pango rendering independent of normalization form is a long standing TODO
item; it's unfortunately incredibly difficult to do right. The problem is that
the two obvious approaches fail

 - Require input in NFC; Hard on the application programmer and not backwards
   compatible.

 - Normalize to NFC on input; for editing and selection operations the 
   correspondence of the input text with the rendering glyphs needs to 
   preserved.

So you actually have to do the normalization during rendering.

There isn't a bug for exactly this TODO item, so I'll use this one.
Related bugs:

 bug 123406 (glib): need a way to do unicode normalization in atomic steps
 bug 89449: Better handling of precomposed/combining forms in Hebrew shaper
 bug 101406: Shape marks with base characters 
 
I think it's unlikely I'll get to doing anything on this for 1.6. 
If someone wanted to work on it it would get done faster, though
its not completely clear to me how it should be done, even. 
Bug 101406 has some notes on the interaction of this with font
selection.
Comment 2 David Oftedal 2004-06-23 21:38:52 UTC
Thanks a bunch! I'll be looking forward to the release of future versions then :)
Comment 3 Owen Taylor 2005-01-24 01:00:46 UTC
*** Bug 165000 has been marked as a duplicate of this bug. ***
Comment 4 Denis Jacquerye 2005-03-10 12:37:21 UTC
*** Bug 169724 has been marked as a duplicate of this bug. ***
Comment 5 Owen Taylor 2005-11-24 14:26:10 UTC
*** Bug 322273 has been marked as a duplicate of this bug. ***
Comment 6 Owen Taylor 2006-09-07 12:18:25 UTC
*** Bug 354712 has been marked as a duplicate of this bug. ***
Comment 7 Behdad Esfahbod 2007-01-17 23:14:18 UTC
*** Bug 397475 has been marked as a duplicate of this bug. ***
Comment 8 Fabio Durán Verdugo 2010-12-27 15:08:30 UTC
This bug was reported against a version which is not supported any more. Developers are no longer working on this version so there will not be any bug fixes for it.
Can you please check again if the issue you reported here still happens in a recent version of GNOME and update this report by adding a comment and adjusting the 'Version' field?

Again thank you for reporting this and sorry that it could not be fixed for the version you originally used here.

Without feedback this report will be closed as INCOMPLETE after 6 weeks.
Comment 9 Behdad Esfahbod 2010-12-27 18:37:01 UTC
Will be fixed with harfbuzz.  Working on it.
Comment 10 Behdad Esfahbod 2011-09-06 13:47:17 UTC
Fixed in HarfBuzz already.  We can close when branch merges.
Comment 11 Behdad Esfahbod 2012-08-18 17:51:32 UTC
Closing as HarfBuzz is merged now.