Red Hat Bugzilla – Bug 129541
changes font when typing different scripts on the same line
Last modified: 2014-03-25 20:50:47 EDT
Description of problem:
Typing numberic 0-9 is displayed in the font that is inconsistant with
the font after typing any alphabet after the number.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Log in zh_TW (Traditional Chinese) from gdm
3.enter any number follow by an alphbet
See Screen Shots
Should resume in zh_TW font, or uses english font for ascii
Please see screen shot.
Created attachment 102557 [details]
Please note the changes in the font after alpabets are typed after numbers.
Font selection is hard. Yes, the behavior you observe is a
little disturbing, but the alternatives are worse.
Well I agree on your saying. And I love the way it starts using
english monospace font glyphs too. Pardon my reopening, for letting me
illustrate one more case:
- The space's spacing is not the same hence the align of editing of
each line is different.
- test case
- type 4 spaces and then type "- 1234"
- type 4 spaces and then type "- abcd"
Notice the line that changed to English monospace font, the space's
spacing is larger than the previous line. Well it is okay for browsing
etc. But when it goes down to email composing, or editing text file
layout then it may affect users. Attached is the screenshot.
Created attachment 102601 [details]
Screenshot of illustrating the space's spacing case.
Created attachment 103150 [details]
Created attachment 103151 [details]
xchat with pango 1.4.0-2
Downgraded pango on my machine from 1.5 to 1.4 and the difference between the
xchat screenshot varies quite a lot.
Having read through my comments earlier, I think I am not very clear
on the result. :-(
So I would just like to add that with pango 1.5 in the ja_JP locale,
you can noticed that most of the charcters at the end of each line are
cut off. Also, changing the style on the same line, like in between
regular style and bold, there is no spacing between those glyphs,
which is not very ideal.
I don't think the last comments have anything to do with the rest
of this bug.
Might be related to:
Well, it shows the same behaviour on all CJK (maybe others as well),
and it only happens on new pango (1.5.2). Old pango (1.4.X) are fine.
Well, really, I don't think it's related to the font selection
issue. Can you file a separate bug?
Filed bug 131218 in regards to the characters truncating problem.
Created attachment 103677 [details]
a pango 1.4.1 screenshot for comparison on comment #4 screenshot
In pango 1.4.1, the space are in same value, so they are aligned to each other.
Created attachment 103679 [details]
loading the same file in gedit with pango 1.5.2 - lines are misaligned
Comment #3 from Behdad Esfahbod (pango developer, points: 20)
2006-06-16 03:46 UTC [reply]
That's not a bug. If you login with Chinese, Pango expects Chinese. When you
enter English, it chooses the best font for English. It has no way to know
that you are going to type English in advance.
*** This bug has been marked as a duplicate of 321113 ***
This bug can be closed.
It is still a big problem if you look at comment #13. Idea here maybe use
English glyphs for ASCII area, so that you won't have different glyphs for the
same character in the same document.
(In reply to comment #16)
> It is still a big problem if you look at comment #13. Idea here maybe use
> English glyphs for ASCII area, so that you won't have different glyphs for the
> same character in the same document.
That's suboptimal. If you have different languages, you want the digits match
their surrounding language for font. I opened another gnome bug to fix the
issue observed in comment #13:
This bug is also a part reason why we have a serious rendering/cursoring problem
in firefox pango support. It is bug 149991 - will cc' you on the bug as well..
I don't think firefox+pango can hit this issue.
I guess it is unlikely that this will ever be fixed for RHEL4?
Shall we just close this? It is fixed in Fedora 9, I believe.
(In reply to comment #20)
> I guess it is unlikely that this will ever be fixed for RHEL4?
> Shall we just close this? It is fixed in Fedora 9, I believe.
Yep. Unlikely. Go for it.