The Edit|Preferences|Fonts has problem with display some foreign fonts.

VERIFIED FIXED in mozilla0.9.1

Status

()

Core
Internationalization
P2
normal
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: Yuying Long, Assigned: jbetak@netscape.com (away - not reading bugmail))

Tracking

({intl})

Trunk
mozilla0.9.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(8 attachments)

(Reporter)

Description

17 years ago
The Edit|Preferences|Fonts has problem with display some foreign fonts.

Tested on 01-03-2001 Mtrunk build/Mac 9.0:
1. Very interesting thing is, the first time you choose most languages except 
Japanese, Western, Unicode font(e.g. Korean, Chinese , Central European.. etc.) 
when you go to Edit|Preferences|Fonts are different than after you click on 
other languages without problems(Japanese, Unicode...) and then choose those 
language fonts.
a. Korean: First time works fine, however "Serif" default value shows blank if 
you visit some other language font like Japanese first, but you still can choose 
the font by the drop down list.
b. Other languages( Chinese, Central European, Cyrillic... etc.): First time the 
2 font "Size" areas are disable, however, if you Choose Japanese or Unicode etc. 
which are no problem with diaplay all area of fonts, the default value of either 
"Sans Serif" or "Serif" or both shows blank.  Like Korean, you still can choose 
the font by select from drop down menu.
(Reporter)

Comment 1

17 years ago
Change QA contact and add keywords.
Keywords: intl, nsbeta1
QA Contact: teruko → ylong

Comment 2

17 years ago
add ben and matt to the cc list.
ylong, can you open Task:Tools:JavaScript Console and attach any warning / error
repored during that testing ?

set it as P3 moz0.9.1
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1
(Reporter)

Comment 3

17 years ago
I didn't see any warning/error in Task:Tools:JavaScript Console during this 
test. 
(Reporter)

Comment 4

17 years ago
Created attachment 22838 [details]
From warning/error in Task:Tools:JavaScript Console
(Reporter)

Comment 5

17 years ago
Created attachment 22911 [details]
Attach one more time.

Updated

17 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9

Updated

17 years ago
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 6

17 years ago
I tried manually edit the prefs.js file so that the fonts for TW, KO, CN
have entry. Mozilla wiped out those entries upon launch. No workaround yet. 

Comment 7

17 years ago
Reassign to jbetak.
Assignee: nhotta → jbetak

Updated

17 years ago
Priority: P3 → P2
Target Milestone: mozilla0.9.1 → mozilla0.9
spam: accepting...
Status: NEW → ASSIGNED
changing platform to "All". 

This problem results from the fact that in absence of a preset font face 
preference, we are trying to default to the last  selected face. If the last 
selected item happens to be from a different language group (e.g. Western vs. 
Japanese), the assignment will fail when the face doesn't exist in the current 
language froup. This then results in the reported JS error.

Suggested remedy: clear the previous selection and default to the first list 
item unless a font face preference has been already established.
OS: Mac System 9.x → All

Comment 10

17 years ago
Why fonts of outside the language group can be selected?
Isn't the UI filtering out faces which does not belong to the language?
>Isn't the UI filtering out faces which does not belong to the language?

Clarifying: the last-selected item is cached regardless of its language group 
membership... If the cached face doesn't exist in the new language group and 
there is no user preference for it yet, it results in this problem.

As discussed with Naoki, a possible temporary workaround is to select a face 
from the dropdown and come back a second time to adjust the face size.
Created attachment 29648 [details] [diff] [review]
pref-fonts.js

Comment 13

17 years ago
r=nhotta

Comment 14

17 years ago
sr=alecf
(in the future, please use cvs diff -u for the benefit of the reviewers!)
works as of 04/05/2001
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 16

17 years ago
Fixed verified on 04-05-2001 Mac trunk build.
Status: RESOLVED → VERIFIED

Updated

17 years ago
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 17

17 years ago
Reopening.
I am not sure how it is supposed to work.
Here is what I see in 2001040911 Mac trunk.
Preferences|Fonts
Under Western, I can see Times for Serif, Helvetica for San-Serif and Courier
for fixed width.
When I switch to Japanese, HeiseiMincho, HeiseiGothic, and Osaka-monospace,
respectively.
Then I switch to either Traditional Chinese, Simplified Chinese, or Korean.
There is blank looking tab or sometimes "No fonts available" for Serif,
HeiseiGothic for San-Serif, and Osaka-monospace for fixed-width.
Now I click the tabs and set all of them to Beijin, Taipei, or Seoul and switch
back to Japanese.
Here What I see is blank tab for Serif, Beijin (Taipei, or Seoul if that has
been selected immediately before switching) for San-Serif and Fixed-width.
If you switch to Western first and then to either Traditional Chinese,
Simplified Chinese, or Korean, there is no font for 2-byte language in the list.
spam: attempting to reproduce... Yuying?
(Reporter)

Comment 19

17 years ago
OK, here is what's the problem:
1. If you have all default font for all lauguages, then you won't see this 
problem - that's why when I mark it as verified on Mac.
2. I change platform to "All" - cause it is not only on Mac.
3. If there are some language's font is not avalible at first time, e.g. 
Traditional Chinese, then the default font for "Serif" will greyed out - not 
avalible at the first time, then you go back to those languages that don't have 
problem at first visiting time, e.g. Japanese or Western... etc.  you will 
"Serif" will display incorrectly(blank).  It might because after the "Not 
avalible" message stay there, so that confuse other language pick up the fonts.  
 
Hardware: Macintosh → All
accepting: the <not available> list item breaks the default value 
functionality...
Status: REOPENED → ASSIGNED
Created attachment 31100 [details] [diff] [review]
Updated patch (covers the issue with "fonts not available")   (text/plain)
Created attachment 31196 [details] [diff] [review]
Updated patch (cvs diff -u -w xpfe/components/prefwindow/resources/content/pref-fonts.js)
Created attachment 31225 [details] [diff] [review]
Fixed some formatting nits (cvs diff -u -w xpfe/components/prefwindow/resources/content/pref-fonts.js)
adding alecf
Created attachment 31228 [details] [diff] [review]
More of the same... (cvs diff -u -w xpfe/components/prefwindow/resources/content/pref-fonts.js)   (text/plain)
review still pending for the latest patch - moving to 0.9.1 
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 27

17 years ago
Jurai,

I'm reworking the font enumerator api which will affect this code.

Could you check with me before checking anything in?

thanks

Comment 28

17 years ago
oops:
s/Jurai/Juraj/
an attempt to "untangle" this patch somewhat. Brian, Naoki - thanks for going 
over this change!
Created attachment 32720 [details] [diff] [review]
Yet more of the same... (cvs diff -u -w xpfe/components/prefwindow/resources/content/pref-fonts.js) (text/plain)   (text/plain)

Comment 31

17 years ago
r=nhotta

Comment 32

17 years ago
sr=alecf
(also, diff -u -w -b will eliminate even more whitespace changes)
thanks everyone! One more off the list...
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
> Suggested remedy: clear the previous selection and default to the first list 
> item unless a font face preference has been already established.

Is this what you are doing? 

What happens if a user selects a new font from halfway down the list on Western, 
then changes to Korean and back to Western? Does the pref panel remember the new 
font he selected?

The fonts panel needs to keep a matrix of encodings versus font types, both the 
original values and the new values. Or something like that.

Note the work going on over in bug 28899 may have an effect on this.

Gerv
Gerv,

glad you asked. I just tried the suggest scenario in my local build and it 
seems to work satisfactorily. My comment and the patch only pertain to the 
initialization values. It seems that the code was less than smart about 
selecting defaults and the change should have no effect on the persistence of 
user-selected pref values. I believe they are cached in the languageData array 
and I haven't really touched that.

BTW would you know about any performance-optimization work being done on this 
pref? We could fully e.g. populate the drop-down lists only when clicked and in 
addition avoid multiple font enumerator calls. There is also bug 33340 to keep 
in mind. I'm very keen on getting work on that started soon. I know Matt Fisher 
and Brian Stell are currently doing some font prefs work. Would you know of 
anyone else?

J.
(Reporter)

Comment 36

17 years ago
Verified on 05-11 trunk build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.