Japanese comma and fullstop problem on Linux

VERIFIED DUPLICATE of bug 45678

Status

()

Core
Internationalization
P3
critical
VERIFIED DUPLICATE of bug 45678
18 years ago
13 years ago

People

(Reporter: Masaki Katakai, Assigned: Erik van der Poel)

Tracking

Trunk
All
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2-] fix checked in)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
On UNIX (Linux 2000051608 and Solaris), japanese fullsize
comma (EUC 0xa1a2) and full stop (EUC 0xa1a3) are not
displayed correctly.

1) start Mozilla
2) click on URL field
3) turn IME on by Shift+SPACE
4) type . or , of keyboard

It seems that vertical glyphs are displayed.
(Reporter)

Updated

18 years ago
Summary: Japanese comma and fullstop → Japanese comma and fullstop problem on Linux
(Assignee)

Comment 1

18 years ago
Hi Katakai-san, please try the 5/17 build with setenv NS_FONT_DEBUG 3
and send me the output. Thanks.

Updated

18 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Comment 2

18 years ago
could you kindly create a test file and attach to it. Thanks

Comment 3

18 years ago
mark as nsbeta2 since these are two important character in Japanese. Without the 
proper display , Japanese user cannot view their document correctly. It is 
simlar to display comma in English to something else.
Keywords: nsbeta2
(Reporter)

Comment 4

18 years ago
Created attachment 8819 [details]
outputs from NS_FONT_DEBUG=3
(Reporter)

Comment 5

18 years ago
See the outputs in attachment field, it seems that ksc font is used.
(Assignee)

Comment 6

18 years ago
Thanks for sending the info. Yes, the KSC5601 font is being used, and it has
vertical glyphs for the comma and period characters. The problem may be that the
URL field does not have an associated language, so it does not pass a language
down to the font engine, so it cannot know which font to select, and somehow
ends up with a Korean font. Maybe I need to make the language fallback smarter
by trying the locale's language first. Re-assigning to myself.
Assignee: ftang → erik
Status: ASSIGNED → NEW
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → M17

Comment 7

18 years ago
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]

Updated

18 years ago
Blocks: 42457

Comment 8

18 years ago
Is that true you already have a fix and pending for code review ? who should 
review it ?
(Assignee)

Updated

18 years ago
Whiteboard: [nsbeta2+] → [nsbeta2+] fix reviewed, waiting for open tree
(Assignee)

Comment 9

18 years ago
Checked in the fix.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta2+] fix reviewed, waiting for open tree → [nsbeta2+] fix checked in
(Reporter)

Comment 10

18 years ago
Hi Erik. It seems that UIs of Mozilla and HTML FORMs on
japanese encoded webpages are using correct japanese fonts. Thanks!

However, korean fonts are still used on

	- Text Editor on Mail Composer
	- HTML FORMs on non-japanese encoded webpages

For examples, japanese fonts are used on www.yahoo.co.jp but
korean fonts are used on www.yahoo.com.

I tested with my local build for Solaris. I'll check Linux nightly.


Comment 11

18 years ago
CC'ed myself and ji on this bug.

Comment 12

18 years ago
With Linux 7/14/2000 build, I see that the Text edit field for Plain text
composer is still using a wrong font. Do we have a bug for this
porblem? 

Comment 13

18 years ago
I tested this in 2000-07-17-08 Linux build.  This still happen in Plain text 
editor.  I logged the different bug for it. 45678.  I verified this bug. 
Status: RESOLVED → VERIFIED

Comment 14

18 years ago
I see this problem again on Linux 2000082008.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 15

18 years ago
Setting to [nsbeta2-] since that is outta here.  Putting on nsbeta3 nominee 
radar.
Whiteboard: [nsbeta2+] fix checked in → [nsbeta2-] fix checked in
(Assignee)

Comment 16

18 years ago
This bug was reopened by kazhik@mozilla.gr.jp. I need to confirm this. Marking
nsbeta3 to get it on the radar.
Status: REOPENED → ASSIGNED
Keywords: nsbeta3

Comment 17

18 years ago
Is this a dup of 34392 ?

Comment 18

18 years ago
Not Bug 34392 but Bug 45678.
I contacted Koike-san. If we don't hear an objection from him within 1 day,
this bug will be marked as a duplicate of Bug 45678.

Comment 19

18 years ago
Koike-san agrees that the original problem is now "Worksforme" but 
additional problems mentioned in Bug 45678 still exist. 
The remaining problems of this bug should be dealt in that bug.
Resolving as a duplicate of Bug 45678.

*** This bug has been marked as a duplicate of 45678 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → DUPLICATE

Comment 20

18 years ago
Verified as dup.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.