|Summary:||Invalid assumptions about character width|
|Product:||[Fedora] Fedora||Reporter:||Owen Taylor <otaylor>|
|Component:||xchat||Assignee:||Jonathan Blandford <jrb>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Version:||14||CC:||ddumas, djr, i18n-bugs, llim, mail, petersen, tagoh, wtogami|
|Target Milestone:||---||Keywords:||i18n, MoveUpstream, Reopened|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-06-06 07:55:15 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
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: http://sourceforge.net/tracker/index.php?func=detail&aid=1204916&group_id=239&atid=100239
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, pango-1.14.6-3.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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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: xchat-2.8.8-10.fc16.x86_64 pango-1.29.4-1.fc16.x86_64
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.