Closed
Bug 130745
Opened 23 years ago
Closed 3 years ago
The font on the SimpChinese page in URL field seems wrong
Categories
(Core :: Internationalization, defect)
Tracking
()
RESOLVED
INVALID
Future
People
(Reporter: amyy, Unassigned)
References
()
Details
(Keywords: intl)
Attachments
(2 files)
Build: 03-11 trunk and N6.2.1 build / RH7.2
Load page: http://www-900.ibm.com/developerWorks/java/joy-i18n/index.shtml
The font in this page looks like is not using SimpChinese font(no matter what's
the locale are), the big size and small size mixed together, and for SimpChinese
only characters is displayed bigger than others - see a followed screen shot.
Windows and Mac don't have same problem.
| Reporter | ||
Comment 1•23 years ago
|
||
| Reporter | ||
Updated•23 years ago
|
QA Contact: ruixu → ylong
Summary: The font on the SimpChinese page in URL field seems wrong → The font on the SimpChinese page in URL field seems wrong
It seems this page is not recognized as a gb2312 page although it has a charset
meta tag in it. There is no mark checked on GB2312 on the charset menu. View
page source window seems to be using gb2312 fonts.
| Reporter | ||
Comment 4•23 years ago
|
||
The charset menu is marked as gb2312 for me, even I manually override charset to
gb2312 still get the same result.
I saw the charset menu problem with a brand new profile.
Yes, manually selecting gb2312 doesn't make the page look better.
| Reporter | ||
Comment 6•23 years ago
|
||
Seems there are different fonts (songTi and heiTi?) mixed together.
And in page source, all characters are using songti.
Is this a RH 7.2 special? since cannot repro it on JA RH 7.1.
Keywords: intl
Comment 8•23 years ago
|
||
The font specified by the document is helvetica, but there is no helvetica font
for gb2312. On RH72 there is a japanese font marked as helvetica, and that makes
the japanese font take precedence of gb2312 font.
As suggested by CSS, we are searching for font family name first. But CSS
specification does not give much description about the role lang group should
play. In case of CJK, lang group might be more important than an exact match of
font family name, as shown by this bug. Should we try other font family in the
same lang group before we try the fonts in other lang groups? I think this make
sense for CJK font matching. I am sure this issue will be very debatable. So for
now, let's blame web author for this.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 9•21 years ago
|
||
shanjian is no longer working on mozilla for 2 years and these bugs are still
here. Mark them won't fix. If you want to reopen it, find a good owner first.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Comment 11•21 years ago
|
||
Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all
the spam is his fault feel free to tar and feather him
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 12•21 years ago
|
||
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
Assignee: nobody → jshin1987
Status: REOPENED → NEW
Updated•16 years ago
|
QA Contact: amyy → i18n
Comment 13•3 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months.
:m_kato, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee: jshin1987 → nobody
Flags: needinfo?(m_kato)
Comment 14•3 years ago
|
||
Old bug that is most likely no longer valid.
Status: NEW → RESOLVED
Closed: 21 years ago → 3 years ago
Resolution: --- → INVALID
Updated•3 years ago
|
Flags: needinfo?(m_kato)
You need to log in
before you can comment on or make changes to this bug.
Description
•