Closed Bug 64231 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: Internationalization, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: amyy, Assigned: jbetak)

Details

(Keywords: intl)

Attachments

(8 files)

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.
Change QA contact and add keywords.
Keywords: intl, nsbeta1
QA Contact: teruko → ylong
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
I didn't see any warning/error in Task:Tools:JavaScript Console during this test.
Attached image Attach one more time.
Target Milestone: mozilla0.9.1 → mozilla0.9
Target Milestone: mozilla0.9 → mozilla0.9.1
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.
Reassign to jbetak.
Assignee: nhotta → jbetak
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
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.
r=nhotta
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
Closed: 24 years ago
Resolution: --- → FIXED
Fixed verified on 04-05-2001 Mac trunk build.
Status: RESOLVED → VERIFIED
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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?
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
adding alecf
review still pending for the latest patch - moving to 0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Jurai, I'm reworking the font enumerator api which will affect this code. Could you check with me before checking anything in? thanks
oops: s/Jurai/Juraj/
an attempt to "untangle" this patch somewhat. Brian, Naoki - thanks for going over this change!
r=nhotta
sr=alecf (also, diff -u -w -b will eliminate even more whitespace changes)
thanks everyone! One more off the list...
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: