Closed Bug 181527 Opened 22 years ago Closed 16 years ago

Printing always prints full header (after View|Headers|All)

Categories

(MailNews Core :: Printing, defect)

Product:
MailNews Core
Component:
Printing
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: jamesrome, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(3 files)

Programmers File Editor Print-UI
78.56 KB, image/gif
Details
Programers File Editor Print UI Gifs
159.71 KB, application/x-zip-compressed
Details
picture of the mail and the printed (to pdf) output
349.29 KB, image/png
Details 
Bug 12505 "fixed" this, but broke it in my opinion. Now when I print mail, I
always get the full header, in BIG type which lists the full message path
through the internet. It takes up at least 1/2 page. Save a tree!

I only want From:, To:, Subject.

Printing headers (or not) should be a user-selectable item.
James, you can turn off printing headers and footers with Page Setup in the
File|Menu list of the 3-pane window for linux and winxp.  You can also turn it
off with Print Preview for winxp with the latest trunk builds 11-21.  marking
invalid becasue user does have an option with current builds.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Note MacOSX platform has a bug where this is coming up blank so at this time MAC
OSX users won't be able to edit the headers.  181522
Verfified
Status: RESOLVED → VERIFIED
I looked there. It lets you turn off the page title and date. I meant the header
in the mail message, not the page header. for win2k, there is no way to turn it
off that I can see.
James, 
You must be viewing the messages with all of the header showing (menu option
View|Headers|All).  When printing we print based on what you selected as your
option for viewing the headers.  If you want just the From: To: Date: and
Subject,  you can change the view of the  headers to  "Normal" then print.  
There may be a feature request here to put a context menu in the header section
to change the view of the header, for that message only,  so you don't have to
go through 3 mouse clicks to print with only the normal header.  I'll cc jglick
for comment.
Reopening
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
You are correct! However, th normal view with either setting is the same if the
header pane is not expanded.

I think Mozilla should print the header if the header pane is expanded (either
short or full as the user selected), but should not print it if the header is
not expanded.
-> reassigning to mail engineer. Sounds like the header in question is formatted
by the mail app.
Status: REOPENED → NEW
Then maybe the feature request should be to honor the collapsed header when
prinitng.  Again to jglick for review.
Even though the user has the header collapsed, they still have it set as Normal 
or All. I'm not sure we shouldn't print the header as the user has it set just 
because its collapsed. I'd like to hear others thoughts on this one.
There are very few times that I would want the full header printed. Generally,
on a printed page, I would want
From:
To:
Date:
Subject:

and that is all. There should be an option to just have that.

And the header text that does print out is in a bigger font than the main message...
--rods
Assignee: dcone → rods
I print what is sent to me from mail, this sounds like a mail enhancement. Seth,
could you get it to the right person?
Assignee: rods → sspitzer
*** Bug 189887 has been marked as a duplicate of this bug. ***
Blocks: 172927
Blocks: 184832
Blocks: 189597
Depends on: 66713
*** Bug 172927 has been marked as a duplicate of this bug. ***
*** Bug 189597 has been marked as a duplicate of this bug. ***
The crux of the problem here is that printing headers has two states (full
headers, normal headers) whereas the GUI has FOUR states (full headers, normal
headers, headers compressed to all on one line while View>Headers>Normal set,
headers compressed while View>Headers>All set).  When users print a message that
is displayed in one of the latter states, they are surprised by the output and
don't know where to go to change it.  They don't think of changing View>Headers
because they don't see its results in the GUI.
If I set View->Headers->Normal, and even if the headers are not expanded, I
still get the From/To/Subject printed in much larger type than the text. They
should be unobtrusive. I see no way to set the headers compressed into the nice
one-line mode they are displayed in.
Moz is great!, thanks for all the hard work... trying to replace NS4.79 @work on
Win32, printing to HP4500/8000 laser printers. Ref.
http://bugzilla.mozilla.org/show_bug.cgi?id=181527#c9  -I am having this problem
too, the page setup dialog box is very weak. We need the ability to turn off
certain fields in the message header in print mode and possibly adjust Print
Fonts in "Page Setup" (I would like to have tiny headers). Frequently, my "To:"
field is almost page long, cause some pointy haired managers have lengthy lists
;). IIRC, NS would truncate it if it were more than a couple of lines? NS, also
prints a much smaller font for its headers that don't fill up the page.
Nothing has been done to fix this.
Some other Print Ui Ideas...
Any ideas if there will be an update to the Prining UI to support Font Changes
or Formatting issues, specifically for mail? Are the very Large Printed Fonts a
symptom of a missing True Type or Font Substitution situation? I have discovered
some HP PCL Print Driver related problems, do different drivers handle print
output at the same point size?

Found some links...

Thoughts About a Print UI for Mozilla
http://www.hut.fi/u/hsivonen/print-ui.html

For a number of years I've been using a the Programmer's File Editor on Win32
clients that has the best Print UI I've found anywhere. It is very simple, small
& intuitive... Amazingly, it is full of useful features like printing the file
PATH in the header, wrapping long lines, and selecting from a lists of fonts
used for printing. Moz Team please take a look at this little editor's Print UI
& help us out. Perhaps the Author (nolonger maintaining it) would donate the
code? Thanks! 

Programmer's File Editor Home Page
http://www.lancs.ac.uk/people/cpaap/pfe/
 This just caught me out too. I had turned view full headers on a while ago and
forgotten about it because the header view was collapsed, so couldn't work out
why it would be printing full headers. The obvious place for the user to look to
try to get rid of the headers on the printout is in the Page Setup dialog.
I agree with comment #9

I think this is an area of printing in Mailnews that could be considered not 
only as request for enhancement but also a bug, as the current behaviour when 
PRINTING cannot be seen as anything but appropriate and inconvinient for most 
purposes. Unless you see use Mailnews because you need to print all headers!

I looked at http://bugzilla.mozilla.org/show_bug.cgi?id=12505 but the patches 
there seem not to have anything to do with printing headers. Any thoughts?
OS: Windows 2000 → All
*** Bug 184832 has been marked as a duplicate of this bug. ***
We just upgraded to Mozilla 1.7.2
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040814
running on Linux RedHat 8

The 3-pane arrangment shows FOUR header lines: Subject, From, Date, and To. It
is expanded (i.e. they are in a vertical list and there is a "-" control).

When we Print OR do "Print Preview", the TO IS MISSING.  The TO is always
missing except on the screen.

This was not happening on Mozilla 1.6 (i.e. the TO did print).

(Also, in case it is related, I am filing a separate bug 258138 report that the
View Headers All/Normal does not function.  It shows normal selected (and that
is the result), but all attempts to change to All are fruitless; the selection
does not change and the appearance on screen does not change.)

Jay
*** Bug 262786 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Bug 61523 is similar request on mail header display.
Since "Print" already uses menu option of "View|Headers|All/Normal", header
choice in viewing is possibly a partial solution for this bug, if user's
requirement on mail header is same on displaying and printing.
Blocks: 288471
*** Bug 299267 has been marked as a duplicate of this bug. ***
This is still broken after 3 years!!
*** Bug 236337 has been marked as a duplicate of this bug. ***
Problem still present in 1.5.0.10 (20070221).

Addional info: The entire header is only printed if user UN-selects "Compose messages in HTML format". I prefer text only, as a consequence my printed messages have a one page long, unwanted header prefix...

It would be great to roll this fix in with 
Bug 61523 – Display user-specified headers
No longer blocks: 189597
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
QA Contact: esther → printing
It is 5 years now, and still no fixes. Don't you think that is too long??
Flags: blocking-thunderbird3?
Unfortunately for the community, "you" is also equal to "us", and I have just many bugs filed back in 2002 which have not been tackled either :(

Unless Mozilla get some funding to pay people to follow up bugs I don't see the situation changing unfortunately.  I do wish Mozilla had pointed out this situation back in 2002 so I could have saved time filling bug reports.

KDE, GCC and other projects manage to keep on top of bug-tracking... so perhaps there is something they're doing well which could be learnt.
Cheers, Jon
Blocks: 387666
Product: Core → MailNews Core
Triaging according to new policy for flags.  
https://wiki.mozilla.org/Thunderbird:Release_Driving
Flags: wanted-thunderbird3?
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
I reported this in 2002, and it is still a problem, even in Thunderbird 3.0b1! I think this needs to be upped in importance. Printing the header often wastes a whole page of output.

Everyone please vote for this bug.
Severity: enhancement → normal
I have been following this for about five years and I have _never_ seen the problem and have not been able to duplicate the problem, as I understand it. My problem was somewhat the opposite (on one Mozilla version, the TO would never print).  

I have upgraded from Mozilla Mail to Thunderbird 2.0.0.19 on Unbuntu Linux. 

I am not seeing any problem with printing headers.  I did a CLEAN install -- specifically to make sure I did not bring over any crud or garbaged CSS files from Mozilla Mail.  My point is that my default clean installation had the proper headers printing (to, from, date, subject); and only those.

IF the problem at this point is that folks are upgrading from old stuff to current Thunderbird and bringing along crud with them, then, while it is not desirable, it sounds like the answer is to do a clean install.

It would be a useful diagnostic if one of the folks that is having the problem, if they had not done a clean install, would do a clean install and then report if they are still having the problem.

I am not saying that everything is wonderful with Thunderbird 2.0.0.19 -- I have a list of 10 (ten) fairly significant bugs that I have encountered in about four months of use of this version.
I'm just a TB3 nightly tester, never hacked anything before. But allows me to make a couple of SWAGs: First-- anything to be done with these issues (header states being tracked within "print", print GUI design mods) involves major changes, and will NEVER be done to TB2.

Second-- The header changes which have already been applied to the TB 3.1 trunk are widely abhorred, resulting in such bugs as the wide-ranging "hacks" within bug 466025 (hacks containing code which corresponds to many individual bugs, not yet selected for specific isolation). So I recommend that we "rest" this one until the fallout from that one, which is affecting all platforms, has been settled. (Because the The names and properties of header UI states might be changing a lot.)

Third-- I think our comments have fallen into two different areas, which should have different bugs: The "Summary" of this one matches the comments about print dialogs and functions failing to follow ALL of the possible states of the header display, but the basic structure of the entire Linux print dialog ("please make it more like PFE") seems like a separate issue to me. The comments and suggestions are of very high QUALITY, but they're probably getting into a completely different area of code, and will ultimately result in a different "bug". That's just a guess.

(BTW, TB "3.1", which uses the same Gecko 1.9.1 as upcoming Firefox 3.1, is the version which will lead to the Release Candidate-- the old "TB 3.0", based on Gecko 1.9.0, is a dead tree.)

I've never coded a Patch to TB before, not even an extension. These are SWAGs, I'm not even REMOTELY competent about TB code and bug management. There's much smarter people than me following this bug, but it looks to me like TB 3.1 needs to kept tightly focused so that MailCo can get the release done-- As Mark indicated in comment 39, months ago, they can't even confirm "wanted" status for this one. For right now, the fire fighting seems to be elsewhere.
I've never seen it either. As earlier comments suggest, it likely has something to do with View|Headers|All (either it's set now, or has been set and some pref hangs around...) Or maybe we're all just misunderstanding. Got a image of the printout?
Summary: Printing always prints full header → Printing always prints full header (after View|Headers|All)
My bad: The trunk *IS* called TB3.0, even though the underlying "Gecko" was changed.
Only happens when I have View|Headers|All set for me. Must be some old junk in your profile/prefs.
Well, the view header did not stick on normal. When I reset it again, it printed OK.

But I would like separate settings for viewing and printing.
Status: NEW → RESOLVED
Closed: 22 years ago → 16 years ago
Resolution: --- → WORKSFORME
Flags: wanted-thunderbird3?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: