Open Bug 1044461 Opened 10 years ago Updated 2 years ago

Monospace font family for Unicode mails is controlled by settings for Western

Categories

(Thunderbird :: Message Reader UI, defect)

31 Branch
x86_64
Linux
defect

Tracking

(Not tracked)

People

(Reporter: gerhard.grossmann, Unassigned)

References

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140715214327

Steps to reproduce:

The font size (and spacing) of the Western monospace font seems to be controlled by the Unicode monospace font.

To reproduce this, establish the following setting: Choose a plain-text mail with encoding “Western” so that it’s displayed in the mail view field. Then I go to Edit > Preferences > Display > Formatting > Advanced (Fonts & Colors).

Choose fonts for Western, set the monospace font for example to Ubuntu Mono, 16pt. Do the same for the Unicode fonts. The checkbox “Use fixed width font for plain text messages” has to be checked. Now close the Advanced window with OK, change to the main window, choose another mail and come back to the plain text mail. That’s the basic setting of this experiment.

Open the Advanced window again, choose fonts for Western and change the font size of the monospace font to something extreme, for example 28pt. Press OK, go to the main window, change to another mail and come back to the plain text mail.
→ No change in font size (also if you close and re-open thunderbird)

Open the Advanced window, chose fonts for Unicode and change the font size of the monospace font for example to 9pt. Press OK, go to the main window, change to another mail and come back to the plain text mail.
→ The font size has decreased.

To make clear, that you don’t have a mail with Unicode setting just change the Western monospace font to something obvious like Comic Sans or FreeSerif. The font-family changes, the font size is still the Unicode one’s.

More surprisingly: Not only the font size but also the spacing of the Western monospace font is controlled by the Unicode setting. Go back to the setting of the second paragraph (both Unicode and Western monospace font set to Ubuntu Mono, 16pt). Don’t forget to choose another mail and come back to the plain text mail to see the effect.

To better see the difference you could take a screen shot of the mail. Now open the Advanced window, chose fonts for Unicode and change the font FAMILY to a font, that has a different line-spacing (for example FreeSerif, Liberation Mono or Fira Mono). Leave the font size untouched. Close the Advance window and the effect is immediately visible: The line-spacing changes, the font stays the same.


Actual results:

The font size and spacing of the Western monospace font is controlled by the settings for Unicode.


Expected results:

These to settings should be independent, the setting of the size in Western should have an effect on the displayed font size.

(By the way: I tested this in the safe-mode with disabled addons.)
SORRY: The encoding of the mail seems to be utf-8 (mail source: Content-Type: text/plain; charset=utf-8). So the real problem is, that the font-family of Unicode mails is picked by the setting for western, while the family setting of Unicode is ignored.
Summary: Display font size/family and encoding Unicode/Western → Monospace font family for Unicode mails is controlled be settings for Western
Summary: Monospace font family for Unicode mails is controlled be settings for Western → Monospace font family for Unicode mails is controlled by settings for Western
See Also: → 1254053
Please read bug 1254053 comment #4.

The font for unicode e-mail (UTF-8) is picked from "Other Writing Systems".
The font for western e-mail (windows-1252, ISO-8859-*) is picked from "Latin".

In attachment 8697225 [details] from bug 1228193 you see a picture of the mapping.
In bug 1228193 comment #10 the resident expert explains how it works. Note that for plain text e-mail there is no language attribute, to the writing system is derived from the font alone.
Correction:
Note that for plain text e-mail there is no language attribute, so the writing system is derived from the *charset* alone.

Can you please supply more evidence, otherwise I'll close the bug as "works for me".
Flags: needinfo?(gerhard.grossmann)
See this attachment. It’s a plain text mail. My settings for the monospace font („Feste Breite“) are the following.

Latin: URW Chancery L, size: 28.
UTF-8: Source Code Pro, size: 15.

But none of this setting is applied to the mail. Instead it’s shown in URW Chancery L (from Latin) and size 15 (from UTF-8). Either the size is ignored (if the mail was identified as Latin) or the font-family (if identified as Unicode).
Flags: needinfo?(gerhard.grossmann)
The bugmail in your picture is UTF-8 encoded and should pick its font and size from "other writing systems". You will believe me without showing a screenshot that when I configure "other writing systems" to use - say - Aharoni and size 20, I get exactly that on Windows. Promise. I tried a few versions (31, 38, 47) and they all work. So this seems to be a Linux problem.

We have Linux developers, so let's CC them. Aceman, can you reproduce this on Linux?

Moving to "New" as per the supplied screenshot.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(acelists)
Confirmed on Linux with TB 38.6 with UTF-8 bugmail:
Font comes from "Latin", size comes from "Other Writing Systems".
Crazy!
Yes, confirming on linux.
It is also interesting that changing font (in Latin) is applied to the current message immediatelly after closing Preferences. The change in font size is applied after viewing another message.
Flags: needinfo?(acelists)
Attached file UTF-8 encoded page
Ultimately the rendering of the page is done in M-C code. So I played around in FF a bit. The enclosed page is encoded in UTF-8. In FF 45 on both Windows and Linux the font and size are driven by the "Latin" (!!) writing system.

This is strange, since in TB on Windows it's the "Other Writing Systems" that drives it, and on Linux it's a strange mix between "Latin" (font) and "Other Writing Systems" (size).

This is particularly strange since in bug 1228193 someone complained that the details are derived from the "Other Writing System" (most likely that person was on Windows) and the resident expert explained in bug 1228193 comment #10 how it is done.

Henri, may I ask once again. I have this page open in FF:
<html>
<head>
<meta charset="UTF-8">
</head> 
<body>
<tt>This is UTF monospace (tt) text: äöüß</tt><br>
This is UTF normal text: äöüß
</body>
</html>

There clearly is no language indicated. Why does it still use the font/size from the "Latin" writing system when in bug 1228193 comment #10 you said (quote):
====
If there is no declared language, the writing system is guessed from the character encoding according to the mapping in https://mxr.mozilla.org/mozilla-central/source/dom/encoding/encodingsgroups.properties?force=1 .
====
In the source you mention, UTF-8 does not appear, so I assume it goes as per the comment:
  x-unicode is assumed for encodings not listed here
Flags: needinfo?(hsivonen)
(In reply to Jorg K (GMT+1) from comment #8)
> There clearly is no language indicated. Why does it still use the font/size
> from the "Latin" writing system when in bug 1228193 comment #10 you said
> (quote):
> ====
> If there is no declared language, the writing system is guessed from the
> character encoding according to the mapping in
> https://mxr.mozilla.org/mozilla-central/source/dom/encoding/encodingsgroups.
> properties?force=1 .

I was wrong and that wasn't the whole story for encodings that aren't on that list, the default depends on the locale:
https://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresContext.cpp#1225
Flags: needinfo?(hsivonen)
can you suggest a component to move this to?
Flags: needinfo?(acelists)
Unless it is actually a bug in gecko, as indicated by comment 8 and later.
Component: Untriaged → Message Reader UI
Flags: needinfo?(acelists)
Looks like the reference is here now:
https://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresContext.cpp#1016
1015     if (mLanguage == nsGkAtoms::Unicode) {
1016       mLanguage = mLangService->GetLocaleLanguage();

Also see bug 91190.
See Also: → 91190
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: