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)

RESOLVED FIXED in Thunderbird 24.0

Status

defect
RESOLVED FIXED
9 years ago
2 years ago

People

(Reporter: bugzilla2007, Unassigned)

Tracking

Trunk
Thunderbird 24.0

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gs], URL)

Attachments

(6 attachments, 4 obsolete attachments)

(Reporter)

Description

9 years ago
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.
Component: General → Printing
Product: Thunderbird → MailNews Core
QA Contact: general → printing
(Reporter)

Comment 1

9 years ago
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.
Depends on: 544984
(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.
Taking this, since I have a fix in the works.
Assignee: nobody → squibblyflabbetydoo
Status: NEW → ASSIGNED
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...
Attachment #507622 - Flags: ui-review?(clarkbw)
And here's a patch which updates all the styles to be like the previous attachment.
Posted patch Add CSS for one more theme (obsolete) — Splinter Review
Oops, I forgot to save one of the CSS files for suite.
Attachment #507623 - Attachment is obsolete: true
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.
Attachment #507622 - Flags: ui-review?(clarkbw) → ui-review+
(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).
clarkbw, thoughts on comment 8?
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.
Attachment #507712 - Flags: ui-review?(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?
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.
Attachment #521306 - Flags: feedback?(clarkbw)
Whoops, I forgot that we'd decided to use vertical-align: top; for the size column. For completeness, here's an updated test page.
Attachment #521306 - Attachment is obsolete: true
Attachment #521307 - Flags: feedback?(clarkbw)
Attachment #521306 - Flags: feedback?(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.
Attachment #521307 - Flags: feedback?(clarkbw) → feedback+
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;
      }
Attachment #507712 - Flags: ui-review?(clarkbw) → ui-review+
Posted patch Use 0.25em vertical padding (obsolete) — Splinter Review
Here we go. bwinton, do you mind looking at this? It should be straightforward, since it's just CSS repeated 5 times. :)
Attachment #507712 - Attachment is obsolete: true
Attachment #521736 - Flags: review?(bwinton)
Comment on attachment 521736 [details] [diff] [review]
Use 0.25em vertical padding

Pulling forward ui-r+
Attachment #521736 - Flags: ui-review+
(Reporter)

Comment 18

8 years ago
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.
(Reporter)

Comment 19

8 years ago
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.
(Reporter)

Comment 20

8 years ago
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...
(Reporter)

Updated

8 years ago
Attachment #523989 - Attachment description: Screenshot #1 of non-wrapping attachment preview caption (Scale: 100%) → Screenshot #1 of non-wrapping attachment preview file name caption (Scale: 100%)
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 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.
Attachment #521736 - Flags: review?(neil)
Attachment #521736 - Flags: review?(bwinton)
Attachment #521736 - Flags: review+
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; ?
Pulling forward r+ from comment 22. I also removed white-space: nowrap; per comment 23 since it didn't actually do anything.
Attachment #521736 - Attachment is obsolete: true
Attachment #525953 - Flags: review+
Attachment #521736 - Flags: review?(neil)
(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.
(Reporter)

Comment 26

8 years ago
(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".
Checked in: http://hg.mozilla.org/comm-central/rev/6d81cb8fe7a9

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

Updated

8 years ago
Attachment #525953 - Attachment description: Fix nits → Fix nits [checked in]
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.
Assignee: squibblyflabbetydoo → nobody
(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?
Status: ASSIGNED → NEW

Updated

7 years ago
Whiteboard: [gs]

Updated

6 years ago
Attachment #523985 - Attachment mime type: message/rfc822 → text/plain
(Reporter)

Updated

2 years ago
See Also: → 1365642
(Reporter)

Comment 30

2 years ago
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?
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED

Comment 31

2 years ago
Already fixed in TB 24, so unless someone bisects this, we'll never know.
Target Milestone: --- → Thunderbird 24.0
You need to log in before you can comment on or make changes to this bug.