I have a display with relatively high dpi, so my standard system font size is 6. If I use that size for the text in the composer I get complaints from the mail recipients that they cannot read my emails because of that small font size. If I change the font size in the composer, then my recipients are satisfied, but I end up having to live with extremely huge fonts in the composer. So I think formating html mails with relative font sizes would make everyone happy. thx for your effort Michi
Yes html generated by QTextEdit is not very good. I will try to replace it by a new library in 4.11 or 4.12 (still in progress). Will look at if it's possible to create a workaround before to use this library
still nothing? I bough a notebook with QHD screen, kmail is unusable for reading emails without magnifying glass
It's when we generate mail ? or receive an email ?
Git commit 4410d6a8b6beff089197561f3faa1a259a3cb781 by Montel Laurent. Committed on 16/01/2015 at 08:14. Pushed by mlaurent into branch 'KDE/4.14'. Fix Bug 316707 - Use em font size rather than absolute px values in HTML messages FIXED-IN: 14.12.2 M +29 -2 messagecomposer/composer/kmeditor.cpp M +3 -1 messagecomposer/composer/kmeditor.h http://commits.kde.org/kdepim/4410d6a8b6beff089197561f3faa1a259a3cb781
QTextEdit created generated html as "pt" now I convert all as "em" I hope that you will able to test it soon to confirm it. I can fix create new email, but not old email sorry for it.
Thanks Laurent, unfortunately I will be able to test this in next weeks kubuntu weekly snaphot. Best regards, Martin
When you can test new version please reports bug :)
Hallo Laurent, first of all, many thanks for your fix. I can acknowledge that the receiver gets relative font sizes now. Flying over the code, your scaling the whole thing relative to 12pt, right? I think this doesn't really do the trick. On HiDPI displays you normally use very small font sizes for your normal desktop context, in my case it used to be 6. But not just on HiDPI screens font size 12 can't be considered the "normal" font size. People might conceive different font sizes as their sweet spot. When you write an email you generally would consider your "normal" screen font as the reference. And really, I think that reference should translate into the receiver's reference, and should denote 1em. Therefore, I think, the scaling factor should really be taken from the systemsettings. Directly related to this are the font size selection widget(s) (e.g. spin box in the composer). Working with absolute font sizes carries the wrong information, I would say. Personally, I think it should also be a percentage rather than a fixed font size, because the result isn't. I also found something that might be another bug though. When you reply to or forward a message, the composer looses the formatting (or at least the font sizes). Should I open a new bug for this, or is this included in this one? thanks Michi
I convert all font-size: 'X'pt to font-size:'X'em => it will use em now when it sends. is it not correct ? I am ok that font combobox is not correct for it. I need to investigate how to replace it. Indeed font "pt" size is not correct. "I also found something that might be another bug though. When you reply to or forward a message, the composer looses the formatting (or at least the font sizes). Should I open a new bug for this, or is this included in this one? " yes please
PS: it's very hard for me to see all bug about dpi as I don't have a big screen but I can fake with systemsettings change dpi, but perhaps it's not enough.
Hi Laurent, I'm not saying it has necessarily to do with HiDPI screens. Let's say someone considers font size 18 as his favoured font size. Dialogues, Menues, web pages, are all 18 - maybe because that someone is blind ;-) That user ill have set this value in the systemsettings. When this someone writes an email, he uses that font size 18, because that's what he thinks is normal. Now he wants to emphasise some text (relative to his perceived "normal" text size), maybe double the size in comparison to his normal text size. In that case 18 should become 1em, the empasised text 2em. On the receiver side things might be different where the default font size is 12pt. So instead of 18pt the normal text will scale to 12pt on the receiver end. I think it really is just a question of: what did the user set in his systemsettings as "General" font size. Does this make sense?
It's hard to know what user wants... Why 18pt must be changed to 1em ? Perhaps he wants that receiver see it as a "18pt" => 1.2em and not 1em no ?
(In reply to Laurent Montel from comment #12) > It's hard to know what user wants... You're absolutely right. Therefore the "General" font size in the systemsettings seems like a very good indication what "default" (aka 1em) really means in the user's eye. > Why 18pt must be changed to 1em ? > Perhaps he wants that receiver see it as a "18pt" => 1.2em and not 1em no ? Yeah, and the solution right now does not produce that to begin with. If your want that you have to revert the commit. But it was the whole point of this bug report that you should not work with absolute values. Noone can assume that a certain pt size is being displayed properly on the receiver end. It's the same story with web pages. Web pages with fixed font sizes are, well, a bit short sighted. Let's assume someone with a default screen font size of 12 writes an email in font size 12. With your fix it is calculated to 1em. Any email client on the receiver side scales that relative to some reference, probably to the "default" font size, whatever that is (it can be anything and not just 12pt!). For that reason I was also suggesting not to use absolute font sizes in the composer UI. Again, working with em font sizes never produces a hard coded result on the receiver side. 18pt will never be automatically 18pt at the receiver end - only if the receiver uses the same reference as the sender. And you cannot assume that.