User Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20100101 Firefox/16.0 Build ID: 20121024073032 Steps to reproduce: Trying to print an email with Thunderbird from my imap account. Trying to print different emails from different sender. Actual results: Not readable. If you choose to print with 100% zoom the lines will be cut out and there is no line break. Expected results: the emails should not be cut out with 100% zoom. There should be a line break. If you try to select "fit to page". the email is not readable (fonts to small).
Tried with Linux and Windows. Same Issue.
Eric, please "Add an attachment" to this bug with source of affected msg (testcase.eml), after removing private data as required (text editor). Similar: Bug 544950
Summary: Printing of emails not readable in Thunderbird → Printing of emails not readable in TB: Scaling "Shrink to fit": font size too small, "100%": long lines truncated
Created attachment 680358 [details] Test.eml as requested. Here we go. This is a sample. The same issue with this sample on Linux and Windows.
Hallo Eric - vielen Dank für die schnelle Antwort! :) Hmmm, testcase of attachment 680358 [details] reproduces the line-chopping behaviour as described in comment 1, but imo it is not a bug... The problem occurs only when printing the text/html-part of the msg, because those extra-long lines are wrapped in a <pre> tag: > <pre>Sehr geehrter Herr Lehnen, > Here comes a very long line which exceeds the normal length of a line and it > still goes on and on and on > Ihre Agentur > </pre> So I think the rendering of those long lines without wrap is actually technically correct rendering of <pre> tag. For a <pre> tag to wrap, you'll have to use: > <pre style="white-space: pre-wrap">loooong lines</pre> Hence imo this bug is invalid. Perhaps it could be morphed into a RFE to always print <pre> with white-space: pre-wrap but I'm not sure if we'd be violating standards. Or it could still be a bug if TB wrongly added the <pre> attribute somewhere along composition. Eric, can you attach the original msg from Agentur to you so we can have a look at that source? (Remember to remove private data as required before attaching). I also wonder if there should be a reasonable minimal font size limit for "Shrink to fit" because I can't imagine any usecase for microscopic printouts (needs a new bug to sanity-check font-size with "Shrink to fit", but it might not be easy to get that right). Btw switching to View > Message body as > Plaintext will wrap the long lines so that they are printable.
Component: Untriaged → Printing
OS: Windows 7 → All
Product: Thunderbird → MailNews Core
Hardware: x86 → All
Summary: Printing of emails not readable in TB: Scaling "Shrink to fit": font size too small, "100%": long lines truncated → Overlong lines in <pre> tag are truncated when printing text/HTML part with scale: 100%, or unreadably small with "shrink to fit"
Version: 16 → Trunk
(In reply to Thomas D. from comment #4) > Perhaps it could be morphed into a RFE to always print <pre> with > white-space: pre-wrap but I'm not sure if we'd be violating standards. I think that wrapping the lines without the sender's stated intention (i.e., by adding the attribute that wrapping is allowed) wouldn't reflect what's supposed to happen (e.g., if you send a patch or some ASCII art you don't want this to be wrapped no matter what). Thus, this shouldn't be done in a default way. > Or it could still be a bug if TB wrongly added the <pre> attribute somewhere > along composition. A frequent cause are replies to messages where quoted-printable formatting was misused to be in compliance with a 76-char line length in the encoded message. Thunderbird (correctly) resolves those to a single line per paragraph (details are explained in bug 387687, duplicate of bug 173918). Note that in this context there was also a discussion about some heuristic to distinguish line length created as an artifact of such bad encoding vs. lines formatted that way on purpose. > I also wonder if there should be a reasonable minimal font size limit for > "Shrink to fit" because I can't imagine any usecase for microscopic > printouts (needs a new bug to sanity-check font-size with "Shrink to fit", > but it might not be easy to get that right). For printing that might be a reasonable approach, where the question still remains if the long line should be cropped or wrapped in such cases (the former obviously implied dataloss, the latter loss of formatting).
See Also: → bug 387687
Marking this as invalid as observing formatting is more important than printing convenience. IMO
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.