111.63 KB, image/jpeg
4.64 KB, text/html
808 bytes, patch
|Details | Diff | Splinter Review|
748 bytes, patch
|Details | Diff | Splinter Review|
889 bytes, patch
|Details | Diff | Splinter Review|
Since I upgraded from the NS6 release bits, i've noticed that the text in messages is so small, it's almost unreadable. I'll attach a screenshot. This makes it really hard to use.
note that my fonts are set at 12pt (default is higher), but webpages are all still readable. It's only email.
I'm not seeing this with my mac build 030608. If I set font to 12 webpages become pretty difficult to read but mail looks fine. Mike, are you still seeing this?
plaintext messages are ok, it's people that send html mail.
and yes, this does happen with my 3/9/01 build
now that mail is usable, I'd love to see this fixed since it makes my eyes bleed to read the tiny text. Hey Seth, if you fix it in moz0.9 i'll buy you a 6pack of whatever you want.
Keywords: mozilla0.9, nsbeta1, nsCatFood, nsdogfood
Keywords: nsCatFood → nsCatFood+
Target Milestone: --- → mozilla0.9.1
marking nsbeta1+ and moving to mozilla0.9.1
*** Bug 70598 has been marked as a duplicate of this bug. ***
Moving to 0.9.2. My understanding is that the default font prefs work ok.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
moving to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Seth and I looked at this for some time today. Here's the deal: On message display, the MIME code wraps the message in a <div class="moz-text-html" style="font-family: Times; font-size: 100%"> (message body here) </div> where the font-family, and the font-size are deduced from your preferences. This was work done for bug 38890 and bug 40547; see http://lxr.mozilla.org/mozilla/source/mailnews/mime/src/mimethtm.cpp#67 The problem here is that Pinkerton and I have set our font prefs to use 12px as the fize for our variable-width font. The code in GetMailNewsFont() compares the font sizes in the user prefs and default prefs (12px and 16px respectively) to determine the font-size percentage, which thus comes out as 75%. So the message is displayed at 75% font size. It's not clear why this <div> needs font-size style on it at all. Removing the font-size attribute seems to work, but may break i18n stuff that nhotta was trying to fix in the first place. nhotta: please take a look at this bug.
Assignee: sspitzer → nhotta
Component: Mail Window Front End → MIME
QA Contact: pmock
This was done to allow the user to change the mail font size by the font preference, so it's not i18n. Removing the size attribute would disable the ability to change message view font size. I think some people may need larger font size. Reassign to putterman for evaluation, can we disable the size attribute for mail?
Assignee: nhotta → putterman
This should probably go to ducarroz, owner of the MIME module.
> This was done to allow the user to change the mail font size by the font But don't the contents of the <div> render using the users preferred font settings already?
Yes, but it uses the font size of unicode because libmime sends UTF-8 data to layout. So, I have to correct my last comment. After removing the font size attibute, there is a way to change message font size by changing unicode font size.
If samll size is the problem then I can prevent generating less than 100% sizes.
reassigning to ducarroz until we decide if mailnews isn't the right owner.
Assignee: putterman → ducarroz
So what you're saying is that the font scaling gets applied twice?
I don't think it's applied twice. If font size is not specified, it is taken from the pref based on the charset of the document.
These <div>s that we insert into displayed messages are also problematic in general. The get included in copy/pasted text, which means that doing a Select All/Copy/Paste of the contents of a message gives you some content that was not in the original message. And doing this repeatedly, as I have seen people do in standard format emails, causes this <div> to appear multiple times. Can we move this font-related CSS into the XUL?
I am not sure about moving the CSS into XUL, if that possible or not. But can the size issue be resolved by moving to XUL?
Yes, we are currently inserting our own (mailnews) css file in each message display.
Created attachment 42413 [details] [diff] [review] Patch, changed not to generate less than 100% font size.
With the patch, libmime always generates font size 100% or larger. But HTML messages are still displayed smaller when the font is set to smaller size by pref UI. It seems like somewhere else setting the font size. It could be related to bug 90474, cc to email@example.com.
Summary: Text of displayed messages very small → Text of displayed HTML messages very small
The problem is that unicode font size is affected by font size setting of Western. This can be reproduced by browser by using charset menu to change the charset to UTF-8 for HTML pages. Because of this problem, the message display (charset is UTF-8) is scaled by Western font size. But the scaling is already done by libmime, therefore we get the double-scaled problem. So the problem is probably related to font/layout, reassign to nhotta for now.
Assignee: ducarroz → nhotta
There is a code in layout (which calls i18n) to use font of the default locale in case the document is unicode (e.g. UTF-8). That was done in order to make XUL (charset is UTF-8) to use the default locale instead of using the unicode font. This creates the side effect. In browser, locale font size (Western in case of US system) is used for Unicode pages. In mail, it causes the double scaling problem because libmime specifies font size and the font is scaled again because the mail output is UTF-8.
Status: NEW → ASSIGNED
I filed a separate bug about the unicode font as bug 91190. The current behavior was done by intention and currently I do not have a solution. For mail/news, I put a patch of disabling the scaling in libmime. This disables the support of per language based scaling. And mail font size is controlled by the default locale font setting (e.g. Western for US system). I think this is fine for most people.
if we are going to do that, why not remove the "font-size: %d%" part completely? and something that sfraser and I noticed, why isn't it: "font-size: %d%%" both ways seem to work, but isn't "%%" correct?
looking at the other callers of GetMailNewsFont(), the one in mimethtm.cpp was the only one using fontSizePercentage (last arg to GetMailNewsFolder()) if that isn't going to be used anymore, we should clean up GetMailNewsFolder() and the callers, right? see http://lxr.mozilla.org/mozilla/search?string=fontSizePercentage
I think we want to keep the argument in case for the unicode font problem is fixed (bug 91190).
ok, good to know. if we plan on using it for something later we should obviously keep it in. sr=sspitzer on the last patch. thanks for fixing this nhotta. pinkerton, sfraser and other mac users are going to be very pleased.
This is a severe problem also under Linux. Is it now fixed for Mac only??
Checked in to trunk. The change is not for Macintosh specific.
OS: Mac System 9.x → All
Hardware: Macintosh → All
Fixed in trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
A sight for sore eyes!
You need to log in before you can comment on or make changes to this bug.