Bug 132527 - Invalid assumptions about character width
Summary: Invalid assumptions about character width
Alias: None
Product: Fedora
Classification: Fedora
Component: xchat
Version: 14
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jonathan Blandford
QA Contact:
: 181892 (view as bug list)
Depends On:
Blocks: 212512
TreeView+ depends on / blocked
Reported: 2004-09-14 14:53 UTC by Owen Taylor
Modified: 2013-04-02 04:20 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-06-06 07:55:15 UTC

Attachments (Terms of Use)
screenshot of xchat with pango (230.36 KB, image/png)
2004-10-20 02:15 UTC, Lawrence Lim
no flags Details

Description Owen Taylor 2004-09-14 14:53:50 UTC
xchat is assuming that the width of ascii characters is
always constant. However, this isn't true for Pango ... 
for example a space in the middle of Japanese text will get 
a different width then a space in the middle of English text.

This causes problems like the horizontal spacing problem
described in bug 131218.

I'll look at coming up with a patch (a patch is easy,
a patch that doesn't badly hurt performance may be harder)

Comment 1 Warren Togami 2004-10-15 04:40:13 UTC
gnome-terminal seems to have similar trouble, readily apparent when
you try to select text containing Japanese characters.  Is this the
same issue?

Comment 2 Owen Taylor 2004-10-15 15:44:55 UTC
Not meaningfully. vte doesn't use Pango for rendering,
so while it is probably making some sort of invalid assumption
about character width, it isn't directly related to this.

Comment 3 Owen Taylor 2004-10-18 21:58:14 UTC
OK, there is a quick fix ... just remove the ASCII optimization. 
But that gives an unacceptable performance hit for the xchat display
overall. And fixing it better would be a major change to go in at 
this point.

Removing it from YellowPad target bug.

Comment 4 Peter Zelezny 2004-10-19 08:34:23 UTC
A quick fix without performance penalty might be to build your RPMs
with ./configure --enable-xft. I guess you'd loose the multiple fonts
features of pango though.

Comment 5 Lawrence Lim 2004-10-20 02:13:54 UTC
Tested xchat-2.4.0-3 with pango-1.6.0-4. The horizontal spacing
problem still exist.

Comment 6 Lawrence Lim 2004-10-20 02:15:17 UTC
Created attachment 105488 [details]
screenshot of xchat with pango

Comment 7 Owen Taylor 2004-10-20 04:19:25 UTC
I'm not planning to fix this for FC3.

Comment 8 Warren Togami 2004-10-20 04:41:19 UTC
Also unsuitable for RHEL4 GA or even U1?

Comment 9 Owen Taylor 2004-10-20 04:46:48 UTC
I don't have a real fix short of a rewrite of GtkXText. 

You might be able to get a partial fix by using Xft for 
rendering of pure ascii segments as well as the measurement.

But there are also bugs with selection and wrapping in assuming
sum(width of chars in string) == width(string) that make working
on the code unhappy. (And make for a darn inefficient algorithm for
non-ascii where it's laying out each character to find it's width)

Comment 10 Peter Zelezny 2004-10-20 05:32:30 UTC
Owen, could you describe to me the changes in Pango 1.5/1.6? Or point
me to the mailing list archives where it was discussed/implemented?

Is it basically that the width of a space (and only a space?) varies
depending on what chars preceeded it?

So rendering (or measuring) "hello " and "hello"," " could yield
different results?

And this phenomenon can never occur in only ascii (< 0x80) strings?

Comment 11 Owen Taylor 2004-10-20 05:40:01 UTC
As of Pango-1.4, the font selected for neutral characters (such
as spaces, punctuation) will in many cases depend on the script of
adjacent characters. 

This can happen even for ASCII only strings in non-latin locales,
because an isolated neutral character (I think, it's sort of late
at the moment) will get the default language tag, not the Latin
language tag. 

If, for ASCII only strings, you specifically pass
a language tag of 'en' to Pango (by using a different PangoContext,
instead of gtk_widget_get_pango_context(), say. Or by setting
it with a PangoAttribute), then Pango will indeed always produce 
consistent font selection for those strings.

Comment 12 Jens Petersen 2005-02-07 07:27:53 UTC
Just a "me too": this makes xchat unusable in CJK locale for example.

Comment 14 Mike A. Harris 2005-06-02 21:26:08 UTC
Moving to FC5Target, as FC4 is 'done', barring release blockers that
pop up.

Comment 15 Peter Zelezny 2005-06-14 03:54:05 UTC
Crude and dirty work-around here, but untested:


Comment 16 Jens Petersen 2005-09-27 13:38:39 UTC
Is this still happening in FC devel?

Comment 17 Jens Petersen 2005-09-28 09:01:49 UTC
This appears to be fixed now finally in FC devel. :)

Comment 18 Lawrence Lim 2005-11-18 06:26:02 UTC
Fixed for Ja, Ko and *_IN but not zh_TW and zh_CN. Strange.

Comment 20 Matthias Clasen 2006-08-30 21:27:17 UTC
I guess that not having this assigned to owen might increase the chances of this
getting fixed.

Comment 21 Jens Petersen 2006-08-31 04:28:59 UTC
Lawrence, this looks fixed to me for Chinese input with fc6,
could you doublecheck, please? :)

Comment 22 Lawrence Lim 2006-08-31 06:45:22 UTC
Tested with xchat-2.6.0-6 and pango-1.13.4-2. Looking very good now. :-)

Comment 23 Jens Petersen 2006-10-25 08:30:18 UTC
Unfortunately seems to be broken again in FC6 final. :-/

Comment 24 Jens Petersen 2006-10-25 09:17:37 UTC
*** Bug 181892 has been marked as a duplicate of this bug. ***

Comment 25 Xiaohong Wang 2006-10-25 11:12:59 UTC
Tested in RHEL5-Client-20061020.1 with ko or ja locale, xchat-2.6.6-7.el5,
In xchat, enter mix of english, numbers and i18n text, the last few chars would
get missing.

Comment 26 Jens Petersen 2006-10-30 03:52:17 UTC
I tried in vain backing down to pango-1.14.3-1.fc6 (fc6test3), pango-1.14.0-3, 
xchat-2.6.0-6 (fc6test2), pango-1.13.4-2 (fc6test2), and pango-1.13.1-3 (fc6test1).

Comment 27 Jens Petersen 2007-09-06 05:03:09 UTC
Still happens with xchat-2.8.4-4.fc8.

Comment 28 Bug Zapper 2008-04-03 15:39:08 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 29 Jens Petersen 2008-04-10 05:01:09 UTC
This looks fixed to me in current rawhide (pre-F9).

If someone else could also test and confirm that would be cool.

Comment 30 Jens Petersen 2008-04-10 05:03:29 UTC
(I assume the actual fix was probably in pango.)

Comment 31 Bug Zapper 2008-05-14 01:57:01 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 32 Tony Fu 2008-09-10 03:16:40 UTC
requested by Jens Petersen (#27995)

Comment 33 Jens Petersen 2009-05-27 01:43:03 UTC
Actually it is still visible at least for zh_CN in F11...

Comment 34 Bug Zapper 2009-06-09 09:06:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:

Comment 35 Bug Zapper 2010-04-27 11:35:22 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 36 Jens Petersen 2010-05-20 06:43:11 UTC
moving back to rawhide

Comment 37 Bug Zapper 2010-07-30 10:25:15 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:

Comment 38 Akira TAGOH 2010-11-26 02:22:49 UTC
still happens with xchat-2.8.8-4.fc14.x86_64 on ja

Comment 39 Akira TAGOH 2011-11-21 07:50:44 UTC
looks good to me on ja locale tested with:

Comment 41 Akira TAGOH 2012-06-06 07:55:15 UTC
still looks good on f17. this may be related to the font configuration though, it's stable enough since f16 at least. close this so far.

Note You need to log in before you can comment on or make changes to this bug.