Closed
Bug 458497
Opened 16 years ago
Closed 6 years ago
Font chaos in Message Pane, Values of "Preferences->Display->Fonts" are used faulty
Categories
(Thunderbird :: Message Reader UI, defect)
Tracking
(Not tracked)
People
(Reporter: samuel.falk, Unassigned)
References
(Depends on 1 open bug, )
Details
(Whiteboard: [dupeme?])
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: version 2.0.0.17 (20080914)
As we always want the same Font to be shown in all received Messages, the following preferences are set:
Preferences->Display->"Use the following Font" = "Variable Width Font" Size=15
Preferences->Display->Fonts->Proportional = "Sans Serif"
Preferences->Display->Fonts->Serif = "Century"
Preferences->Display->Fonts->Sans-serif = "Century"
Preferences->Display->Fonts->Monospace = "Century" Size=15
Preferences->Display->Fonts->"Minimum font size" = 15
Preferences->Display->Fonts->"Allow Messages to use other Fonts" = NO/disabled
We used the Century Font, cause the wrong font displayed is like an Arial, and so the problem is difficult to detect with Sans serif fonts.
It seems that the Problem very often occurs, if people write their Mail in eg. an Microsoft Word, and then copy and paste the text. But there is no connection to Thunderbird, for example they copy their text in a Web Mail Interface and send the message.
Other Mail Clients do not have a Problem eg. Apple Mail. Also we cannot change how other people create their Emails, so the problem has to be solved in Thunderbird.
As every copy and paste changes the content, i could not copy and paste the source of the mail, but i saved a test message as an EML file and if this file is opened and vied with Thunderbird and the Preferences are set as told above, the totaly wrong displayed fonts are reproduced.
In one Line of this test message the word "ErdenWärts" suddenly is the correct Fonts set in the Preferences.
This Bug? happens 5% of all incoming Mails.
In the URL Field i entered the URL of an EML File that shows the Bug when viewed in Thunderbird.
Reproducible: Always
Steps to Reproduce:
1.Incoming Email with content http://s3.nativesolutions.at/thunderbird/font_problem.eml
Actual Results:
I saved one Testmail als "font_problem.eml". If this Email is "open with" Thunderbird, the wrong Fronts used are shown. Instead of the set "Century" Font (just for the best viewing of the bug) an "Arial" is shown, and in one Line suddenly the "Century" is shown (the word "ErdenWärts" is Font Century).
Expected Results:
The whole Message should be shown in the Font "Century" with Font Size 15, as set in the Preferences.
This Bug also happens in the German Version (a view days ago tested with a friend) AND also happens in the latest Alpha of Thunderbird 3.
If you want to work seriously on content, it is a breakdown to have a mismatch of Fonts, even different Fonts in one line of a message. So i set the Severity to "A major feature is broken".
One major additional Information:
If such a message which displays different Fonts is replied, the text which is then under "Quotation" is shown correct. Also if "Edit as New" is choosen, the bug disappears. This should help finding the bug.
Comment 2•16 years ago
|
||
(In reply to comment #0)
> the wrong Fronts used are shown.
What do you mean by your "wrong"?
"Wrong" based on "well documented spec/design/RFC/ECMA,.."?
If yes, what is the documentation of spec/design of Tb or Mac OS X, documentation of RFC/ECMA etc.?
Or it merely means "different from you expectation"?
> following preferences are set:
>(snip)
> Preferences->Display->Fonts->Proportional = "Sans Serif"
>(snip)
> Preferences->Display->Fonts->Sans-serif = "Century"
> Preferences->Display->Fonts->Monospace = "Century" Size=15
> Preferences->Display->Fonts->"Minimum font size" = 15
> Preferences->Display->Fonts->"Allow Messages to use other Fonts" = NO/disabled
Above is for which "Fonts for:"? For "Western" isn't it?
> Steps to Reproduce:
> 1.Incoming Email with content
> http://s3.nativesolutions.at/thunderbird/font_problem.eml
The mail says:
> Content-Type: text/plain; charset=UTF-8; format=flowed
AFAK, font selection for charset=UTF-8 doesn't base on font settings for "Western".
What fonts are set for "Other Languages" and "User Defined"?
(AFAIR, "Other Languages" is used for unicode mail. I saw bugs for difficulty in font setting for unicode data due to the unclear words in font setting for unicode data and unclear words for region/language and charset.)
> "Arial" is shown
I think it can explain your problem, because "font selection" has mechanism of "font selection based on alphabetic order of listed font names" in it. And, "Arial" is the font listed at top in many environments as font satisfies conditions for font search(such as, Sans-Serif, has code-point, supported language, ...).
> Also if "Edit as New" is chosen, the bug disappears.
Note that followings for used charset(if no other settings affects on it):
- When display of mail, charset=xxx in Content-Type: header of the mail
- When compose a mail, "default character encoding for compose" by your setting
"Font selection" depends on charset used to display/compose a mail.
Please never confuse charset choice and font selection based on charset.
(In reply to comment #2)
> What do you mean by your "wrong"?
> "Wrong" based on "well documented spec/design/RFC/ECMA,.."?
> If yes, what is the documentation of spec/design of Tb or Mac OS X,
> documentation of RFC/ECMA etc.?
> Or it merely means "different from you expectation"?
It is really not a matter of "expectation". It is well defined,
for what the values set in Preferences->Display are for.
They control the way which font is used when displaying Text.
The simple problem is, open the Mail "font_problem.eml" and the
Values set in Preferences->Display do not change the displaying font consistantly.
It is no matter what font you configure under Preferences->Disply.
I just told that the error or bug is not visible when you choose coincidence the same font as the bug shows.
The Value Preferences->Display->Fonts->"Allow Messages to use other Fonts" = NO/disabled is self describing. If you do not allow Messages to use other
Fonts, then it is a Bug if other Fonts are used, and it cannot be a feature, if some words in a line suddenly change their font.
> Above is for which "Fonts for:"? For "Western" isn't it?
Yes, in this example for Western.
> Steps to Reproduce:
> 1.Incoming Email with content
> http://s3.nativesolutions.at/thunderbird/font_problem.eml
The mail says:
> > Content-Type: text/plain; charset=UTF-8; format=flowed
AFAK, font selection for charset=UTF-8 doesn't base on font settings for
"Western".
What fonts are set for "Other Languages" and "User Defined"?
(AFAIR, "Other Languages" is used for unicode mail. I saw bugs for difficulty
in font setting for unicode data due to the unclear words in font setting for
unicode data and unclear words for region/language and charset.)
> > "Arial" is shown
> I think it can explain your problem, because "font selection" has mechanism of
"font selection based on alphabetic order of listed font names" in it. And,
"Arial" is the font listed at top in many environments as font satisfies
conditions for font search(such as, Sans-Serif, has code-point, supported
language, ...).
It is not my problem, and you argue with the values in the content of the sent mail. No one can control the content that is sent. Exactly for that reason the Configuration in Preferences->Display is possible.
To argue why something maybe is shown with a false font does not solve the problem, that only one font (for what the Preferences->Display are for) have to be shown. Usually you set the font you are working with in your documents.
> > Also if "Edit as New" is chosen, the bug disappears.
> Note that followings for used charset(if no other settings affects on it):
- When display of mail, charset=xxx in Content-Type: header of the mail
- When compose a mail, "default character encoding for compose" by your
setting
"Font selection" depends on charset used to display/compose a mail.
Please never confuse charset choice and font selection based on charset.
What charset ever is used in the header of the mail, don´t you agree, that this does NOT explain, why suddenly in one text line the font changes for one word?
This is something strange. This is an inconsistent behavior to your explanation. If this change of font in one word would not be, then the next problem could be, that the configuration parameters are too weak, cause they only set values for one font eg. Western. But let as look first on the inconsistent behavior.
It is no solution to set "Apply the default character encoding to all incoming messages", cause for example charates as umlauts (ä, ü, ...) are destroyed.
But this does not happen when "Edit as New" or "Reply" is used.
As well "Allow messages to use other fonts" is disabled.
So for some mails sent there is no possible configuration to get the font you want to work with. This is the problem, and additional there is an inconsistent behavior when suddenly in one line one or more words are displayed in the font set in the preferences.
Comment 5•16 years ago
|
||
Thank you Magnus Melin, cause i´am really interested in solving this problem or bug. Bug 91190 does not include the inconsistent sudden change of fonts at words in lines. No parameters or tokens are in the message and suddenly the font changes at a word or line. So the font set in the preferences is used, but only at a view words or lines. So Bug 91190 does not include the problem or bug.
Please could anybody answer if with the given URL (eml file) and my poor explanation in english can reproduce the behavior? The word "ErdenWärts" suddenly changes the font in the given example.
Comment 7•16 years ago
|
||
(In reply to comment #5)
> Bug 91190?
Thanks for pointing to correct information about font selection for Unicode.
(In reply to comment #3)
> But let as look first on the inconsistent behavior.
(In reply to comment #6)
> So Bug 91190 does not include the problem or bug.
Problems/phenomena described in Bug 91190 is different from your request, but the bug can explains some phenomena occur upon you.
(1) A font is selected for unicode display (say Font-A)
(2) Till "W", before "ä", characters are displayed by Font-A
(3) Font-A doesn't have code point for "ä" (U+00E4, UTF-8=0xC3A4),
then font switch occurs. (say Font-B)
(4) "ä" is displayed by Font-B
(5) When Font-B has code point for following characters(rts... in your case),
switch back to Font-A doesn't occur in some situations.
I saw the phenomenon in next case during font related test in the past.
(With very special characters & fonts. Two concecutive font switch occurs)
Code-1 Code-2 Code-3
Font-A : O X X (Font-A is default font for the charset)
Font-B : O O X (O : Has code point)
Font-C : O X O (X : Doesn't have code point)
When sequence of (1)Code-1, (2)Code-2, (3)Code-3, (4)Code-1:
(1)Code-1=Font-A, (2)Code-2=Font-B, (3)Code-3=Font-C, (4)Code-1=Font-C
This problem in step (5) causes different shape of same character for Code-1. And, if design of font is different between Font-A and Font-C, display becomes ugly. I don't know exact condition, but at least "line break" seems to invoke "font selection from initial". "Return to initial font" possibly occurs at "word boundary(a space)".
> The word "ErdenWärts" suddenly changes the font in the given example.
Phenomenon depends on environment : installed fonts, font used by system, font specified in Tb's profile, etc. I couldn't re-produce phenomenon by your test mail. I use MS Win-XP SP3, and I install some additional fonts such as Arial Unicode MS, and many of my fonts for single byte char has code point for "ä".
There are at least two problems in font selection area: Bug 91190(font selection for unicode), other bugs(not-imaginable font swiching behavior. sometimes inconsistent for user, sometimes unwanted display for user)
To samuel.falk@aon.at(bug opener):
Your request sounds for me to be following.
Choose a font which can display all characters in data since initial,
instead of using "font switch" mechanism.
Is it right?
But, please consider my case (5) in above. There is no super font in that case.
Or next request?
Use font you specified in "Font for: Western" of Tb's profile when Unicode?
The Problem is not a font which can display all characters in data since initial,
case any font like Arial, Century, New York, Futura and so on have the characters like "a", "b", ... , AND also "ä", "Ä", "ü" ....
And Thunderbird itself can show everything correct for example if you select the Mail and choose "Edit as New". There you are, everything is then shown in the Font you have choosen in the preferences for "Display" and no problems with "ä" or any other character. Every character can be shown (as known).
BUT, if you change instead anything in the preferences with "Default character encodings" "for incoming mail" (force an other encoding) - yes - there is the problem of "ä" which then will be a chunk of garbage.
But there is one step as i told, so that everything is shown correct:
"Edit as New" shows everything correct, or a "Reply". What is changed in the source when "Edit as New" is executed? And if nobody has a disadvantage, couldn´t it be done to display mails as if "Edit as New" has been choosen.
This would be the solution, but i do not know what is done in "Edit as New", but it solves the Problem.
When and where do we have the possibility to get this done as an improvement, cause there is no inconsistent switching of fonts in an mail whre "Edit as New" has been done.
Now it is profen as a Bug, cause the content written an displayed in the "compose" window looks good, but afterwards displayed after sending in the "Mail Window Front End" the displayed font is wrong.
By the way, it is also not consistent, that in the compose window a Quotation (Reply) is just marked with a blue line on the left side, and afterwards in the "Mail Window Front End", after the mail is sent and selected in the sent folder, also the text beside the blue line is blue.
The whole problem i´am talking about is simply solved when everything is displayed like the Compose window displays the messages.
Concerning the Quotation and the blue text it would be best that everywhere also the text beside the blue line is also blue.
I´am writing this final content, cause i thing that this consistency problem of displaying mails (fonts and quoted text) could be solve in a day by an insider. Can´t anybody involved in the project correct this problem "in a minute", cause how text is already displayed in the compose window just has to be used for the display of the Mail Window Front End.
Thanks in advance.
Sam
Comment 10•16 years ago
|
||
Sam: for me, in Shredder nightlies, if I set the font for "Other languages" (which corresponds to UTF-8), then that font is used when reading your test message. I can't reproduce a problem.
(The "Other languages" menu item is hard to find -- it's in the popup menu that most likely says "Western" or something like that in german, but way at the bottom)
Note that it's possible that the composition window uses the font specified in the Western setting, but that the message reader uses Other Languages, because in between the message is encoded in UTF-8.
That would likely explain this bug, as far as I understand it.
Comment 11•16 years ago
|
||
Re "the blue": the plain text quote is only blue if you set it so (under Options | Display | Formatting | When displaying quoted.....).
Comment 12•16 years ago
|
||
Bug 323747 is report of similar phenomenon when mail composition in UTF-8.
To Sam(bug opener): Read Bug 323747 Comment #5, please.
Reporter | ||
Comment 13•16 years ago
|
||
(In reply to comment #11)
Of course, but it does not work, please verify when you reply a message and are working in the compose window, there your quoted text wont be blue, just the line to the left ist blue. Or if you "Past as Quotation" the same. Not the possiblity of configuration is the problem i´am talking about, the problem ist, that the configuration does not work. Some Parameters do not work in the mail window front end, some do not work in the compose window (the blue font is black there).
Reporter | ||
Comment 14•16 years ago
|
||
Additional informations:
It ist not the case (as mentioned above) that the font switching ist done cause there are some characters like 'ä', 'ö' and so on, cause exactly when such characters are used in a line, then the correct font set in the preferences is used in the line. So the argument, that the charecters are not available and then a font switch is done is wrong. The font switch is done without any reason, cause no font switch is done in the compose window, and the font switch is done in the mail window front for characters like 'a', 'b', 'c', and NOT, cause the charecter 'ä' ist not available.
Comment 15•16 years ago
|
||
(In reply to comment #13)
That setting is for *displaying* plain text messages, not for color during composition. (Otherwise it would be confusing to know if you sent a msg with colored text or not.)
Updated•15 years ago
|
Component: Mail Window Front End → Message Reader UI
QA Contact: front-end → message-reader
Comment 16•9 years ago
|
||
Is this really Mac only?
Surely this and bug 91190 are not the only ones which describe this problem?
Depends on: 91190
Whiteboard: [dupeme?]
Comment 17•6 years ago
|
||
Magnus, do you still think this is the same as Bug 91190, or related?
(Sam's email bounces.)
Flags: needinfo?(mkmelin+mozilla)
Comment 18•6 years ago
|
||
Probably, and perhaps something else - but we will never know.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(mkmelin+mozilla)
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•