GNOME Bugzilla – Bug 346110
Headers and footers may be unvisible
Last modified: 2014-01-02 23:46:11 UTC
When printing from Epiphany, the page headers and footers are positioned at the very edge of the page - there's no margin between the page edge and the header/footer. This means that the header/footer text is not (or only partly) visible if your printer does not reach the paper edges. I suppose that this is the case for most printers used at home. The printing dialog in Firefox has an option called »Gap from edge of paper to margin« which can be used for a workaround. There is no obvious workaround for Epiphany.
Does this still happen with epiphany 2.15 which is using the new gtk print dialogues?
I've spent hours now trying to compile a release of gtk that goes with epiphany 2.15, but did not succeed, getting an error about undefined references to g_bookmark_file_* symbols. So I'm afraid I cannot report about that.
The Print Preview on epiphany 2.15.4 (Mandriva Cooker) seems to confirm this problem.
Does the same occur in firefox if you set headers/footers ?
The same thing happens in Firefox, except that Firefox has a 'Properties' dialog under the Print dialog that allows to change the gap setting mentioned in comment #0. When increasing that setting the header is positioned lower on the page.
You can set the margins in epiphany too, File->Print setup .
After looking really carefully under the Page sizes dropdown I found that I could specify my own page size with custom margins. (This has to be one of the best hidden dialogs in all of GNOME!) However, after changing the top margin from 0 to 10 mm, the print preview still shows the header directly along the top of the page.
*** Bug 415861 has been marked as a duplicate of this bug. ***
This is probably a gecko bug then.
Created attachment 94031 [details] [review] Sets page header and footer margins to a reasonable value I'm printing from Gnome using LPRng, not CUPS. However, in either case, XUL runner reads the page header/footer margins from javascript. It might be the case that CUPS users may have to change the printer's name within the patch from "PostScript/default" to "CUPS/default" or something similar. Nothing has to be recompiled, just modify "default-prefs.js" for a quick test.
Thanks for figuring this out! We always use the PostScript/default printer, so the prefs names should be ok. Now this shouldn't hard-code the values of course, but instead use something that corresponds to what the printer actually supports; but gtk doesn't expose this info. I've filed bug 468989 for that. Also we'll need to file a gecko bug since setting prefs for this is really not the right way.
Filed as https://bugzilla.mozilla.org/show_bug.cgi?id=396278 .
let's get this work-around in for now. The upstream bug is close to checkin, but we still depend on the gtk feature which won't be done until gtk+ 2.14. Trunk and gnome-2-20 please. Thanks for the patch!
Committed. Leaving the bug open for a proper resolution when upstream mozilla and gtk+ bugs are solved.
@Cosimo, now that bug 468989 is fixed, what can we do here? Mozilla bugs are no longer relevant of course.
Sounds obsolete to me. If still an issue please reopen.