Closed Bug 102596 Opened 23 years ago Closed 23 years ago

[WFM]headers/footers are cropped by edge of paper

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.1alpha

People

(Reporter: sujay, Assigned: rods)

References

Details

Attachments

(1 file, 2 obsolete files)

patch (k drive)
19.63 KB, patch
roland.mainz
: review+
kinmoz
: superreview+
Details | Diff | Splinter Review 
using 10/1 linux build for netscape

1) launch netscape
2) print any page

notice the URL in the upper right hand corner does not print out
and also the Page title in the upper left hand corner does not
print out.

works on Windows and Mac. problem on Linux only.
Status: NEW → ASSIGNED
sujay, are you still seeing this?  I can't reproduce this in a Linux nightly...
I haven't seen this either. Please un-future this nug once it is reproducable
Target Milestone: --- → Future
*** Bug 109376 has been marked as a duplicate of this bug. ***
Unfuturing.  I misunderstood the problem initially.  When I print to file, I see
the headers/footers just fine, but they are near the edge of the page.  When I
print this postscript to a printer (which I did not try till today) they do not
get printed; presumably because the printer cannot handle text that close to the
page edge.
Target Milestone: Future → ---
updating summary
Summary: header info not printed out for Linux → header/footer info not printed out for Linux
Is all the text missing? 
Or just the patr that is near the edge of the page?
Well, all of it is near the edge.  It's flush with the top/bottom edge of the
paper, and the font is fairly small...
*** Bug 111839 has been marked as a duplicate of this bug. ***
Summary: header/footer info not printed out for Linux → headers/footers are cropped by edge of paper
Attached patch patch (obsolete) — — Splinter Review 
Since each platform renders differently on the page we want to make to a pref
to indicate how much gap in twips should be above/below/left/right of the
header/footer
Attachment #59364 - Attachment is obsolete: true
Attached patch patch (obsolete) — — Splinter Review 
We need to be able to specify to things:
1) An extra gap or dead space around the entire contents of the page. This
represents the unprintable space between the edge of the paper and where the
platform printer driver starts printing. This is needed only for Print Preview
so what is on the screen closely resembles what is on the printed page.

2) An extra space or gap between the headers/footers and the edge of the page
when in print preview and printing. Some platforms allow the print driver to
print on 100% of the paper and therefore we need to specify a gap so they do
not print all the way to the edge. This is used only for the headers and
footers and it does not shrink the area the contents will print into. When this
is specified then item #1 is usually set to zero.
Summary: headers/footers are cropped by edge of paper → [FIX]headers/footers are cropped by edge of paper
Target Milestone: --- → mozilla0.9.7
r=dcone..
I am not sure if you have this.. but you might want to do a check on the 
following kinds of code to make sure x is greater than 0 when your done.

-      x += aRect.width - width;
+      x += aRect.width - width - mPD->mExtraMargin.right - mPD->mHeadFooterGap;
Comment on attachment 59373 [details] [diff] [review]
patch

sr=attinasi
Attachment #59373 - Flags: superreview+
The headers/footers printed well in earlier milestones (like 0.92 or 0.93). So
it may be helpful if you can compare the current codebase with what was before.
A lot has changed since then.
fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Has the fixed checked into some nightly builds so that we can test it? Really
cannot wait for longer to have this feature :-).
Yes, it was checked in this morning, so it should be in today's build.
when you said today, do you mean today's midmight (13.5 hours away PST) or it's
already there if I download the nightly build right now?
THe build from today that they are spinning right now. I checked in the code 
this morning before the tree closed.
I downloaded the nightly build (2001112808) and the problem is still there: no
headers/footers are printed. Pls note: I am using the same printer for both IE
and Mozilla and only IE can print the headers/footers. Is there any setting I
need to do with mozilla in order to print out the headers/footers?
What platform are you printing on? (Win2k?)
What kind of printer are you printing to?
What is the page you are trying print (I guess any page)?
My previous tests:
IE--on win2k,  headers/footers printed
Mozilla nightly build on Mandrake 8.1, no  headers/footers printed
Printer Brother HL 1440

Now I go back and downloaded Mozilla milestone 0.92 (Mozilla/5.0 (X11; U; Linux
i686; en-US; rv:0.9.2) Gecko/20010628) and tried the same test, and it printed
out all the headers/footers (left-upper corner: the title, right-upper; the url,
lower-left: page no./total page, lower-right: timestamp).

So the problem is clearly with the current Mozilla build. Can you double check
if your fix has been built in to the current lastest nightly build.
*** Bug 112654 has been marked as a duplicate of this bug. ***
REOPEN...still not fixed Rod. I'm using 11/29 build on linux.

definitely not fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 112654 has been marked as a duplicate of this bug. ***
They aren't cropped , they aren't showing. Can't reproduce at the moment
Status: REOPENED → ASSIGNED
Summary: [FIX]headers/footers are cropped by edge of paper → headers/footers are cropped by edge of paper
adding Boris' comment from other bug:

------- Additional Comment #5 From Boris Zbarsky 2001-11-29 13:09 -------

Rod, the spacing you put in for the "default postscript" printer on unix is far
too small.  I'd give it a quarter inch between the edge of the page and any
header-footer text....
OK.  The default unix setting for the header/footer gap is 60 twips.  This is
about 1/12 of an inch, if I understand correctly.  This is far, far too small.
Experimentation with the HP LaserJet 8150 here shows that a value of at least
180 twips is needed to be able to read the text, a value of 240 is needed if
ascenders are not to be cut off.
Boris,

Sounds like we need to be able to specify a Margin, because the top, botom and
sides will probably be
different. 

Could you experiment and let me know what the offsets should be for each? 

Rod will work on a patch to be able to set each.

I only have one type of printer I can test, and I only have Unix machines.  I
just tested, and the top/bottom/left/right offsets all need to be the same and
240 twips or so.

*** Bug 112799 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.7 → mozilla0.9.8
If I were you, I would go back and look at the source code in the earlier
milestones (0.92/0.93) and find out what has been changed to make this printing
feature unavailable in the later milestones (0.95/0.96).
We know what changed.  Rod even fixed it by adding a pref-able offset from the
edge of the paper.  However, the default offset of the headers from the edge of
the paper needs to be on the order of at least a quarter inch to have a hope of
displaying correctly.  A half inch should be safe for the vast majority of printers.

All that needs to happen is that those prefs need to get tweaked to be bigger.

If you feel like helping out, test how close to paper edge your printer will
print and comment on this bug with the results.  That will give a bit more hard
data on which to base the default offsets.

The pref in question is "print.print_headerfooter_gap", see 
 
http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/win/winpref.js#181
http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/unix/unix.js#111
http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/mac/macprefs.js#235

and the like.

Rod, it may make sense to put a default in all.js and only override in the
platform-specific files... 


 
I would like to help out. Can you tell me the exact steps for me to do the
testing? For example, which build should I use? How do I tweak the pref
settings? I am only talking about the Linux OS.
Get any build that has this bug (today's nightly will do).

Put:

user_pref("print.print_headerfooter_gap", 60);

in your prefs.js.  Start Mozilla.  Got to a page and print it.  If the headers
are cut off, quit mozilla, edit prefs.js and change the 60 to a larger number. 
Restart Mozilla, print.  Repeat until you have a decent lower bound on the size
that gap should be to print correctly.


I downloaded today's nightly build for Linux, put the line you mentioned above
in the prefs.js file, and printed a few pages. I set the number to 60, 160, 260,
and 240. 60 seemed to be a little too small. 160, 240, and 260 gave acceptable
header/footer printings. I am pretty happy with the fix. Is there any reason why
you cannot add such a line into prefs.js and set a default number that is around
200?

By the way, the printer I printed to is a networked Xerox DocuPrint N24. I am
gonna try the Bother HL 1440 printer at home later.
I tried the Brother HL 1440 printer with different settings. I could get
acceptable header/footer (the probblem is mainly with the headers) printing only
by setting print.print_headerfooter_gap with numbers larger than 450.

So this number needs to be set differently for different printers. The
interesting point is that with earlier Milestones (0.92/0.93), the header/footer
printing worked with all the printers I have used without any tweaking. 

Again, I am curious about what changes have been made to make this feature so
difficult to achieve. 


On FreeBSD4.4 [i386] and HP LaserJet 2100TN:

I've added ``user_pref("print.print_headerfooter_gap", 60);''
to my prefs.js and checked that it is read by mozilla
(by modifying the printer command).
``60'' or any other number makes no difference whatsoever.
Headers and footers are nicely displayed on the Print Preview,
always on the same place on the edge as if the position
were hard-coded.




Harald, which build are you using?
A thought.  One reason we could get all this variation in what the length needs 
to be set to is that the length is in _twips_.  The size of a twip depends on 
the dpi of the device context, no?

It would make more sense to me to set the length in some sort of physical size 
units, like mm or in.
we really need to get a fix ASAP...printoutputs are not looking good because of
this...it used to work fine before...
*** Bug 116921 has been marked as a duplicate of this bug. ***
Recommendations for looking up size of
dead zone on non-full-bleed printers.

In an openoffice installation, grep the
files /whereever/share/psprint/driver/*.PS for
"ImageableArea Letter/US Letter".

I see that typically you cannot mark 
within 15/72 inch of the sheet edge.
*** Bug 119754 has been marked as a duplicate of this bug. ***
Chunnuan, what are the DPI values for the two printers you tested (the one that
needed ~160twips and the one that needed ~450 twips)?

I think the headers/footers used to be _inside_ the margins.  So they were
always 0.5 inches from the page edge...
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Instead of putting the header and footer to a fixed place, how about extending
the printer-panel with 4 values:
- Font for header and foot
- Vertical size for header and footer
Make the footer and header area inside the margins given in the printpanel.

Schema:
...........................................
.  physical margins       T               .
.  ...................................... .
.  .    header area            | size 1 . .
.  .------------------------------------. .
.  .                                    . .
.  .                                    . .
. L.                                    .R.
.  .         page context               . .
.  .------------------------------------. .
.  .    footer area            |size 2  . .
.  .                           |        . .
.  ...................................... .
.                 B                       .
...........................................
Attached patch patch (k drive) — — Splinter Review 
Since there are many different printer and it would be hard to specific either
a single value or even a set of margin values that would cover all cases. 

I have decided to make it a margin and enable the user to set the values (in
1/100 of inch) via the PrintJobOptions dialog while printing. This may be
something we will want to change in the future to be on an individual printer
basis. The values will be persistent in the Prefs.
Attachment #59373 - Attachment is obsolete: true
Summary: headers/footers are cropped by edge of paper → [FIX]headers/footers are cropped by edge of paper
Comment on attachment 65823 [details] [diff] [review]
patch (k drive)

-- Should we move the maxval check under the |if| statement before
   it so that element.value gets set only once to avoid possible
   flicker in the textfield?

   +function checkDouble(element, maxVal)
   +{
   +  var value = element.value;
   +  if (value && value.length > 0) {
   +	value = value.replace(/[^\.|^0-9]/g,"");
   +	if (!value) value = "";
   +	element.value = value;
   +  }
   +  if (value > maxVal) {
   +	element.value = maxVal;
   +  }
   +}



-- There are a couple of places where you do a getService of
   nsIPrefBranch and then do a get/set of the prefs inside a
   try/catch block:


   +  var pref = Components.classes["@mozilla.org/preferences-service;1"]
   +			   .getService(Components.interfaces.nsIPrefBranch);
   +  try {


   Since the getService() call can also throw an exception,
   it should probably be moved under the try too:


-- As Boris pointed out earlier, since only Unix seems to override
   the default zero values for "print.print_edge_*" prefs, why aren't
   we defining the default prefs with zero values in all.js, and
   modifying unix.js with the values it needs, instead of modifying
   all of the platform specific pref .js files?


sr=kin@netscape.com with the suggestions/modifications above.
Attachment #65823 - Flags: superreview+
fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Does this look fixed to everyone? Boris ?
still not fixed in 2/4 build on Linux.

This used to work great in the past...why can't we roll back to when
it worked ?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Keywords: nsbeta1
I am not sure, but may be the patch in bug 120916 ("PostScript/Xprint module
revamp") can help...
What is wrong? 

The fix wasn't that the extra "gap"  between the margin and the edge would
always be correct. It's that you can now put in your own "gap" for your printer,
because it printer handles it differently.

I can explain why it used to always work, because I have considerable time
trying to figure that out.

I just tested out putting in different values it is works.
Status: REOPENED → ASSIGNED
Summary: [FIX]headers/footers are cropped by edge of paper → [WFM]headers/footers are cropped by edge of paper
Ok I will retest...Boris/Roland, does it work for you? please try on your
system also...
I don't see this problem with my tree (which includes patch from bug 120916) and
Xprint module...
Chunnan, how about you? does this work for you now?
Resolving as fixed. As per conversation with Rods.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla0.9.9 → mozilla1.1
resolving per Kevin's comments.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
marking verified.
Status: RESOLVED → VERIFIED
*** Bug 127615 has been marked as a duplicate of this bug. ***
Sorry I have missed your recent updates on this bug. I still have a little bit
problem with my Brother 1440 printer with regard to the header printing. The top
1/4~1/5 gets cut off. So the top portion of letters such as 'l','b','h' will be
cut and is kind of annoying. On the other hand, the footer printed perfectly.

I am using:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020425

on Mandrake Linux 8.2.

1. I tried resetting the "top" margin on the printer properties page from 0.04
(default) to 0.22

2. I also tried by putting the something like

user_pref("print.print_headerfooter_gap", 260); 
or 
user_pref("print.print_headerfooter_gap", 460); 

in the prefs.js file and restarted the browser

3. I used the KUPS printer manager to increase the top margin from 0.5 inch to
1.5 inch

4. I tested the printer by setting the resolustin at 300 dpi or 600 dpi.

All above measures didn't help resolve the problem. I am not sure if the this
problem only happens to me and would like to know if there is anything else I
can set to make the header print in its completeness.


can anyone else reproduce CHunnan's problem?

Do we need to REOPEN this bug ?
I use Debian 3.0 and the mozilla rc1. There the headers are printed.
I'm betting chunnuan is seeing bug 140699 (the fact that the UI is broken) plus
the fact that the pref is not called "print.print_headerfooter_gap" anymore...
It's now "print.print_edge_top" (and right/left/bottom instead of top), but see
bug 140699 for more on that... :(

This bug is still fixed in that if you set the right prefs it all works correctly...
I believe it's 140669, not 140699, that Boris is referring to.
John
Adding something like the following fixed my problem:
  
    user_pref("print.print_edge_top", 8);

the number 8 seems to be the smallest number I can use in order to have the
headers printed in its fullness. 

According to the current state of bug 140669, I still need to enter above line
manually, the change made through the printer properties page won't work. 

I am not sure how many users' printers are affected in this way. It may be a
good idea to change the default print_edge_top setting (shifting it by 10 or so)
if there are many printers are affected.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: