Closed Bug 95978 Opened 23 years ago Closed 20 years ago

Can't change Central European, Baltic, Cyrillic and Greek font prefs

Categories

(Core :: Internationalization, defect, P4)

PowerPC
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla1.2beta

People

(Reporter: hsivonen, Assigned: ftang)

References

()

Details

(Keywords: intl, Whiteboard: MacOS X,adt3)

Attachments

(1 file, 3 obsolete files)

Build ID: 2001081505 FizzillaCFM

The page http://www.unics.uni-hannover.de/nhtcapri/central_european.html2 uses
the Latin-2 encoding. The text is tiny, but it should be the normal size.
It means you probably have a wrong font (or jus font size) chosen for the
Central European codepages. Go to Properties -> Appearance -> Fonts and change
the settings for "Central European". It should solve your problem (if you have
the right fonts installed).
Mac OS X comes with adequate fonts by default. Even though the text is tiny, I
can see the glyphs are correct. Also, if I copy the text to TextEdit, I can
verify that I have adequate fonts. However, in the Mozilla font prefs, the
Central European prefs are disabled.

What's the point in having a separate font size pref for Central European
anyway? If I like to read Western European at 18px, why would I want to read
Central European (or Cyrillic or Greek) at a different size?
> What's the point in having a separate font size pref for Central European
> anyway? If I like to read Western European at 18px, why would I want to read
> Central European (or Cyrillic or Greek) at a different size?

Because you may use different fonts for different encodings. And the same
"perceived" look for both may require different pixel size. I've seen this
happen under Linux. 

OK. I checked my prefs.js. The Central European size was set to 8px.

Morphing bug to reflect the real issue and starting discussion in n.p.m.ui.

Steps to reproduce:
1) Run Mozilla on Mac OS X
2) Take a look at the Central European, Baltic, Cyrillic and Greek font prefs

Actual results:
Can't edit the prefs.

Expected results:
Expected to be able to adjust the prefs, since Mac OS X comes with fonts with
glyphs for displaying:
* the Russian subset of Cyrillic
* basic Greek (without diacritics)
* Central European* Baltic
Summary: Tiny font on ISO-8859-2 page → Can't change Central European, Baltic, Cyrillic and Greek font prefs
reassign to myself. 
Which fonts have those glyph?
Assignee: yokoyama → ftang
We probably need to look into the 'OS/2' table of the TrueType/OpenType.
or we just fake it to let any MacRoman font also available on
Cyrillic/CentralEurope/Baltic/Turkish/Greek.
Times, Courier, Helvetica, Geneva, Apple Chancery, Charcoal, Chicago, Textile,
Sand, Skia and Palatino support Western European (including Icelandic), Baltic,
Central European, South European (Maltese, Esperanto) and Turkish. (Basically
Latin-you-name-it.)

I suggest these defaults for all Latin variants:
Serif: Times
Sans-serif: Helvetica
Monospaced: Courier
Cursive: Apple Chancery
Fantasy: Sand

Hiragino Kaku Gothic Pro and Hiragino Maru Gothic Pro support extended Greek and
the Russian subset of Cyrillic

Hiragino Mincho Pro supports basic Greek and the Russian subset of Cyrillic.
Oops. In the Hiragino family, the width Greek and Cyrillic glyphs is tuned for
mixing with Han/Kanji blocks making the Hiragino fonts unusable for pages where
Greek or Cyrillic is the dominant script.

Lucida Grande has variable-width glyphs for Cyrillic & Greek.
looks like a isolated improvement, consider for m94
Status: NEW → ASSIGNED
Whiteboard: MacOS X
Target Milestone: --- → mozilla0.9.4
QA Contact: andreasb → ylong
Is the 0.9.4 milestone realistic?  We are branching on Friday.
Keywords: intl
move to m0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Priority: -- → P3
Blocks: 103669
move to m0.9.7
No longer blocks: 103669
Target Milestone: mozilla0.9.5 → mozilla0.9.7
Blocks: 103669
move to 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
mass move unimportant m9.8 bug to m9.9 for now. 
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Note also that Unicode fonts that may cover the character range of the encoding
in question are not selectable as the font for that range in Fizzilla.
give to nhotta
Assignee: ftang → nhotta
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.9 → mozilla1.0
I tried IE and it has the same problem, no default selection for Central
European. But the list is not disabled so the user can select something.
I think we can list all the fonts instead of disabling the list, let the user
choose whatever appropriate.
Status: NEW → ASSIGNED
Keywords: nsbeta1
nsbeta1+ per triage meeting 
Keywords: nsbeta1nsbeta1+
reassign to ftang
reassign to ftang
Assignee: nhotta → ftang
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Attached patch patch v1 (obsolete) — Splinter Review
we have the following issue:
1. we put the FMFontFamily into the hash for MacOS X but we get it and cast it
as FondID in here. So we need to change that, we need to cast to FMFontFamily
for MacOS X to match the other place
2. The current code only list the font which belong to a script code. We need
to check the OS/2 table to list all the font(but not CJK fonts) which have the
glyph for some subrange.
Blocks: 104056
two issue.
1.  currently, in the Carbon build (see
http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsDeviceContextMac.cpp#793 )

nsDeviceContextMac :: InitFontInfoList()

we put a FMFontFamily into the hash but in the (see
http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsDeviceContextMac.cpp#1099 )


1099 EnumerateFont(nsHashKey *aKey, void *aData, void* closure)

we cast the hash data into a short which mean FontID and then call
::FontToScript (fontID) to get the script code. 

1106 short fondID = (short) aData;
1107 ScriptCode script = ::FontToScript(fondID);
1108 if(script == info->mScript) 

This is ok on non carbon build since we put the FontID into the hash, but for
carbon build, it is NOT a font ID but a FMFontFamily, therefore, we need to use
a different way to get the script

2. some font could be use for langgroup other than the script code , for
example,. some Latin font could be used for x-western, x-central-euro and tr
(turkish) . In that case, we need to access the OS/2 table in the TrueType font
to find out the hint. 
+  PRUint32    mUsb[4];
+  PRUint32    mNoUsb[4];

Could you explain about those? Are those related to TrueType table? What does
the nuber 4 mean?
+  PRUint32    mUsb[4];
mUsb[4] mean if those bits are on in ulCharRange[4] of the TrueType 'OS/2'
table, then we should list the font also

+  PRUint32    mNoUsb[4];
mNoUsb[4] mean if those bits are on in ulCharRange[4] of the TrueType 'OS/2'
table, then we should NOT list the font even there are other condiction said we
should list it. 

So, for example, for "el" (greek lang group), we turn on the Greek bits in the
mUsb[4] but also turn on the HanIdeograph bits in the mNoUsb[4] . In this way,
all the TrueType font have the Greek bit set but no HanIdeograph bit set will be
listed. We need the mNoUsb so we won't list Japanese or Chinese font (Usually
have wider Greek Glyph) for Greek but list Latin font for Greek. 
see http://developer.apple.com/fonts/TTRefMan/RM06/Chap6OS2.html
for ulCharRange[4]
The meaning of bits could be found at 
http://www.microsoft.com/typography/otspec/os2.htm
Attachment #72987 - Attachment is obsolete: true
nhotta, please r= 
nhotta verbally ask me to put
+  // but if we match the following bits, we don't list it
+  // need this so we can exclude CJK fonts for Latin/Greek/Cyrillic
+  for (i=0; i<4; i++) {
+    if (signature.fsUsb[i] & info->mNoUsb[i]) 
+    {
+      match = PR_FALSE;
+      break;
+    }
+  }


into the previous else block. 
Attached patch v3 patch (obsolete) — Splinter Review
Attachment #73097 - Attachment is obsolete: true
nhotta, please r= 
+  PRUint32    mUsb[4];

Please add a comment to indicate this means bits 0-127.

+  FMFontStyle aStyle;
+  FMFont aFont;

Please change not to prepend 'a' for the local variables.

+    // get the encoding of the font
+    status = ::FMGetFontFamilyTextEncoding(aFontFamily, &fontEncoding);
+    // convert the encoding to script code
+    status = ::RevertTextEncodingToScriptInfo(fontEncoding,
&aSignature.scriptCode , nsnull, nsnull);

Please check an error after ::FMGetFontFamilyTextEncoding.
Attached patch v4 of patchSplinter Review
Attachment #73578 - Attachment is obsolete: true
Comment on attachment 73611 [details] [diff] [review]
v4 of patch

r=nhotta
Attachment #73611 - Flags: review+
Blocks: 104148
No longer blocks: 104056
I'm getting very worried about all the special-case font/i18n logic that seems
to be scattered throughout the Mac gfx code. This logic really doesn't live in
nsDeviceContextMac; some of it should be off in a class that deals with the
internals of TrueType fonts, so the reader can easily see what the main logical
decisions in the code are. As someone who is investing some amount of time in
text rendering code on Mac, I need this code to be clean and self-documenting.
Right now, it's scattered and confusing.
ok. it make sense. Let's spin this bug into two issue. One is the fix the
straight forward FMFontFamily cast to fontID problem and other is to enhance the
Mac font pref code to look at the TrueType 'OS/2' table. Let's keep this one for
the enhancement and put the FMFontFamily casting bug into bug 130443
Blocks: 104056
No longer blocks: 104148
No longer blocks: 104056
P4 
Priority: P3 → P4
Whiteboard: MacOS X → MacOS X,adt3
Impact Summery
Impact Platform: MacOS X only
Impact language users: Central European, Baltic, Cyrillic and Greek (30.7 M, 5.6%)
Probability of hitting the problem: low, depend on users action
Severity if hit the problem in the worst case: Users cannot set the font
preference but they can still see the text.
Way of recover after hit the problem: None
Risk of the fix: Low
Potential benefit of fix this problem: None
> Risk of the fix: Low

One possible fix is letting the user pick any font--even those that are bad choices.

> Potential benefit of fix this problem: None

No benefit?
I suggest we nsbeta1- this bug. Even we show all the font on the pref, the back
end code probably won't use the font we selected. It is not just a ui issue.


nsbeta1- because we can see the page, 
also, I do see "Time CE" etc for Central European listed 
and if people have Cyrillic and Greek font, they will still be listed in font pref. 
Keywords: nsbeta1+nsbeta1-
> also, I do see "Time CE" etc for Central European listed 

Times CE, Helvetica CE, etc. are no longer supposed to be required for Central
European chars. The character repertoire of those fonts has been merged into
Times, Helvetica, etc. but Mozilla doesn't allow the user to select those.
Target Milestone: mozilla1.0 → mozilla1.2beta
Anyone working on this one? It's targetted for 1.2 beta! It's been more than a
year since anyone has posted any comments... I still cannot change the Greek
fonts in Mozilla 1.4b or Camino 0.7+.
It seems like even v4 patch wouldn't be sufficient to deal with fonts with
various character repertoires (that go beyond 'traditional' repertoires
corresponding to Mac OS Classic 'script codes') because the patch still relies
on Mac OS Classic 'script' code.

As far as I can tell, barring the transition to ATSUI, we have to do something
similar to what's done in Gfx:Win. For instance, take a look at 

http://lxr.mozilla.org/seamonkey/source/gfx/src/windows/nsFontMetricsWin.cpp#1590

Gfx:Xft (Gfx:Gtk-FT2) doesn't need to deal with the cmap table directly because
fontconfig (and freetype) offers a nice set of APIs. Unless there are similar
Carbon APIs, we have to either duplicate what's done in Gfx:Win (reading
different types of cmap tables in truetype fonts) or factor that out so that it
can be used by both Gfx:Win and Gfx:Mac.
Sorry for spamming.
Perhaps, I have to take back most of what I wrote in the previous comment.
gfx/src/mac/nsUnicodeRenderingToolkit.cpp has a bulk of code for rendering
'Unicode text' including MathML and even Korean fallback. It appears that it's
still a mix of 'script'-based code and 'ATSUI' and is not so easy to read.  The
cleanest way, I guess, is to go all the way to ATSUI APIs (because QuickDraw
APIs are based on 'Mac classic scripts'), but there's a lingering performance
concern... Hmm.. Safari must use it. Then, why not Mozilla? Well, there's an
impedance matching issue between Mozilla's layout engine  and ATSUI. Handing
over a small chunk of text at a time to ATSUI APIs instead of a paragraph (the
'natural' working unit of ATSUI) and repeating that many times would be a big
performance hit. I wish there were a set of low-level drawing/measuring APIs....
Exactly what Bug 157967 is about.
FIXED in bug 120401, but we still needs ATSUI for better rendering.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
FIXED in bug 120401, but we still need ATSUI for better rendering.
Depends on: 120401
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: