Closed Bug 1254053 Opened 8 years ago Closed 8 years ago

euc-kr plain text emails display with a larger font than other "normal" encodings

Categories

(Thunderbird :: Untriaged, defect)

38 Branch
x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: hong, Unassigned)

References

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0 Iceweasel/44.0.2
Build ID: 20160214093701

Steps to reproduce:

Open a plain text email encoded in base64:

    Content-Transfer-Encoding: base64



Actual results:

The font looks larger (and stranger) than other plain text emails. Zoom out makes the font normal in this message, but also making other messages look smaller than normal.


Expected results:

The font should be a similar size with other plain text emails.
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Please attach a sample as .eml
You're sure it's not just different due to character encodings? (You can set sizes for each font.)
Indeed this is caused by a different character encoding (euc-kr)! But why changing the font size of euc-kr also changes the font size of UTF-8 emails?
Maybe related: bug 1044461
Summary: base64 encoded plain text emails display with a larger font than other "normal" encodings → euc-kr plain text emails display with a larger font than other "normal" encodings
See Also: → 1044461, 1228193
I have created myself five plain text e-mails:

UTF-8:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

Korean:
Content-Type: text/plain; charset=EUC-KR; format=flowed
Content-Transfer-Encoding: 7bit
and
Content-Type: text/plain; charset=EUC-KR; format=flowed
Content-Transfer-Encoding: base64

Western:
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
and
Content-Type: text/plain; charset="windwows-1252"
Content-Transfer-Encoding: 7bit

I've configured UTF-8 (Other Writing Systems) to use font Aharoni, size 34.
I've configured Korean to use font GulimChe, size 9.
I've configured Latin (Western) to use font Batang, size 14.
I can clearly distinguish the three different fonts/sizes.

I've also checked "Use fixed width font for plain text messages".
Note: If you don't check that, the font/size configured for proportional will be used. 

Result: All four messages display as expected. There is no problem. The Content-Transfer-Encoding has no influence on the text display.

If you want to pursue the alleged problem further, you need to add screen shots.
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, so the writing system is derived from the font alone.
Can you please supply more evidence, otherwise I'll close the bus as "works for me".
Flags: needinfo?(hong)
My comment #4 relates to Windows. In bug 1044461 on Linux we see that there's something wrong.
I tried this on a Linux Mint system with TB 38.6.
For a message encoded in EUC-KR, the font and size can be set by making adjustments for the Korean writing system. When changing the settings for Korean, the settings for UTF-8 are not affected and UTF-8 mail displays as before.

So unlike bug 1044461, I can't see a problem here.

Reporter: Please supply screenshots or I will close this bug.
Yes, I've also tried on Linux and an EUC-KR message (manually crafted) observed font settings for the Korean "writing system".

UTF-8 or ISO latin 1 encoded messages did not use the font defined for Korean. I tried on TB47 trunk.
Attached image utf-8
The attachment is the UTF-8 encoding display.
Attached image kr.png
This attachment is the kr display. You can see that the display of kr is elongated vertically. However, if I zoom out, the font can look exactly the same as utf-8, but other utf-8 messages are also zoomed out.

I checked my preference for Korean: It is exactly the same as the "Other Writing System" (I never touched the settings).
Flags: needinfo?(hong)
Thanks for the images.

So you're saying that you configured "Korean" and "Other Writing Systems" to use the same font and size, however the Korean looks different? Like "taller" (elongated vertically).

Then you're also saying that when you change the size for the Korean writing system, the setting for "Other Writing Systems" is also affected? Or the setting is not affected, but the display is?

I'm still not sure what it is exactly that isn't working for you.

Why don't use use very different fonts and sizes, like URW Chancery L, so the difference is obvious.
(In reply to Jorg K (GMT+1) from comment #12)
> Thanks for the images.
> 
> So you're saying that you configured "Korean" and "Other Writing Systems" to
> use the same font and size, however the Korean looks different? Like
> "taller" (elongated vertically).
> 
> Then you're also saying that when you change the size for the Korean writing
> system, the setting for "Other Writing Systems" is also affected? Or the
> setting is not affected, but the display is?
> 


I did not change the size in the preference. What I did was open a kr message, and zoom in and out with mouse scroll. Then open a UTF-8 message, the size also changes. I consider this is expected, but that also means for me that kr and utf-8 messages cannot be both read with a normal font without scrolling the mouse back and forth.
I still don't understand what the problem is.

Yes, if you zoom, the zooming will affect all messages regardless of the encoding.

Are you saying that you want to view EUC-KR and UTF-8 messages with different zoom factors?

Why don't you just configure a larger size for EUC-KR messages, so the size is larger and you don't have to zoom?
Looks like I can tweak kr font size to make both kinds of messages look normal. Thanks for all the help.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: