Created attachment 1900 [details] HTML mail from Outlook MS Outlooks likes to send HTML-only e-mails. Its HTML is a little strange and each line is in a <p> section. This isn't handled well by Claws. When Claws displays HTML as text, but more importantly when it quotes an HTML e-mail in a reply, its conversion will add extra newlines, making the text harder to read: there will be an empty line between each line of the original e-mail. I'm attaching an example HTML file generated by Outlook. This HTML file is rendered "incorrectly" (as described above) by Claws, Links, Lynx and W3M, but rendered correctly by Firefox. Attaching example outputs of Claws and Firefox to show the difference. This is particularly painful when Claws quotes an e-mail by prepending >. The "fix" that I'm carrying locally is attached in a patch. It works for me but may not be the most correct solution.
Created attachment 1901 [details] "correct" output by firefox
Created attachment 1902 [details] "incorrect" output by Claws and many others
Created attachment 1903 [details] My workaround patch
I have been using my patch for a few months now and observed no problem. Would you please merge it?
I'm still unsatisfied how CM shows text out of HTML, adding extraneous newlines between paragraphs. Your patch is fixing some (newlines were added at every single line) but not all, and until I (or somebody else) can afford spending more time on this topic, I'd prefer holding the patch on for a while.
Do you have examples of incorrect output that my patch isn't fixing? I can take a look, but I haven't noticed any problem that my patch isn't fixing. Either way, my current patch is a net improvement, and you can always revert it later if a more complete fix comes in. As it is upstream, replies to Outlook-sent e-mails look super crappy. This ought to be fixed for more than just me.
The patch has been held for quite "a while" now. Would you please merge it?
It hasn't been merged because it seems like a workaround rather than a fix, working around microsoft's non-standard html tags, whose only purpose is to faciliate ms office.
I don't think there is a fix in the client that isn't a workaround; but there's a usability problem in Claws if it can't display this properly. It wouldn't be the only one of course. Yes, the HTML passed in input is crap. It shouldn't be like that. Sadly, you don't usually have a choice in what e-mail client people use to write you, and it's not practical in most settings to tell them not to use Outlook. There's a chance to improve Claws here, without hurting anything that I could see in more than a year of testing, and after asking for examples. I think it should be considered. Rest assured the distaste of Outlook is well-shared...
> There's a chance to improve Claws here, without hurting anything that I could see in more than a year of testing Your patch does break it. For example, in a simple html file, with the following in its body: <p>my first paragraph</p> <p>my second paragraph</p> <p>my third paragraph</p> There should be a blank line between each paragraph. Currently there is. With your patch there is not.
After discussion on IRC, I'd like to reopen this. I am working on a patch that will 1. detect MS-originated HTML 2. apply the workaround of avoiding extra line breaks on <p class=MsoPlainText>…</p> This seems to be the scheme Outlook is following: Converting plaintext mail lines to those paragraphs of the given class, then display them in HTML. The class is configured with margin:0 in CSS so that the pseudo-paragraphs look like lines again. On converting to plaintext again, Outlook itself forgets about the fake nature of these paragraphs and creates extra empty lines between the initial plaintext lines in quotes inside the reply it generates. Especially with the top-posting style prevalent in corporate environments, and which is _sometimes_ actually useful to get someone new into the conversation with some history by CC-ing all the cruft, this leads to discussion threads where the plaintext mails from Claws stick out by being strangely formatted with extra line breaks. The reaction is: „What's wrong with that person? Cannot they use a proper mail client and send nicely formatted HTML like the rest of us?” So my plan is two-fold. I am actually hoping that MS will fix their behaviour, at least in creating the plaintext version from their HTML. But that may still leave the HTML part being badly displayed by Claws, because it does not know the CSS that turns paragraphs into lines again (not using an actual web engine, just the reduction to text that Claws does without plugin). So I want what the initial reporter of this bug inteded, but with a bit more finesse to only apply it to the kind of fake paragraphs MS creates.
Created attachment 2177 [details] new patch looking for MS-specific syntax OK, done and tested on a Ubuntu 20.04 x86-64 system. This avoids the extra line break only when this is a MS HTML part and for paragraphs with the proper class.