544950 - Long attachment names don't wrap on message printout, causing small and unreadable message text font size (need fixed width for attachment file name tables)

Status: RESOLVED FIXED

(MailNews Core :: Printing, defect)

Description

[Thomas D. (:thomas8)]

There's no way to print out a normal continuous text message where both the msg text and long attachment file names are fully and fairly readable. Either text is unreadably small, or file name is truncated.

STR

1a) enable "Shrink to page width" (File > Page Setup > Format & Options)
1b) disable "Shrink to page width"
2) print msg with long attachment file names (> 3/4 of a normal size line)

Actual results (after step 2)

1a) with "shrink..." enabled:
- attachment file name printed in tabular structure at bottom of msg text,
- but long file name not wrapped within table cell (even has spaces)
-> table width is unnecessarily expanded (now very long), then shrinked to fit to page width
-> upon shrinking, printout font size, especially that of msg text, becomes very small and unreadable (without need)

1b) without "shrink..."
- msg text printout size is normal and readable
- but attachment file name doesn't wrap within table cell
-> table with attachment file name is truncated (without need)

Expected results (after step 2)

1a) with "shrink..."
- Continous msg text that doesn't itself require shrinking to fit to page width should always print in normal and readable size.
- Only msg text that requires shrinking to fit to page width should be shrinked (e.g. fixed html text width, text with tables, pictures etc.).
- In both cases, degree of text shrinking should never depend on length of attachment file name (what a weird connection!)
-> attachment file name tables should have a fixed with that doesn't require shrinking to fit on a default A4 or letter size page
-> long attachment file names should wrap within table cell (or just abandon the useless table altogether, as I'll propose in a new bug)

1b) without "shrink..." 
Everything should be readable in normal size. Same changes needed as for 1a):
-> attachment file name tables should have a fixed with that doesn't require shrinking to fit on a default A4 or letter size page
-> long attachment file names should wrap within table cell (or just abandon the useless table altogether, as I'll propose in another bug)

Another bug in the series of "WOW, basic mail handling stuff that TB doesn't handle well yet". Actually, the whole print layout is somewhat archaic, unpolished, not customizable enough, and useless (content-type? content-enoding? wth?). Bug 297702 being the saddest example - printed compositions aren't formatted at all. I'll roll out some more ideas for improvement in this area in separate bugs.

Comment 1

[Thomas D. (:thomas8)]

With Jim's wonderful fix for bug 544984 (http://hg.mozilla.org/comm-central/rev/9704a3548bdb), someone should test if this bug still occurs, using both scenarios of comment 0.

Comment 2

[Jim Porter (:squib)]

(In reply to comment #1)
> With Jim's wonderful fix for bug 544984
> (http://hg.mozilla.org/comm-central/rev/9704a3548bdb), someone should test if
> this bug still occurs, using both scenarios of comment 0.

The text is readable (assuming you have spaces in your filename so it can wrap), though it's still a little bit funky: the size ends up getting pushed to two lines. Let's leave this open for now.

Comment 3

[Jim Porter (:squib)]

Taking this, since I have a fix in the works.

Comment 4

[Jim Porter (:squib)]

Attachment: HTML file to test the updated style

Here's what it looks like as an HTML file. For attachments with short names, this shouldn't change anything. :clarkbw, opinions on this? I set the width of the size column to 8ch which is probably enough unless there are locales with very long names for "KB", etc. Maybe the size should be vertically aligned at the top too...

Comment 5

[Jim Porter (:squib)]

Attachment: Patch to make things look like the above

And here's a patch which updates all the styles to be like the previous attachment.

Comment 6

[Jim Porter (:squib)]

Attachment: Add CSS for one more theme

Oops, I forgot to save one of the CSS files for suite.

Comment 7

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 507622 [details]
HTML file to test the updated style

(In reply to comment #4)
> Created attachment 507622 [details]
> HTML file to test the updated style
> 
> Here's what it looks like as an HTML file. For attachments with short names,
> this shouldn't change anything. :clarkbw, opinions on this?

I put a 1/2 em padding on the top and bottom so the text doesn't run up against the border.

      .mimeAttachmentFile,
      .mimeAttachmentSize {
        padding: 0.5em 0;
      }

> I set the width of
> the size column to 8ch which is probably enough unless there are locales with
> very long names for "KB", etc.

That seems reasonable, there aren't really better ways I know of to make this happen.

> Maybe the size should be vertically aligned at
> the top too...

yeah, I'd add a vertical-align: top; to the .mimeAttachmentSize selector so they all line up in a similar space.

Comment 8

[Jim Porter (:squib)]

(In reply to comment #7)
> Comment on attachment 507622 [details]
> HTML file to test the updated style
> 
> (In reply to comment #4)
> > Created attachment 507622 [details]
> > HTML file to test the updated style
> > 
> > Here's what it looks like as an HTML file. For attachments with short names,
> > this shouldn't change anything. :clarkbw, opinions on this?
> 
> I put a 1/2 em padding on the top and bottom so the text doesn't run up against
> the border.
> 
>       .mimeAttachmentFile,
>       .mimeAttachmentSize {
>         padding: 0.5em 0;
>       }

This seems a bit sparse to me when the attachment names fit on a single line (which should be the case nearly all the time).

Comment 9

[Jim Porter (:squib)]

clarkbw, thoughts on comment 8?

Comment 10

[Jim Porter (:squib)]

Comment on attachment 507712 [details] [diff] [review]
Add CSS for one more theme

Flagging this for ui-review just to be safe re: comment 8.

Comment 11

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 507712 [details] [diff] [review]
Add CSS for one more theme

I've actually upped the padding to 1em since then just to get a little better separation.

I'm seeing the text and names run right along the border line, seen here:
http://cl.ly/2w2E2e3x082I02052q2I

With a 1em padding, instead of the 0.5em padding this works for me.  Were you feeling that 0.5em wasn't enough?

Comment 12

[Jim Porter (:squib)]

Attachment: An interactive test page to figure out the right padding

Keep in mind that attachment 507622 [details] just shows the pathologically bad case, and in practice, it should almost never appear. Attached is a simple page that shows both the normal case and the pathological case and lets you pick a padding to see how it applies to both of them. Just type in, say "1em 0" and click "Try it!" to see what it looks like.

Comment 13

[Jim Porter (:squib)]

Attachment: An interactive test page (with vertical-align:top)

Whoops, I forgot that we'd decided to use vertical-align: top; for the size column. For completeness, here's an updated test page.

Comment 14

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 521307 [details]
An interactive test page (with vertical-align:top)

Ok, I see what you're saying now.  Lets tone down the padding then to just being 0.25em on top and bottom only.  That gives a little room and doesn't go too far when the file names are within normal parameters.

Comment 15

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 507712 [details] [diff] [review]
Add CSS for one more theme

ui-r+ with 0.25em top/bottom padding.  Thanks.

      .mimeAttachmentFile,
      .mimeAttachmentSize {
        padding: 0.25em 0;
      }

Comment 16

[Jim Porter (:squib)]

Attachment: Use 0.25em vertical padding

Here we go. bwinton, do you mind looking at this? It should be straightforward, since it's just CSS repeated 5 times. :)

Comment 17

[Jim Porter (:squib)]

Comment on attachment 521736 [details] [diff] [review]
Use 0.25em vertical padding

Pulling forward ui-r+

Comment 18

[Thomas D. (:thomas8)]

Attachment: Testcase email msg with long attachment file name, non-wrapping attachment preview caption

Jim, thank you for working on this!

Here's a testcase email msg that shows the remaining problems.
More about them in my next comment.

Comment 19

[Thomas D. (:thomas8)]

Attachment: Screenshot #1 of non-wrapping attachment preview file name caption (Scale: 100%)

Mozilla/5.0 (Windows NT 6.1; rv:2.0pre) Gecko/20110402 Thunderbird/3.3a4pre
(still without the patch for this bug)

Looking at the attached screenshot #1, I still see the following problems, as for the scenarios 1a and 1b of comment 0:

1b) print preview with scale: 100% (*dis*able shrink to page width)

1b-1 (red circle): attachment preview file name captions don't wrap
long attachment file names in the caption of attachment previews (for images and text files) don't wrap, truncated at the end of the line (red circle).
This still causes the original small-print problem of comment 0, 1a.
I believe we should wrap the captions rather than truncate in the middle, assuming that long file names serve to describe the file, so the full description certainly makes sense in the caption (say for image files/photos or text files/code).

1b-2 (green circle): size column width (must be 10ch)
sizes are squeezed to 2 lines (as per Jim's comment 2): contrary to comment 4, we need at least 9ch of width to cater for English locale:
"999 bytes" has 9 characters. For that case, we still need some padding on the left, so I suppose 10 characters width for the size column would be best (adding another character to the width for padding is better than using padding-left, as we allow other languages another character).

1b3 (blue circles): too much vertical padding after attachment preview caption
... is something else I discovered (strictly not part of this bug, but might be fixed along with it). Note that the padding at the bottom is actually less than at the top, making it visually difficult to associate the caption with the preview.

1b4 (red circle): strike-through effect for some captions
Another weird thing: Only for the long file name caption and the attachments caption at the bottom, but NOT for the short file name caption, the separating line strikes through the captions (red circle again). Odd.

I entrust these to Jim's ingenuity. Pls let me know if we need a new bug for 1b3 or 1b4.

Comment 20

[Thomas D. (:thomas8)]

Attachment: Screenshot #2 of non-wrapping attachment preview file name caption (Scale: Shrink to fit)

Mozilla/5.0 (Windows NT 6.1; rv:2.0pre) Gecko/20110402 Thunderbird/3.3a4pre (without the patch for this bug)

For the case of comment 0, 1a (Scale: Shrink to fit), the attached screenshot:

1a1 (red circle): non-wrapping attachment preview file name caption causes unreadably small text (the main concern of this bug)

1a2 (green circle, yellow circle): strange strike-through variations with captions
Note how the undesired strike-through effect has gone for the long file name, but seems still present for the "attachments" caption...

Comment 21

[Jim Porter (:squib)]

From comment 19, 1b4 is just a bug in the preview (I think). As I recall, it looks fine when you actually print it. Either way, that's almost certainly a core bug, since that style looks perfectly fine in the message reader.

Comment 22

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 521736 [details] [diff] [review]
Use 0.25em vertical padding

>+++ b/mail/themes/pinstripe/mail/messageBody.css
>@@ -203,27 +203,37 @@ body[selected="false"] {
> table.mimeAttachmentTable tr + tr > td {

Why not change this to:
.mimeAttachmentTable tr + tr > td {
Like you did in gnomestripe?

>+++ b/mail/themes/qute/mail/messageBody.css
>@@ -172,27 +172,37 @@ body[selected="false"] {
> table.mimeAttachmentTable tr + tr > td {

Why not change this to:
.mimeAttachmentTable tr + tr > td {
Like you did in gnomestripe?

>+++ b/suite/themes/classic/messenger/messageBody.css
>@@ -176,37 +176,48 @@ body[selected="false"] {
> /* Attachment display styling (for inline attachments and printing) */
>-.mimeAttachmentHeader {
>+

I don't think you really wanted to remove that line…

> .mimeAttachmentHeaderName {
>-  color: gray;
>+  color: GrayText;
>   font-size: 80%;
>+  font-family: Arial, sans-serif;

And I do wonder a little about changing the styles in /suite/ without asking a SeaMonkey person first, so let's do that, just to be safe…

But r=me with the nits fixed.

Later,
Blake.

Comment 23

[[e-mail]]

Comment on attachment 521736 [details] [diff] [review]
Use 0.25em vertical padding

>-.mimeAttachmentHeader {
>+
???

>   border-style: none;
>-  border-top: 1px solid gray;
>+  border-top: 1px solid GrayText;
> }
> 
> .mimeAttachmentHeaderName {
>-  color: gray;
>+  color: GrayText;
>   font-size: 80%;
>+  font-family: Arial, sans-serif;
Please lose the colour/font changes in suite.
Note: I couldn't get word-wrap: break-word; to work here for some reason, but is it still worth adding white-space: normal; ?

Comment 24

[Jim Porter (:squib)]

Attachment: Fix nits [checked in]

Pulling forward r+ from comment 22. I also removed white-space: nowrap; per comment 23 since it didn't actually do anything.

Comment 25

[Jim Porter (:squib)]

(In reply to comment #19)
> 1b-1 (red circle): attachment preview file name captions don't wrap
> long attachment file names in the caption of attachment previews (for images
> and text files) don't wrap, truncated at the end of the line (red circle).
> This still causes the original small-print problem of comment 0, 1a.
> I believe we should wrap the captions rather than truncate in the middle,
> assuming that long file names serve to describe the file, so the full
> description certainly makes sense in the caption (say for image files/photos or
> text files/code).

I disagree. We already have the full attachment name in the attachment list at the end, so we could easily truncate it in the caption without losing any information. I'll probably do that as a separate patch, though.

Comment 26

[Thomas D. (:thomas8)]

(In reply to comment #25)
> (In reply to comment #19, 1b-1)
> I disagree. We already have the full attachment name in the attachment list at
> the end, so we could easily truncate it in the caption without losing any
> information.

Yes and no. Jim, you correctly referenced over-long filenames as the "pathological" use case.

1) Over-long filenames are the exceptional use case, i.e. they will not occur with the average user.

2) My assumption is that users who deliberately have such exceptional / pathological uses will actually need/want the information contained in the long filename, even in the preview captions. E.g. in Use cases like this:
- user sends a set of photos (image files)
- photos have long file names that describe the content, e.g. "Photo of Mr. Joe giving his presentation at the company's headquarters on 24 Mar 2011.jpg"

3) Truncating long file names in the preview captions makes that information unavailable as an *in-place* description of the preview, even though (as per 2) that information can be assumed relevant for understanding the preview (images, code, etc.). Suppose there are 10 photos attached, it will be much harder, if not impossible to associate information from the list at the bottom with the respective previews of each photo.

4) Truncating long file names in the preview captions can even *lose* information, if the user omits printing the attachment file list (after implementing bug 549139). In use cases like 2, it might make much more sense to print full-length file names in the caption of the photos (as a description of each preview), and skip printing the duplicate list of attachment file names at the end altogether.

> I'll probably do that as a separate patch, though.
It might be helpful to have truncated preview captions as a fast interim fix, as this bug cannot be fully fixed without addressing the captions issue explained in comment 19, 1b-1. Pls truncate the middle of the filename, like this: "Photo of Mr. Joe giving...24 Mar 2011.jpg".

Comment 27

[Jim Porter (:squib)]

Checked in: http://hg.mozilla.org/comm-central/rev/6d81cb8fe7a9

Leaving this open for now to fix the legends on the inline attachments.

Comment 28

[Jim Porter (:squib)]

Unassigning myself from this, since I'm not likely to work on it in the immediate future, and I wouldn't want to deter any other enterprising individuals from tackling the remaining bits here.

Comment 29

[Wayne Mery (:wsmwk)]

(In reply to Jim Porter (:squib) from comment #27)
> Checked in: http://hg.mozilla.org/comm-central/rev/6d81cb8fe7a9
> 
> Leaving this open for now to fix the legends on the inline attachments.

close and file bug for remaining bits?

Comment 30

[Thomas D. (:thomas8)]

Something has fixed this! Now works as expected, long attachments are wrapped whereever they occur.
Wayne, Richard, Jörg, would you know the bug where this was fixed?

Comment 31

[Jorg K (CEST = GMT+2)]

Already fixed in TB 24, so unless someone bisects this, we'll never know.