Bug 132527

gnome-terminal seems to have similar trouble, readily apparent when
you try to select text containing Japanese characters.  Is this the
same issue?

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.

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.

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.

Tested xchat-2.4.0-3 with pango-1.6.0-4. The horizontal spacing
problem still exist.

Created attachment 105488 [details]
screenshot of xchat with pango

I'm not planning to fix this for FC3.

Also unsuitable for RHEL4 GA or even U1?

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)

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?

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.

Just a "me too": this makes xchat unusable in CJK locale for example.

Moving to FC5Target, as FC4 is 'done', barring release blockers that
pop up.

Crude and dirty work-around here, but untested:

http://sourceforge.net/tracker/index.php?func=detail&aid=1204916&group_id=239&atid=100239

Is this still happening in FC devel?

This appears to be fixed now finally in FC devel. :)

Fixed for Ja, Ko and *_IN but not zh_TW and zh_CN. Strange.

I guess that not having this assigned to owen might increase the chances of this
getting fixed.

Lawrence, this looks fixed to me for Chinese input with fc6,
could you doublecheck, please? :)

Tested with xchat-2.6.0-6 and pango-1.13.4-2. Looking very good now. :-)

Unfortunately seems to be broken again in FC6 final. :-/

*** Bug 181892 has been marked as a duplicate of this bug. ***

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.

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).

Still happens with xchat-2.8.4-4.fc8.

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.

This looks fixed to me in current rawhide (pre-F9).

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

(I assume the actual fix was probably in pango.)

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

requested by Jens Petersen (#27995)

Actually it is still visible at least for zh_CN in F11...

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

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

moving back to rawhide

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

still happens with xchat-2.8.8-4.fc14.x86_64 on ja

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

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.