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 481210 - [All lang] [firefox] - Face of the number is changing when enter number + Char, in any Locale
[All lang] [firefox] - Face of the number is changing when enter number + Cha...
Status: RESOLVED OBSOLETE
Product: pango
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: pango-maint
pango-maint
Depends on:
Blocks:
 
 
Reported: 2007-09-28 08:52 UTC by LingNing Zhang
Modified: 2018-05-22 12:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description LingNing Zhang 2007-09-28 08:52:27 UTC
Please describe the problem:
https://bugzilla.redhat.com/show_bug.cgi?id=228804

Opened by Huang Peng (phuang@redhat.com)  	 on 2007-02-15 00:51 EST  	[reply]  	   Private

+++ This bug was initially created as a clone of Bug #220885 +++

Description of problem:
The face of the number is changing when char is entered after number. Must be
logged in with any locale other than en_US locale. For Example : input may be :
1111aaaa or 1111<any other language char>.

Version-Release number of selected component (if applicable):
firefox-1.5.0.9-3.el5
firefox-1.5.0.9-4.el5

How reproducible:
Always

Steps to Reproduce:
1. Login into the system with any locale except en_US locale
2. Open firefox with any CJKI locale/
3. Open batman.brisbane.redhat.com/bugzilla -- Login with your Account
4. Enter a New Bug for this test
5. In the text box, type 1111aaaa or 1111<any other language char>
6. Oserve the face of 1111 is changing just any char is entered after the number
  
Actual results:
face of the number is changing.

Expected results:
Face should not be changed

Additional info:
Screenshot attached. In the scrshot, there is a line where 1111 is written
without any locale reference. Thats the actual face of the number before any
char typed after that. It is red marked.

-- Additional comment from smaitra@redhat.com on 2006-12-28 06:33 EST --
Created an attachment (id=144459) [edit]
Firefox Face change screenshot for all locales


-- Additional comment from phuang@redhat.com on 2007-02-09 01:38 EST --
I found CJK locales use font monospace for textarea, but western locals use
Courier. If I change the fonts for CJK in about:config. This bug will disappear.


-- Additional comment from phuang@redhat.com on 2007-02-09 01:41 EST --
Created an attachment (id=147728) [edit]
Change font config for chinese.


-- Additional comment from mcepl@redhat.com on 2007-02-09 05:41 EST --
Could you try to switch all monospace fonts to monospace? Does problem disappear
as well? I think that having Courier in Western fonts is not good either --
serif/sans-serif/monospace should be the standard fonts.

-- Additional comment from phuang@redhat.com on 2007-02-09 07:29 EST --
Created an attachment (id=147760) [edit]
A simple test code

I think it's a bug of pango or fontconfig. I reproduced it in gedit and in a
simple pango test code. Run the simple test program with zh_CN.UTF8 locations,
it will use different fonts to render two lines.

-- Additional comment from mcepl@redhat.com on 2007-02-09 09:39 EST --
Changing component accordingly.

-- Additional comment from phuang@redhat.com on 2007-02-11 21:29 EST --
I found pango treats numbers and punctuations as common script and almost fonts
support common script characters. So pango will render common script using
different fonts. If common script is among of other script, pango will render it
with the other script's font, If common script is alone, it will be render with
locale font. So the varied strategy will cause this bug, and the text will be
looked weirdly. 
So I think pango should not use different fonts to render common script
characters according to characters before or after it.


-- Additional comment from phuang@redhat.com on 2007-02-11 21:47 EST --
Created an attachment (id=147872) [edit]
Using Latin font to render numbers and punctuations.


-- Additional comment from besfahbo@redhat.com on 2007-02-12 14:16 EST --
(In reply to comment #7)
> I found pango treats numbers and punctuations as common script and almost fonts
> support common script characters. So pango will render common script using
> different fonts. If common script is among of other script, pango will render it
> with the other script's font, If common script is alone, it will be render with
> locale font. So the varied strategy will cause this bug, and the text will be
> looked weirdly. 
> So I think pango should not use different fonts to render common script
> characters according to characters before or after it.
> 

That's not going to happen, and this is not a bug.  If you run firefox under a
CJK locale, pango chooses fonts for that locale.  Why do you expect it to choose
digits from a Latin font?

-- Additional comment from besfahbo@redhat.com on 2007-02-12 14:22 EST --
This is NOTABUG IMHO.

-- Additional comment from phuang@redhat.com on 2007-02-12 20:50 EST --
(In reply to comment #9)
> 
> That's not going to happen, and this is not a bug.  If you run firefox under a
> CJK locale, pango chooses fonts for that locale.  Why do you expect it to choose
> digits from a Latin font?

yeah, you are right. But when common characters are among of Latin charaters,
pango will render it with Latin fonts. In a document, some numbers are rendered
with CJK fonts, and another numbers are rendered with Latin fonts. It's really
weird, and It is not be acceptable for CJK users. Maybe other locale users do
not accept it too.
Except my patch in Comment #8, there is another solutions. It's rendering all
common and Latin characters with locale fonts. Almost all local fonts support
common and Latin characters.
Do you think it reasonable?

Thanks
Shawn

-- Additional comment from besfahbo@redhat.com on 2007-02-13 13:43 EST --
If you really want to get the same common chars, just remove those from your
locale's font.

-- Additional comment from mcepl@redhat.com on 2007-02-14 04:13 EST --
Is Chinese supported in DejaVu fonts or is fonts-chinese still necessary?

-- Additional comment from besfahbo@redhat.com on 2007-02-14 13:24 EST --
fonts-chinese is necessary.  Chinese is not supported in DejaVu fonts, and note
that we ship dejavu-lgc-fonts in core, which only contains the
Latin/Greek/Cyrrillic subsets of dejavu.

-- Additional comment from petersen@redhat.com on 2007-02-15 00:44 EST --
But why are some numbers rendered in one font and others in different one?


Comment #1 From Huang Peng (phuang@redhat.com) 	on 2007-02-15 22:14 EST 	[reply] 	Private

Created an attachment (id=148168) [edit]
Screensohts from firefox & gedit

The attached files are some screen shots from firefox and gedit. In 1.png and
2.png, some digits and punctuations are rendered with different fonts. It
reduces pango's good rendering effect, And sometime it will cause some problem
when application calculates width from variable common characters. I think it
is necessary to fix it. And I think removing common and Latin glyphs from
locale's fonts are not easy. There are many fonts need fixing and some of
locale's fonts in RHEL are commercial copies, we must ask font companies to
modify them. It's very hard.:(
I think fixing it in pango is easier. Do you have some ideas to fix it in pango
and make the text output perfect? Please consider it. Thanks.
BTW, In 3.png, pango renders all common characters with Latin font, it's very
good.
In 4.png, pango renders all common and Latin characters with Chinese font, it
is also acceptable.

Thanks
Shawn Huang


Comment #2 From Huang Peng (phuang@redhat.com) 	on 2007-02-25 22:26 EST 	[reply] 	Private

Created an attachment (id=148776) [edit]
Let pango process common script as Latin

Hi Behdad

I created a patch that processes common script as Latin. Could you review it?
Any comments are welcome.

Thanks
Shawn


Comment #3 From Behdad Esfahbod (besfahbo@redhat.com) 	on 2007-02-27 13:30 EST 	[reply] 	Private

(In reply to comment #2)
> Created an attachment (id=148776) [edit] [edit]
> Let pango process common script as Latin
> 
> Hi Behdad
> 
> I created a patch that processes common script as Latin. Could you review it?
> Any comments are welcome.

What's the rationale for such a change?  Common characters are common to all
scripts.  They are not Latin.  If I write in Persian, I want common characters
chosen from my Persian font, not Latin font.

> Thanks
> Shawn



Comment #4 From Huang Peng (phuang@redhat.com) 	on 2007-02-27 21:17 EST 	[reply] 	Private

(In reply to comment #3)
> (In reply to comment #2)
> What's the rationale for such a change?  Common characters are common to all
> scripts.  They are not Latin.  If I write in Persian, I want common characters
> chosen from my Persian font, not Latin font.

The patch will give a good result for Chinese users. Maybe it is not suitable
for all locales.:( As you said, you want common characters chosen from Persian
font, but when a common character is among of Latin characters, it is no chance
to be rendered by Persian, although it is a Persian article. Do you think it is
reasonable? I believe that different scripts need different processing logic for
common script. Do you agree with me? If not, do you have some ideas to resolve
this problem in Chinese locale? 

Thanks
Shawn



Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Jens Petersen 2009-10-23 04:08:42 UTC
(In reply to comment #3)
> What's the rationale for such a change?  Common characters are common to all
> scripts.  They are not Latin.  If I write in Persian, I want common characters
> chosen from my Persian font, not Latin font.

But that is not true for CJK (East Asian langs)
they have their own wide punctuation and number glyphs.

For CJK, COMMON should be rendered in the same font as Latin.
Comment 2 GNOME Infrastructure Team 2018-05-22 12:33:34 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pango/issues/97.