There a several components in printing that are either buggy, have one or more design flaws. The overall code isn't touched since ages and needs a good rewrite. Printername Enumerator The printer enumerator nsIPrinterEnumerator results on Linux returns prefixed printernames. The nsIPrintSettingsService however returns prefix less for printerName. Paper Selection: There are to many different ways to select a paper, specially nsIPrintSettings can have totally broken paper settings, including failing to printpreview/print on Linux because settings are broken. No code path should assume only a subset of paper sizes. Win32: Can select a paperData, but the width and height can totally disagree, paperName is ignored. The win32 backend doesn't query paper names at all, for every Printer the backend should query available Paper Names and Paper Sizes via DeviceCapabilities DC_PAPERS to get the IDs, DC_PAPERNAMES to get display names, and DC_PAPER to get the actually size of that paper. The code assumes a printer always supports all win32 default paper sizes, neither does it query the possible papers for a selected paper. Overwriting is possible via printSettings to get a mostly sane selection. Note: Current Firefox on Win32 has no way to let users select paper size before doing a print or PrintPreview. Linux GTK: Uses a combination of paperData, paperWidth, paperHeight that is incompatible with PSPaperNames. iso_A4 <-> A4. nsDeviceContextSpecG.cpp assumes fixed paper names via PSPaper Names and still use temp prefs via CopyPrinterCharPref. The paper names are incompatible with GTK. GTK provides gtk_paper_size_get_paper_sizes which likely is a more sane way. Technical all platforms should agree on one format setting in the prefs. A universal format is PWG 5101.1-2002, Self-Describing Names. The css3 paged media specs names them PWGMSN / Media Standardized Name The benefit is that there is name of paper and the size. Supports both inch and mm. gtk_paper_size_new should handle them well. For the iso formats a table can be created on the fly easily to convert between formats. For any windows formats, they can be described as custom format. The size part of the paper name can be used to select a paper if the currently selected isn't found. Non printable margins: The printing backend disagree about paper surface sizes. Linux: Linux GTK uses always the full surface. There a non printable margins in the settings. This needs more testing how they are used. Win32: The device context is the real printable surface. There a no code paths to query the non printable margins, nor the offsets. A Win32 DEVMODE provides the offsets but isn't used. CSS and Printing. CSS2 @page margins on Win32 will be applied to printable surface. Meaning they sum up Specially considering CSS3 allows selecting a paper size. There is no ui to disallow this or show why the margins can't be changed. In CSS3 Paged media it is possible to select the paper size via alias or PWGMSN name: @page { size: letter; } moznomarginboxes (see Bug 743252) Simple sets margins to zero and disables printing headers and footers. Still on win32 you still have only a smaller surface. This means if a document uses a left and top margin around it's content the right and bottom edge will be cut even if the printer could technical print. And you still have the offset. Note: Fit to Page isn't an option, as this will reduce the overall size. Sum up: A cross platform way to enumerate Printer, their Paper sizes, selecting the paper by name for a printer and querying the non printable margins for the select paper.

Thanks for compiling this list. I think this is probably better as a meta-bug which depends on many bugs for different aspects of the problem. I know I keep asking you to do more work, and if this is too tedious I understand, but if you could go through all existing bugs about printing, figure out which of the above issues are already filed, file new bugs for the ones that aren't, and add them all as dependencies to this bug, that would be very helpful. (If you can't add dependencies, just post a list in the comments and I'll do it.) I personally am not going to rewrite any more of the printing system until bug 629500 is done, but some of the issues raised here are orthogonal. I'm going to add a dependency on that bug. I'm also adding two other bugs that I know are relevant. Bringing over some comments from bug 650966 which are more on topic here: > So I tried to write a workaround at the internals using negative margins for > win32, but this end up not very successfully as page reflow was crashing. > The margins system is insane for win32 and I have no idea to fix this as the > internals have no concept that a actually device surface is actually smaller > on windows (only the printable area) then the selected paper size. I haven't looked at that part of printing at all myself yet, but Elika (fantasai) may have. cc:ed.

Technical any CSS3 paged media settings depends on a sane way to see if a paper size can be selected, preselected and maybe even warn the user. Say you have a Label Printer and trying to set @page { size: A4; } is useless. #851937 #286443