GNOME Bugzilla – Bug 321113
Wrong glyph subsituation algorithm for digital characters and punctuations
Last modified: 2007-02-16 02:30:23 UTC
Look at the screenshot of Firefox showing http://cvs.gnome.org/viewcvs/pango (or any likely pages). Although this one is more likely a bug of gecko, but I think it should be fixed in Pango because it involves the font substitution algorithm of Pango.
Created attachment 54555 [details] pango-wrong-font-substitution.png I'm using a virtual font family "Sans" here, while the font substitution series in fontconfig is: Bitstream Vera Sans, AR PL ShangHeiSun Uni. The latter one is a CJK font. It seems that Pango only assumes letters(A-Z,a-z) as latin characters when sustituting Virtual font families, but digits(0-9) and punctions('-','+',\,'(',')',) are looked as non-latin characters. Thus, those characters will be mapped to AR PL ShangHeiSun Uni, because Bitstream Vera Sans does not include those characters(??) IMHO, the mapping result of "Sans", should be exactly the same as the mapping result of "Bitstream Vera Sans", which is the 1st substitute font provided by fontconfig.
Is your gecko engine using Pango? Can you reproduce this in any GNOME application?
Created attachment 54577 [details] pango-substitution-in-rhythmbox.png > Is your gecko engine using Pango? Yes, I'm quite sure Mandriva is one of those distros. > Can you reproduce this in any GNOME application? That is why I'm requesting changing how Pango substitute virtual font families. In fact, normal GNOME applications (such as Yelp) don't have messed up display, but the font substituation is quite the same. Check the screenshot of rhythmbox attached. Although you might not know Chinese, but it is quite reasy to check the fonts being used. Note, this problem does not occurr in real font substitution.
I still don't understand *what* is wrong. What is wrong with the screenshot?
attachment#54577 [details]: The digits and the letters are mapped into different fonts. And, for some reason I don't know, the closing bracket ')' are cut by 1px. attachment#54555 [details]: Due to digits(2005-07-21) and letters are mapped into different fonts, gecko is computing wrong width of certain string segment. The digits (including punctions) are mapped into Chinese fonts, rather than the 1st avaliable substitute font provided by fontconfig.
Forget about gecko problems. As for the rhythmbox one, which version of Pango are you using? We fixed a similar problem. Can you try HEAD please?
Still valid in glib2.9 and pango 1.11.0
Is it a gtk+-2.8 or 2.6?
gtk 2.8. In fact, I'm using Mandriva cooker + gpwgnome(which contains gnome 2. 13).
Ok, this is in fact a feature, not a problem. Your chinese font contains (crappy?) digits and punctuations. Digits and punctuations are Common characters, do not belong to any script. So they are shaped with sorrounding letters, which means Chinese in this case. It would be wrong to use the first font for punctuation, if it does not contain glyphs for the letters. Consider a Chinese only text, won't you open another bug if the punctuation are selected from a different font other than the one used for rendering the text? Your first attachment is showing a different bug though.
Created attachment 55468 [details] gedit.png > So they are shaped with sorrounding letters, which means Chinese in this case. IMHO, consistency is the most important thing. Check the attachment, the font I set is "Monospace 10". When the greater-than sign is inputed, the font is mappped into Chinese font. But when I input another 'a', the whole font becomes "Bitstream Sans Mono" immediately. The font being used to render the same character varies from the surrounding text, which is unacceptable. > Consider a > Chinese only text, won't you open another bug if the punctuation are selected > from a different font other than the one used for rendering the text? No, I won't open another bug. Chinese are using full-width punctions which are completely different from the characters <U+40.
You are really not getting the point. If you run under the Chinese locale, the assumption is that you are going to type Chinese.
The point is the font being used for rendering the same character shouldn't change depending the surrounding text.
Yes it should, for Common characters that do not belong to any particular script. Now please stop arguing over something that is NOTABUG.
> Now please stop arguing over something that is NOTABUG. If the problem affect not only gecko, but also affect xchat(if you want, screenshot follows), it should be considered as a bug. The actural width of rendered text is not the same as what a program could calculate from the context. You say it is a feature?
Now you are talking about another issue, not the font selection. I would be happier if you use another bug report for a new issue. Next, it may be a bug with your fonts as probable as (if not more) that it may be a bug with pango.
Nope. The core problem is just the same: the digits and punctuations are not mapped to the 1st avaliable font, but to 1st avaliable font which is preferred in current locale. Say context "ABC 123". It is highly probably that pango is internally mapping " 123" into font other than "ABC", and that font can not be known by the applicaiton. Although the string "ABC 123" is rendered in same font in most environment, but the when the applications want to calculate the actural width of the context, pango tells applications the *internal* font subsitution result, while in that case, "123" is using a different font than "ABC". As digits and punctuations and not belong to any scripts, why are they mapped as locale dependent? > Next, it may be a bug with your fonts as probable as (if not more) that > it may be a bug with pango. What if the problem occurs in all the distribution and for all the Chinese (probably all the non-latin) users?
I am a non-Latin user. Never had this problem. If you know what's pango doing wrong, go ahead and send a fix please.
Sorry, not all the bug reporters are programmers.
Bug report marked as enchancement should not be closed as invalid.
I don't like arguments, too. But font of those "Common characters" are changing during your typing, this is odd and really annoyed us Chinese users. If you do like this behavior, is it possible to add a switch that determines whether font should follow the context or not, at either run-time or compile-time?
It's not about being a programmer or not, or a switch or whatever. What you are asking doesn't make any sense. It's a computer, it's not a psychic. If you do not run under a Chinese locale, there's no way for Pango to choose Chinese fonts before you start typing Chinese. When you type Chinese on the other hand, all common characters use the Chinese font, and that's not going to change, I'm telling you. If you want Chinese font by default, set your LANG to the Chinese locale. If you don't want Chinese messages, set back LC_MESSAGES to en_US. That's all. Enhancement or not, I'm going to close this as WONTFIX. Do not reopen. If you see any real issue, file another bug. I don't like open bugs around that I cannot work on when I have time, and this definitely ranks number one in that category.
> If you do not run under a Chinese locale, there's no way for Pango to choose > Chinese fonts before you start typing Chinese. But why it changes if Latin letters follows? Do you mean that consistency is less important than a so-called user-friendness?
What is your locale set to?
> What is your locale set to? zh_CN
Then just swap Latin and Chinese in what I wrote: It's not about being a programmer or not, or a switch or whatever. What you are asking doesn't make any sense. It's a computer, it's not a psychic. If you do not run under a Latin locale, there's no way for Pango to choose Latin fonts before you start typing Latin. When you type Latin on the other hand, all common characters use the Latin font, and that's not going to change, I'm telling you. If you want Latin font by default, set your LANG to a Latin locale. If you don't want Latin messages, set back LC_MESSAGES to zh_CN. That's all.
> What you are asking doesn't make any sense. It do make sense, because the behaviour of pango will be more consistence, rather than current vairying from different context. > If you do not run under a Latin locale, there's no way for Pango to choose > Latin fonts before you start typing Latin. There is such a way to achieve that, just mark those common characters as lang:en. > that's not going to change... please fix bug#328374 at first.
(In reply to comment #27) > > What you are asking doesn't make any sense. > It do make sense, because the behaviour of pango will be more consistence, > rather than current vairying from different context. I doubt many call punctuation in Persian/Arabic/Hebrew/Indic/Chinese text rendered using Latin fonts consistency. > > If you do not run under a Latin locale, there's no way for Pango to choose > > Latin fonts before you start typing Latin. > > There is such a way to achieve that, just mark those common characters as > lang:en. Ask the Unicode Consertium. > > that's not going to change... > please fix bug#328374 at first. Most probably that's a bug with your fonts as I said already.
> I doubt many call punctuation in Persian/Arabic/Hebrew/Indic/Chinese text > rendered using Latin fonts consistency. Nope. I'm always talking about the font used to rendering single character 2 and string "2nd" is different. As you said, if '2' should be rendered in Chinese font, itshould be rendered in Chinese font always, no matter what context will be. It shouldn't keep changing.
*** Bug 345072 has been marked as a duplicate of this bug. ***