After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 321113 - Wrong glyph subsituation algorithm for digital characters and punctuations
Wrong glyph subsituation algorithm for digital characters and punctuations
Status: RESOLVED WONTFIX
Product: pango
Classification: Platform
Component: general
1.11.x
Other Linux
: Normal enhancement
: ---
Assigned To: pango-maint
pango-maint
: 345072 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-11-10 03:28 UTC by Funda Wang
Modified: 2007-02-16 02:30 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
pango-wrong-font-substitution.png (12.22 KB, image/png)
2005-11-10 03:38 UTC, Funda Wang
Details
pango-substitution-in-rhythmbox.png (44.51 KB, image/png)
2005-11-10 11:15 UTC, Funda Wang
Details
gedit.png (27.78 KB, image/png)
2005-12-01 12:57 UTC, Funda Wang
Details

Description Funda Wang 2005-11-10 03:28:38 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.
Comment 1 Funda Wang 2005-11-10 03:38:05 UTC
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.
Comment 2 Behdad Esfahbod 2005-11-10 03:40:24 UTC
Is your gecko engine using Pango?  Can you reproduce this in any GNOME application?
Comment 3 Funda Wang 2005-11-10 11:15:40 UTC
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.
Comment 4 Behdad Esfahbod 2005-11-10 15:15:56 UTC
I still don't understand *what* is wrong.

What is wrong with the screenshot?
Comment 5 Funda Wang 2005-11-11 09:20:14 UTC
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.
Comment 6 Behdad Esfahbod 2005-11-11 22:07:03 UTC
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?
Comment 7 Funda Wang 2005-12-01 03:32:52 UTC
Still valid in glib2.9 and pango 1.11.0
Comment 8 Behdad Esfahbod 2005-12-01 03:38:47 UTC
Is it a gtk+-2.8 or 2.6?
Comment 9 Funda Wang 2005-12-01 03:40:29 UTC
gtk 2.8. In fact, I'm using Mandriva cooker + gpwgnome(which contains gnome 2.
13).
Comment 10 Behdad Esfahbod 2005-12-01 03:49:49 UTC
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.
Comment 11 Funda Wang 2005-12-01 12:57:48 UTC
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.
Comment 12 Behdad Esfahbod 2005-12-01 21:27:06 UTC
You are really not getting the point.  If you run under the Chinese locale, the
assumption is that you are going to type Chinese.
Comment 13 Funda Wang 2005-12-02 05:43:34 UTC
The point is the font being used for rendering the same character shouldn't 
change depending the surrounding text.
Comment 14 Behdad Esfahbod 2005-12-02 21:51:35 UTC
Yes it should, for Common characters that do not belong to any particular
script.  Now please stop arguing over something that is NOTABUG.
Comment 15 Funda Wang 2005-12-13 13:32:00 UTC
> 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?
Comment 16 Behdad Esfahbod 2005-12-14 08:53:32 UTC
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.
Comment 17 Funda Wang 2005-12-14 09:07:22 UTC
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?
Comment 18 Behdad Esfahbod 2005-12-14 09:17:36 UTC
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.
Comment 19 Funda Wang 2006-01-23 02:28:45 UTC
Sorry, not all the bug reporters are programmers.
Comment 20 Funda Wang 2006-01-23 07:48:17 UTC
Bug report marked as enchancement should not be closed as invalid.
Comment 21 Xin Zhen 2006-01-23 09:38:26 UTC
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?
Comment 22 Behdad Esfahbod 2006-01-23 14:32:07 UTC
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.
Comment 23 Funda Wang 2006-01-24 02:21:43 UTC
> 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?
Comment 24 Behdad Esfahbod 2006-01-24 02:43:36 UTC
What is your locale set to?
Comment 25 Funda Wang 2006-01-24 06:23:37 UTC
> What is your locale set to?
zh_CN
Comment 26 Behdad Esfahbod 2006-01-24 13:07:32 UTC
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.
Comment 27 Funda Wang 2006-01-24 16:01:54 UTC
> 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.
Comment 28 Behdad Esfahbod 2006-01-24 16:06:57 UTC
(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.
Comment 29 Funda Wang 2006-01-24 16:27:13 UTC
> 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.
Comment 30 Behdad Esfahbod 2006-06-16 03:46:22 UTC
*** Bug 345072 has been marked as a duplicate of this bug. ***