Shoshannah Forbes Reporter
	Description • 23 years ago

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
BuildID:    20010801

I just downloaded and installed Mozilla 0.93 on my w2k machine.
Unlike older builds, I can not set default font types (serif vs. sans-serif)
independently for each language (Hebrew and English). It only lets me set
both as serif or both as sans serif.

Going into the settings and changing them for one language, automatically
changes it for the other.

This is the setup I am trying to reach, but I am unable to:
Western languages: Default font should be Georgia (Serif)
Hebrew: Default font should be Arial (Sans-Serif)


Reproducible: Always
Steps to Reproduce:
1. Install Mozilla 0.93 on windows 2000 w/hebrew installed
2. Go into "prefrences", and change the default font type for latin as Serif
3. Set the default font type for Hebrew as sans serif

Actual Results:  both are set to the last type defined, regardless of the 
setting in each language

Expected Results:  Each lanauges should have indipendent default settings

	Andreas Becker
	Comment 1 • 23 years ago

Switching qa contact to ylong. Yuying, please take a look at it and confirm. 

	Yuying Long
	Comment 2 • 23 years ago

I checked 08-10 commercal trunk build on my Win2k-CN, I haven't seen this 
problem.

Reporter: your system is US win2k/w Hebrew installed?  have you ever found in 
some other OS?

	Shoshannah Forbes Reporter
	Comment 3 • 23 years ago

Testing now on another machine running Hebrew enabled win98 2nd Edition, and
gthe bug is still there.
Mybe it is Hebrew spcific?

	Andreas Becker
	Comment 4 • 23 years ago

CCing mahar@eg.ibm.com, giladehven@hotmail.com, and simon@softel.co.il

	Simon Montagu :smontagu
	Comment 5 • 23 years ago

I see the same bug on WinNT with and without Hebrew support.

	Andreas Becker
	Comment 6 • 23 years ago

Thanks for testing this. Changing status to NEW based on Simon's comment.

	Frank Tang
	Comment 7 • 23 years ago

This could be caused by gerv@gerv.net 's check in . 
change the component to Preference, add gerv@gerv.net to the cc list and
reassign to default preference owner. 

	sairuh (rarely reading bugmail)
	Comment 8 • 23 years ago

cc'ing gerv's current addy.

	rbs
	Comment 9 • 23 years ago

Adding dependency to bug 61883.
The problem is that the back-end currently uses "font.default" as the pref key 
for the default font. (Note that the key doesn't include the langGroup.) 
Therefore, when switching from on langGroup to another, the previous selection 
is overwritten. See "Additional Comments From rbs@maths.uq.edu.au 2001-08-17 
18:05" on bug 61883 for details on the current keys, as well as the extension 
that will be happening soon. Feel free to provide feedback if any intl issue is 
not accounted for in the proposed extension.

	Jaime Rodriguez, Jr.
	Comment 10 • 23 years ago

Ftang/Samir - Is this something we should fix for 0.9.4? Looks like a regression
we should address IMO. Pls advise .  . .

	Jaime Rodriguez, Jr.
	Comment 11 • 23 years ago

Peter/Samir - If you agree that this is a regression and should be fixed this
round, pls mark as nsbranch+.

	Gervase Markham [:gerv]
	Comment 12 • 23 years ago

rbs's patch, which I believe fixes this, is far too complex for 0.9.4. 

Did this ever work correctly? From what rbs says just above, it seems not.

Gerv

	Shoshannah Forbes Reporter
	Comment 13 • 23 years ago

Strange, but it did work for me on older builds, like 0.90 / 0.91 

	selmer (gone)
	Comment 14 • 23 years ago

I recommend nsbranch- for this bug.  Is this really a regression?

	Gervase Markham [:gerv]
	Comment 15 • 23 years ago

The pref is font.default , and a quick look at lxr says it's been that way for
years. As far as I can see, there was never a way of setting this independently.

As I say, rbs' fix fixes this.

Setting nsbranch- based on selmer's comments.

Gerv

	Peter Trudelle
	Comment 16 • 23 years ago

really setting nsbranch- (keyword)

	Peter Trudelle
	Comment 17 • 23 years ago

over to rbs, per gerv's 2001-09-17 14:15 comments.

	rbs
	Comment 18 • 23 years ago

To clarify, this bug won't be fixed _automatically_ after my checkin, bug 99010. 
To precisely match what the back-end expects, the front-end will have to be 
tweaked too... Specifically, the front-end will have to persist:

font.name.variable.[langGroup] = current user' selected font on the pref dialog

and, as explained in bug 61883, it will also have to sync the corresponding: 

font.default = generic type of current user' selected font

	Jaime Rodriguez, Jr.
	Comment 19 • 23 years ago

nominating ...

	Prognathous
	Comment 20 • 22 years ago

Quote:
>This is the setup I am trying to reach, but I am unable to:
>Western languages: Default font should be Georgia (Serif)
>Hebrew: Default font should be Arial (Sans-Serif)

Same problem here (Mozilla v1.0/RC1 under Win2kPro)

Serif Hebrew fonts have a terrible (almost biblical) appearance.
Many first time users of Mozilla abandon it, just because of that. Most of them
don't even bother to check the font Preferences panel.

The default for Hebrew must be Sans-Serif.

Prog.

	rbs
	Comment 21 • 22 years ago

Re-assigning to default component owner since I am not going to fix it.

My contribution was in the back-end which was checked in long ago (bug 99010),
at the same time as the back-end for the minimum font-size preference which was
only exposed recently (bug 110342). So, some UI savvy person needs to step in 
bug 61883 to move things forward as inspired by bug 110342. (I might help with
additional tweaks in the back-end if need arises during the fix of bug 61883.)

In the meantime, you can manually add this to your user.js:

user_pref("font.name.variable.x-western", "Georgia");
user_pref("font.name.variable.he", "Arial");

	Samir Gehani
	Comment 22 • 22 years ago

Nav triage team: nsbeta1-

	u32858
	Comment 23 • 22 years ago

This seems similar/ the same as my bug
http://bugzilla.mozilla.org/show_bug.cgi?id=128790


another of my bugs that is related
http://bugzilla.mozilla.org/show_bug.cgi?id=128208

basically utg-8 japanese looks great, but iso-2022-jp looks **** in some serif
font. it would be nice to be able to get the japanese font

	rbs
	Comment 24 • 22 years ago

*** Bug 128790 has been marked as a duplicate of this bug. ***

	rbs
	Comment 25 • 22 years ago

*** Bug 128208 has been marked as a duplicate of this bug. ***

	Ahmad A. Abu-Taha
	Comment 26 • 21 years ago

Kindly be informed that Ahmad A. Abu-Taha (ahtaha@eg.ibm.com) from IBM Egypt is 
replacing Maha Abou El-Rous (mahar@eg.ibm.com) in monitoring and receiving 
notifications of Mozilla bugs regarding Arabic.

	Shoshannah Forbes Reporter
	Comment 27 • 21 years ago

*** Bug 192347 has been marked as a duplicate of this bug. ***

	Justin Kerk
	Comment 28 • 20 years ago

I'm getting this with Firefox trying to set Japanese to sans-serif while keeping
everything else serif, although I can "cheat" by setting the Japanese "serif"
font choice to be the same as the sans-serif.

Is this bug generic enough to cover this or does a separate Firefox one need to
be opened?

	Jungshik Shin
	Comment 29 • 20 years ago

(In reply to comment #21)

> In the meantime, you can manually add this to your user.js:
> 
> user_pref("font.name.variable.x-western", "Georgia");
> user_pref("font.name.variable.he", "Arial");

Does this still work?  It seems not. Anyway, I'd rather have
'font.default.LANG_GROUP' which can be set to serif, sans-serif, cursive and
fantastic, monospace (rather than any arbitrary font name). Implementing that
requires changes in all ports of Gfx. I'm changing the component to Gfx because
this doesn't require any change in 'layout/' but all the changes should happen
in 'gfx/' (and xpfe/toolkit)

	rbs
	Comment 30 • 20 years ago

The prefs still work. Of course, you won't see them in action if you visit a
page that sets its fonts explicitly.

> Anyway, I'd rather have 'font.default.LANG_GROUP'

Comment bug 61883 comment 84 and bug 61883 comment 85 that draws from bug 28899.

See also point 2) in bug 61883 comment 87. 'font.default.LANG_GROUP' might be
good (as a separate holder) if it is not redundant with something else.

	Shoshannah Forbes Reporter
	Comment 31 • 20 years ago

*** Bug 275908 has been marked as a duplicate of this bug. ***

	Jungshik Shin
	Comment 33 • 20 years ago

(In reply to comment #32)
> Created an attachment (id=169540)
looks good. Please, change the default for Korean to 'sans-serif' as is done for
Japanese.

	Asaf Romano (gone)
	Comment 34 • 20 years ago

(In reply to comment #32)
> Created an attachment (id=169540) [edit]
> Patch rv0.3(work in progress)
> 

The default for Hebrew should be "sans-serif".

Thanks for working on this!

	Eyal Rozenberg
	Comment 35 • 20 years ago

(In reply to comment #34)
> The default for Hebrew should be "sans-serif".

I disagree. I believe the default for Hebrew should be serif; the problem is
that the current default serif font for Hebrew is a poor choice (it should be
David instead of Narkisim; at least on Windows).

	Prognathous
	Comment 36 • 20 years ago

The default for Hebrew should definitely be Sans-Serif. Serif is especially
unreadable in Hebrew, as was proved by a recent poll that span 42 users. In this
poll. Sans Serif won 95% of the votes. Only two users chose Serif (for spite?).

http://www.hwzone.co.il/community/index.php?topic=89493.0

As for David as a possible Serif font that does-not-suck, this was offered too:
http://www.hwzone.co.il/community/index.php?topic=89493.msg763583#msg763583

Nobody wanted to change their vote. In fact, in some font sizes, Narkisim is
even more legible than David, but the on-screen legibility of these fonts is so
poor compared to Sans Serif fonts such as Arial, that we're just wasting our
time debating this.

The default for Hebrew should definitely be Sans-Serif. Period.

Prog.

	Eyal Rozenberg
	Comment 37 • 20 years ago

Prog and Asaf, changing the default Hebrew font from serif to sans-serif is a
different issue than enabling different settings for different languages, so
please file this as a different bug (depending on this one) instead of having
this discussion/argument here.

(Plus I have a long answer to Prog's last comment but like I said I would rather
make it elsewhere).

	Prognathous
	Comment 38 • 20 years ago

Since the fix is going to change the defaults for Japanese and Korean, it is
perfectly ok to request a change for Hebrew as well. Let alone when the evidence
shows that this is what the public wants.

Eyal, your suggestion that David is in someway so superior to Narkisim fails the
test of reality. It's your own personal preference. As a Serif font, some users
actually prefer the latter.
-> http://forums.ort.org.il/scripts/showsm.asp?which_forum=117&mess=2140195

No matter how you look at it, public preference is not as overwhelmingly in
favor of one of those as it is in favor of Arial.

Now, I've shown solid evidence as to why the Hebrew proportional font should be
the same as Japanese and Korean and be set to Sans Serif, how about providing
some counter evidence?

Prog.

	Eyal Rozenberg
	Comment 39 • 20 years ago

Very well. Referring to the survey you linked to above:

- The sampling of opinions on such an issues using 10-20 votes from visitors of
HWzone.co.il is quite unsound statistically.
- Changing a survey after a while and counting 'change' votes introduces an
irreparable statistical bias to the already shaky basis of validity.
- The question was taken out of context in two ways. For the first way, consider
what would happen if I were to ask people whether large or small caps are more
legible. They would obviously tell me large caps are more legible - but they
wouldn't really want to read all text in large caps. To a great extent it is the
same case with serif vs. sans-serif fonts. Using serif font by default has a
certain awkwardness to it which is independent of the question of legibility,
and this is almost as true in Hebrew as it is in English (this is of course just
my opinion; but others may share this opinion as well) .
- The second way the question was taken out of context was by the surveyed not
having taken into consideration (nor having been asked to take into
consideration) the fact that almost all page authors who do not specify font
families for their pages assume the default is serif font.
- Worst of all, the survey question was rigged, in two ways. First, people were
asked to choose between two sections of text which _formally_ have the same font
size, but _actually_ do not. Taking the first line of text in both choices
(which contains the same sentence fragment, i.e. "hasdara" up to "ota"), is
613px x 7px in the Arial section, v.s. 586px x 6px in the Narkisim section (used
the non-bold version; not countied vertical extrusions above the line, e.g. the
upper edge of the lamed or the lower edge of the quf; I checked the sizes using
the first image put forward, not the later modifications of the question, which
also do not seem to change this situation). To emphasize this last point, the
Narkisim text was rendered in ~85% of the height of the Arial text.
- The second way the question was rigged was by comparing the fonts at a small
size, rather than the normal size of text. It is a known fact that serif fonts
become much less legible (relative to sans-serif ones) as the font size
decreases, since they include more minute details. That is why almost all web
pages which use smaller-size font also make it sans serif.
- An issue which does not constitute rigging but is still problematic is the use
in different desktop environemtns of different methods for anti-aliased font
rendering - there may be pros and cons to serif vs sans-serif which are
dependent upon the type of anti-aliasing (e.g. in Windows, try the two options
in Control Panel|Display|Appearance|Effects|Method to smooth edges of screen fonts).
- Finally, the survey was designed and carried out by someone with an interest
in a certain particular outcome, with no control or review of the methodology by
someone impartial or of the opposite opinion; this, regardless of the specific
faults mentioned above, already constitutes a statistical inference faux pas.

It is true that David instead of Narkisim is a personal preference of mine
rather than an objective claim. However I will say that I have never witnessed
anyone producing printed or on-line text (other than large-font 'artistic'
titles) in Narkisim, in my life. My preference is also partly due to the fact
that the variant of Narkisim for non-anti-aliased 12pt is not one of its best
(at least on Windows), while that of David is one of its best. But regardless of
which serif font is better, your argument that sans-serif is preferred to serif
is very far from being supported by 'solid evidence'.

	Eyal Rozenberg
	Comment 40 • 20 years ago

To illustrate my criticism above, I've attached a screenshot of the effect of
setting the font to Arial, Narkisim and David on my system. No nominal font
size changes have been made (i.e. the effective font heights and widths vary,
but 'formally' these are all 16px fonts).

	Prognathous
	Comment 41 • 20 years ago

Eyal, the anti-aliasing in your comparison doesn't work due to Bug 172430.
Regardless, I still find Arial to be significantly more legible, and I am
certain that if you bother to do a survey you won't get 95% support or even a
majority to either of the Serif fonts.

Now back to your previous comment,

- 42 votes is not a large group, but it is much more useful than what you've
provided us with so far - the opinion of a single individual.
- I didn't change the survey. I just asked for comments about an additional
sample (David vs. Narkisim and Arial). Only one participant had something to add
about the new sample, and it didn't involve David.
- Your opinion about Serif fonts being easier to read for long texts, is exactly
as you state, "just an opinion". I happen to think the opposite, but I preferred
to go to the length of actually checking what others prefer.
- Page authors who don't specify font type should not rely on browser settings.
Similarly, page authors who don't check for document.all should not assume the
browser supports it. Can you provide any hard evidence that such page authors
even *know* the difference between the various font families?
- The font size used in the test was 10pt. Switching to Narkisim 11 or to David
11, while keeping Arial at 10pt would not have normalized their sizes but would
have actually made the first two much larger. Choosing the same size for all
fonts was not only a "formal" choice, it was the also the best way to make their
sizes as close as possible. It's also what would happen if this bug is fixed.
- The reason to start by comparing small sized fonts was quite simple: I believe
that Mozilla should provide defaults that work fine for every page and for users
with different screen/resolutions. I don't see the point in choosing a font
that's only usable in optimal conditions.
- The scope of the survey and the resources invested in it could not cover all
operating systems, anti-aliasing methods, screen resolutions and so on. It is a
best effort that displays what many of us already knew - Sans Serif fonts are
much more legible for displaying on-screen Hebrew. If you think otherwise, I
suggest that you set up a similar survey. If you manage to provide a much larger
test group with all possible variants, then that would of course be more through
than my own survey. When can we see the results?

Prog.

	Eyal Rozenberg
	Comment 42 • 20 years ago

The anti-aliasing doesn't work because it shouldn't work. The default for
windows is no anti-aliasing and that's fine by me. There's no bug here. This is
the same thing I, and the vast majority of Windows users, see in notepad and
word and inernet explorer and everywhere.

Also, I don't need to provide anything. You're the one who's claiming that
Hebrew is somehow different than Latin with respect to serif vs sans-serif font
preference, that sans serif fonts are have excessively low legibility, and
asking for a change of the default. But if you believe that Mozilla should
provide defaults that work fine for every page and for users with different
screen/resolutions, then what you _really_ want is to change the default to
sans-serif for Latin as well as Hebrew: I've attached as illustration an image
similar to that in your survey, with the only difference being the use of Latin
script instead of Hebrew. Arial has there an obvious leigibility advantage at
10pt, which only increases when you go down to 8pt (again note the fact that
the font sizes aren't really the same; the Times New Roman is much smaller than
the Arial at 10pt).

For the same reason Mozilla's default font is not being changed from serif to
sans-serif for Latin script, so should the case be for Hebrew script. And if
you claim otherwise, you need to show that solid evidence.

	Prognathous
	Comment 43 • 20 years ago

(In reply to comment #42)
> The anti-aliasing doesn't work because it shouldn't work. 

Oh yes it should work, just like it does in IE. Read Bug 172430 and test it
yourself. I've attached a testcase that proves it.

> ...if you claim otherwise, you need to show that solid evidence.

I already have. Now it's up to the component owner to decide if this 42
participant survey is solid enough evidence, or if he wants to rely on the
subjective opinion of a single individual.

Prog.

	Eyal Rozenberg
	Comment 44 • 20 years ago

(In reply to comment #43)
> Oh yes it should work, just like it does in IE.

It does 'work'. The current behavior is how it works, just like in IE. (Prog.
conceded this just now in bug 172430).

> this 42 participant survey 

You can get 42 Million people, not just 42, to say that 7-pixel-high Arial is
more legible than 6-pixel-high Narkisim or David. And they would be telling the
truth, too - just like someone who tells you 10pt Arial is more legible than
10pt Times New Roman. So what?

	Prognathous
	Comment 45 • 20 years ago

The fact is, the survey compared size 10 fonts. It also compared size 12 fonts.
http://www.hwzone.co.il/community/index.php?topic=89493.msg764201#msg764201

Note that since these are two different fnot families, your can't really
normalize their size. For example, the letter 'tav' (ú) is taller in David 12
than it is in Arial 12, while the letter 'vav' (å) is the same height. The only
way to compare them is to select fonts that are "foramally" eqaully, which is
exactly what the survey did.

Bottom line: Whether the above stands for more than your singled opinion, is for
the component owner to decide.

Prog.

	Prognathous
	Comment 46 • 20 years ago

Sorry for the typos, here's the text, corrected:

The fact is, the survey compared size 10 fonts. It also compared size 12 fonts.
http://www.hwzone.co.il/community/index.php?topic=89493.msg764201#msg764201

Note that since these are two different font families, you can't really
normalize their size. For example, the letter 'tav' (ú) is taller in David 12
than it is in Arial 12, while the letter 'vav' (å) is the same height. The only
way to compare them is to select fonts that are "formally" eqaull, which is
exactly what the survey did.

Bottom line: Whether the above stands for more than your singled opinion, is for
the component owner to decide.

Prog.

	Ernest Cline
	Comment 48 • 20 years ago

While the argument about which default default should be used for Hebrew (serif
or sans-serif) has been intellectually interesting to read, which _initial_
defaults Mozilla ships with for Hebrew is irrelevant to this bug.  That
discussion belongs in bug 149796 for Hebrew in particular and bug 61883 in
general.  This bug is about allowing the user to decide for himself what he
wants his _personal_ defaults to be on a basis that doesn't have to be the same
for all scripts.

	Hixie (not reading bugmail)
	Comment 49 • 20 years ago

This should get review from rbs and roc before check-in.

	Prognathous
	Comment 50 • 20 years ago

(In reply to Ernest Cline, comment #48)
> which _initial_ defaults Mozilla ships with for Hebrew is irrelevant to this bug.

The patch sets Sans-Serif as the default for Japanese, Korean and Chinese. It's
completely relevant to ask the same for Hebrew.

> (In reply to Eyal Rozenberg, comment #44)
> You can get 42 Million people, not just 42, to say that 7-pixel-high Arial is
> more legible than 6-pixel-high Narkisim or David. 

I can't belive I actually fell for that. THEY WERE ALL 7-PIXEL-HIGH FONTS. You
forgot to count the serifs.

The fact that Serif fonts waste a single line of pixels to just display the
serifs makes them visibly smaller, while their total (raw) height is actually
the same as Arial's. This is another great reason to choose Sans-Serif as the
default for Hebrew.

Ian, before checking anything in, please at least consult with Simon Montagu.

Prog.

	Eyal Rozenberg
	Comment 51 • 20 years ago

(In reply to comment #48)

I agree with Ernet Cline. I do, however, believe that a review of the entire set
of font defaults for Hebrew (serifness, face, size) is indeed due. But after
this bug is fixed.

	Hixie (not reading bugmail)
	Comment 52 • 20 years ago

Um, I'm not checking anything in, I was just saying that this would need review
from roc and rbs before checkin. It goes without saying that this would need
smontagu's input too, since it's an i18n bug.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 60 • 20 years ago

I tested the patch rv1.0 on Windows only.

	rbs
	Comment 61 • 20 years ago

Comment on attachment 170451 [details] [diff] [review]
Patch rv1.0(gfx/src)

It is pointless to have the member variable "nsCOMPtr<nsIAtom>	 
mGenericLangGroup". The fonts are Init()'ed only once, and so mGenericLangGroup
is going to receive the value of mLangGroup and retain that all the rest of the
time. (It wouldn't even worth having that member either way.)

All you have to do is change "font.default" to 
"font.default." + langGroup, like you did in your patch for layout/base.

	Asaf Romano (gone)
	Comment 62 • 20 years ago

Comment on attachment 170451 [details] [diff] [review]
Patch rv1.0(gfx/src)

Where is the mac part?

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 63 • 20 years ago

> Where is the mac part?

I cannot find the string "font.default" on Mac.
http://lxr.mozilla.org/seamonkey/search?string=%22font.default%22

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 64 • 20 years ago

(In reply to comment #61)
> (From update of attachment 170451 [details] [diff] [review] [edit])
> It is pointless to have the member variable "nsCOMPtr<nsIAtom>	 
> mGenericLangGroup". The fonts are Init()'ed only once, and so mGenericLangGroup
> is going to receive the value of mLangGroup and retain that all the rest of the
> time. (It wouldn't even worth having that member either way.)

I don't think so. Init() is called some time.
If I change |if (mGeneric.IsEmpty() || mGenericLangGroup != mLangGroup)|
to |if (mGeneric.IsEmpty())|, the patch does not work fine on testcase.
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=2514&action=view

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 65 • 20 years ago

Comment on attachment 170451 [details] [diff] [review]
Patch rv1.0(gfx/src)

Please re-review for comment 64.

	rbs
	Comment 66 • 20 years ago

Init is called only once -- otherwise there would be leaks from objects that are
new()'ed in the Init() and not deleted until the font is destroyed. The several
Init() that you see are likely coming from different font metrics instances.

Try clearing mGeneric before calling "EnumerateFamilies", i.e.,

+ mGeneric.Truncate();
  mFont.EnumerateFamilies(FontEnumCallback, this);

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 71 • 20 years ago

I removed |mGenericLangGroup| member and the code of copying generic font.
Because we can copy the generic font when mLangGroup of each instances must be
same value only.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 72 • 20 years ago

Oops...
I fogot camino. We must change the pref of camino.
http://lxr.mozilla.org/mozilla/source/camino/PreferencePanes/Appearance/Appearance.mm

But I cannot change it. Because it is not either C++ or Javascript.
I hope you make a patch.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 75 • 20 years ago

Changing priority and target milestone.
I hope this is fixed on Firefox1.1 and Mozilla 1.8.
Because this issue is important for marketing of Mozilla Japan.

	rbs
	Comment 76 • 20 years ago

Comment on attachment 170560 [details] [diff] [review]
Patch rv1.1.3(gfx/src)

This patch is incorrect.

I am going to explain a bit more what is happening. Suppose you have the
following elements:

1. <span style="font-family: Arial, serif">
   in this case, the font is fully specified, and mGeneric should
   have "serif".

2. <span style="font-family: Arial">
   in this case, the generic is missing, and mGeneric is inferred
   from font.default.[mLangGroup]

   -> therefore, if in your patch you forcibly treat case 1 as case 2,
      it is incorrect (which is why I am minusing the patch).

3. <span lang="en>
   you should check that the font ultimately used for this element is 
   font.name.[font.default.en].en
	     [actual mGeneric]

   In other words, there is subtle second level of indirection.
   Of course, "font.default.en" must have, say, sans-serif (= mGeneric)

4. <span lang="ja">
   check here that the font ultimately used for this element is 
   font.name.[font.default.ja].ja
	     [actual mGeneric]

   Here too, "font.default.ja" must have, say, serif (= mGeneric)

This is the behavior expected by design. If you are not seeing this
in your testcase, then something unexpected is going on.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 77 • 20 years ago

O.K.
I mistook for the role of mGeneric.
But this patch is _not_ influence of lang attribute.
But I think it is right for CSS inheriting system.
Therefore, the "font.default.[langGroup]" is influence of the document's
encoding.
See following testcases.

	Benjamin Smedberg
	Comment 81 • 20 years ago

The generic font should depend on the language, not the encoding. If there is no
language specified, it is fine to guess the language from the repertoire being
used or from the encoding, but we should definitely not be using the encoding as
our only guide. What happens for universal encodings like utf8?

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 82 • 20 years ago

On my system(Win2000-JA), Testcase of ISO-8859-1 is rendered with serif font.
And other testcases are rendered with sans-serif font.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 83 • 20 years ago

For test.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 84 • 20 years ago

the screenshots of Testcase of ISO-8859-1 and Testcase of Shift_JIS are here.
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=2545&action=view
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=2546&action=view

I don't change Mac's source code, but it is fixed on mac too.

	rbs
	Comment 87 • 20 years ago

Comment on attachment 170737 [details] [diff] [review]
Patch rv1.2.1(gfx/src)

r=rbs, this is all what GFX needs.

The remaining problem that you mentioned comes from
nsPresContext::GetDefaultFont() in layout. It has to be updated to also take a
language as parameter (this will introduce a perf hit for the sake of
correctness). With its current signature, the Style System initializes sytle
contexts with the same font for the document-wide's language (as specified or
inferred), instead of the default font for the particular language of the
element. It matters significantly now because font.default has become
font.default.langGroup. Care to file another bug about this problem?

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 88 • 20 years ago

I think that on style system, we should inherit font of all element that is not
spacified 'font-family'.
If we update the default font per different langGroup element, it is not this
system.

e.g.,
<p lang="ja">
  <span lang="en">english</span>
</p>

I think the span[lang=en] should inherit default font from p[lang=ja].
If it is not inherited, the computed style of span[lang=en] is 'serif' but the
parent element has the computed style is 'sans-serif'.
I think it is wrong.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 89 • 20 years ago

Comment on attachment 170455 [details] [diff] [review]
Patch rv1.0(prefwindow)

Ben:
Could you review it?

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 90 • 20 years ago

Comment on attachment 170458 [details] [diff] [review]
Patch rv1.0(all.js)

Simon:

Could you review it?
I hope that you review that the each langGroup's default font are fit.

	rbs
	Comment 91 • 20 years ago

Re: comment 88
You are saying conflicting (or perhaps inarticulate) comments (one of which is a
wrong interpretation). Anyway, this bug is not a good place to discuss that.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 92 • 20 years ago

I tested follwing systems.
Win2000, GTK2+xft, GTK.

And in bugzilla-jp, tested on MacOS X by contributer.

	neil@parkwaycc.co.uk
	Comment 93 • 20 years ago

Comment on attachment 170455 [details] [diff] [review]
Patch rv1.0(prefwindow)

r=me if you fix these nits:

>-    var lists = ["selectLangs", "proportionalFont"];
>+    var lists = ["selectLangs"];
>     for( var i = 0; i < lists.length; i++ )
We now have a for loop that executes once... seems wasteful ;-) Just inline the
single value into the loop body.

>-    var lists = ["selectLangs", "proportionalFont"];
>+    var lists = ["selectLangs"];
>     var prefvalue;
>     
>     for( var i = 0; i < lists.length; i++ )
Same thing here.

>+            currDefaultFont = pref.getComplexValue( defaultFontPref, Components.interfaces.nsISupportsString ).data;
These should all use parent.hPrefWindow.getPref - don't bother changing the
existing ones, that's a separate bug, but use it for the new one (like you
correctly did for setPref).

>+        var defaultFontPref = "font.default." + languageList.value;
>+        var defaultFontVal = parent.hPrefWindow.pref.getComplexValue( defaultFontPref, Components.interfaces.nsISupportsString ).data;
>+        defaultFont.selectedItem = defaultFont.getElementsByAttribute( "value", defaultFontVal )[0];
This is also the wrong way; as well as using getPref the old selectedItem
technique is out of date. Correct code would be
defaultFont.value = parent.hPrefWindow.getPref("string", "font.default." +
languageList.value);

	Simon Montagu :smontagu
	Comment 97 • 20 years ago

Comment on attachment 170458 [details] [diff] [review]
Patch rv1.0(all.js)

>+pref("font.default.ar", "serif");

>+pref("font.default.he", "serif");

Please make .ar and .he default to sans-serif everywhere. I don't know what is
best for the Indic scripts, but we can always change the defaults in later
bugs.

r=smontagu with the changes to Arabic and Hebrew

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 98 • 20 years ago

all.js is updated.

	neil@parkwaycc.co.uk
	Comment 99 • 20 years ago

Comment on attachment 170880 [details] [diff] [review]
Patch rv1.3(prefwindow)

I've really opened a can of worms, haven't I ;-) Don't feel like you have to
fix these, after all, you're only reindenting. I also found a bug in the
existing code, you don't have to fix that either :-)

>+    if( !( "dataEls" in dataObject ) )
>+      dataObject.dataEls = [];
>+    dataObject.dataEls[ "selectLangs" ] = [];
Ideally I think these should use {} instead of []. Also, because "selectLangs"
is an identifier, you can use dataEls.selectLangs in place of
dataEls["selectLangs"] in several places, e.g.
dataObject.selectLangs = {};

>+        element.selectedItem = element.getElementsByAttribute( "value", aDataObject.dataEls[ "selectLangs" ].value )[0];
element.value = aDataObject.dataEls.selectLangs.value; should work.

>+            var prefvalue = parent.hPrefWindow.getPref( preftype, prefstring );
>+            element.selectedItem = element.getElementsByAttribute( "value", prefvalue )[0];
element.value = parent.hPrefWindow.getPref(preftype, prefstring); should work.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 100 • 20 years ago

this issue is important for marketing of Mozilla Japan.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 101 • 20 years ago

Comment on attachment 170906 [details] [diff] [review]
Patch rv1.4

r=everyone, sr=me

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 102 • 20 years ago

I checked this in. Thanks for all the work!!!!!

	Asaf Romano (gone)
	Comment 103 • 20 years ago

Thanks Masayuki!

Note you should contact Ben Goodger (ben at mozilla org) for pref window
changes... He may override your changes in the new options dialog bug / branch
(see bug 274712).

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 104 • 20 years ago

Thank you, everyone.

I separated new bug for prefernce dialog of camino.
That is bug 279533.

	Eyal Rozenberg
	Comment 105 • 20 years ago

(In reply to comment #97)
> Please make .ar and .he default to sans-serif everywhere. I don't know what is
> best for the Indic scripts, but we can always change the defaults in later
> bugs.

Why was this snuck in despite being the object of an argument? Simon, that
wasn't fair of you.

	Simon Montagu :smontagu
	Comment 106 • 20 years ago

(In reply to comment #105)
> Why was this snuck in despite being the object of an argument? Simon, that
> wasn't fair of you.

I personally also prefer serif (I will be changing the default in all my new
installations), and I take the statistics quoted here with a large grain of
salt. Even so, sans-serif seems to be what the majority of Hebrew-speaking users
want. We can't please all the people all the time.

	Jungshik Shin
	Comment 107 • 19 years ago

bug 283461 was filed to address the issue rbs raised in comment #87 and comment #91.