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

RESOLVED FIXED in mozilla1.2beta

Status

()

Core
Internationalization
P4
normal
RESOLVED FIXED
16 years ago
13 years ago

People

(Reporter: hsivonen, Assigned: Frank Tang)

Tracking

({intl})

Trunk
mozilla1.2beta
PowerPC
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: MacOS X,adt3, URL)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

16 years ago
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.

Comment 1

16 years ago
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).
(Reporter)

Comment 2

16 years ago
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?

Comment 3

16 years ago
> 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. 

(Reporter)

Comment 4

16 years ago
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
(Assignee)

Comment 5

16 years ago
reassign to myself. 
Which fonts have those glyph?
Assignee: yokoyama → ftang
(Assignee)

Comment 6

16 years ago
We probably need to look into the 'OS/2' table of the TrueType/OpenType.
(Assignee)

Comment 7

16 years ago
or we just fake it to let any MacRoman font also available on
Cyrillic/CentralEurope/Baltic/Turkish/Greek.
(Reporter)

Comment 8

16 years ago
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.
(Reporter)

Comment 9

16 years ago
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.
(Assignee)

Comment 10

16 years ago
looks like a isolated improvement, consider for m94
Status: NEW → ASSIGNED
Whiteboard: MacOS X
Target Milestone: --- → mozilla0.9.4

Updated

16 years ago
QA Contact: andreasb → ylong

Comment 11

16 years ago
Is the 0.9.4 milestone realistic?  We are branching on Friday.

Updated

16 years ago
Keywords: intl
(Assignee)

Comment 12

16 years ago
move to m0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
(Assignee)

Updated

16 years ago
Priority: -- → P3
(Assignee)

Updated

16 years ago
Blocks: 103669
(Assignee)

Comment 13

16 years ago
move to m0.9.7
No longer blocks: 103669
Target Milestone: mozilla0.9.5 → mozilla0.9.7
(Assignee)

Updated

16 years ago
Blocks: 103669

Comment 14

16 years ago
move to 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
(Assignee)

Comment 15

16 years ago
mass move unimportant m9.8 bug to m9.9 for now. 
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Comment 16

16 years ago
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.
(Assignee)

Comment 17

16 years ago
give to nhotta
Assignee: ftang → nhotta
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.9 → mozilla1.0

Comment 18

16 years ago
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

Updated

16 years ago
Keywords: nsbeta1
(Assignee)

Comment 19

16 years ago
nsbeta1+ per triage meeting 
Keywords: nsbeta1 → nsbeta1+
(Assignee)

Comment 20

16 years ago
reassign to ftang
(Assignee)

Comment 21

16 years ago
reassign to ftang
Assignee: nhotta → ftang
Status: ASSIGNED → NEW
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 22

16 years ago
Created attachment 72987 [details] [diff] [review]
patch v1

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.
(Assignee)

Updated

16 years ago
Blocks: 104056
(Assignee)

Comment 23

16 years ago
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. 

Comment 24

16 years ago
+  PRUint32    mUsb[4];
+  PRUint32    mNoUsb[4];

Could you explain about those? Are those related to TrueType table? What does
the nuber 4 mean?
(Assignee)

Comment 25

16 years ago
+  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. 
(Assignee)

Comment 26

16 years ago
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
(Assignee)

Updated

16 years ago
Attachment #72987 - Attachment is obsolete: true
(Assignee)

Comment 27

16 years ago
Created attachment 73097 [details] [diff] [review]
patch v2, add comment about OS/2 table
(Assignee)

Comment 28

16 years ago
nhotta, please r= 
(Assignee)

Comment 29

16 years ago
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. 
(Assignee)

Comment 30

16 years ago
Created attachment 73578 [details] [diff] [review]
v3 patch
Attachment #73097 - Attachment is obsolete: true
(Assignee)

Comment 31

16 years ago
nhotta, please r= 

Comment 32

16 years ago
+  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.
(Assignee)

Comment 33

16 years ago
Created attachment 73611 [details] [diff] [review]
v4 of patch
Attachment #73578 - Attachment is obsolete: true

Comment 34

16 years ago
Comment on attachment 73611 [details] [diff] [review]
v4 of patch

r=nhotta
Attachment #73611 - Flags: review+
(Assignee)

Updated

16 years ago
Blocks: 104148
No longer blocks: 104056

Comment 35

16 years ago
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.
(Assignee)

Comment 36

16 years ago
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
(Assignee)

Updated

16 years ago
Blocks: 104056
No longer blocks: 104148
(Assignee)

Updated

16 years ago
No longer blocks: 104056
(Assignee)

Comment 37

16 years ago
P4 
Priority: P3 → P4
(Assignee)

Updated

16 years ago
Whiteboard: MacOS X → MacOS X,adt3
(Assignee)

Comment 38

16 years ago
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
(Reporter)

Comment 39

16 years ago
> 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?
(Assignee)

Comment 40

16 years ago
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.


(Assignee)

Comment 41

16 years ago
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-
(Reporter)

Comment 42

16 years ago
> 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.
(Assignee)

Updated

15 years ago
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+.

Comment 44

13 years ago
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.

Comment 45

13 years ago
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....

Comment 46

13 years ago
Exactly what Bug 157967 is about.
FIXED in bug 120401, but we still needs ATSUI for better rendering.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 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.