| Summary: | Treat <br> variants as newlines on HTML only messages | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Claws Mail (GTK 2) | Reporter: | Pierre Fortin <pf> | ||||
| Component: | UI/Message View | Assignee: | users | ||||
| Status: | RESOLVED WORKSFORME | ||||||
| Severity: | enhancement | CC: | mones | ||||
| Priority: | P3 | ||||||
| Version: | 3.7.10 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Attachments: |
|
||||||
Hi Pierre, is bug this still happening? I think this may have also fixed by patch for #3236 in 2014¹, but just wondering :-) regards, ¹ http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=6e2217d5bb5722a5426158f49bcaed95005a28f6 Haven't noticed this in a while; closing. |
Created attachment 1038 [details] redacted example message I get messages in HTML only, and the plain text that CM renders ignores all of {<br>,<br/>,<br />,0x0a,space[1]} which causes all the text to be rendered as one LONG line making the message difficult to read without resorting to invoking dillo... Could CM at least convert the <br> variants to 0x0a [and not delete any 0x0a?] in the original message? These messages contain sequences like this: [24 spaces]text<br/><br/>0x0a [24 spaces]text<br/>0x0a <br />0x0a <br>0x0a Sample attached... [1] the original message contains 24 spaces in front of each text line; but the dillo rendering ignores these as expected -- so ignoring these while rendering a text/html block as plain text is reasonable.