This is not an UI spec. This is an incomplete collection of thoughts about what I would like to see in the printing UI.
The Page Setup / Print model was designed for apps where the user is the author of the document and works on the document in a constant print preview mode—ie. the app uses the WYSIWYG paper paradigm. With such an app, the user already knows what the page layout is going to be when (s)he selects print. Also, settings made in the Page Setup dialog are saved with the document.
With an app like a Web browser the user is not necessarily the author of the document and the document isn’t viewed in a constant print preview mode. When the user selects Print in Nav 4.x, (s)he does not know exactly how the document get paginated. That is bad.
Mozilla needs an “I wanna print” mode (hereinafter referred to as the “Print As window”). In that mode the browser would display a suggested paper page layout and the user could customize it. This way the user would know what to expect from the printer. I doesn’t make sense to display online documents with a paper page layout while browsing, but it makes a lot of sense to display them that way prior to printing.
It doesn’t make sense to associate document-specific Page Setup information with online documents. Therefore, Mozilla shouldn’t extend the Page Setup dialog in any way. Ideally, if the printer driver defaults to the paper size the user always keeps in the printer’s paper tray and the Print As windows allows scaling of the page, access to the Page Setup dialog isn’t required at all in normal situations. This means that Mozilla doesn’t need a menu item called “Page Setup…”, either. The Page Setup dialog could be made accessible via the Print As window for the rare occasions when the Page Setup really needs to be accessed.
The only print-related menu item that is really needed is “Print As…”, which would open the Print As window. However, some users don’t want to spend time previewing and fine-tuning the page layout. They just want to print as fast as possible. If the implementation of the Print As window turned out to be slow, another menu item called “Print ” could be provided. This command would bypass the Print As window and proceed to the platform Print dialog with the default settings.
The Print As window would provide the user with various settings affecting the print output and a preview displaying the effect of the settings on screen. Here is a list of possible settings:
!important style sheet:
<table> grid
The CSS spec allows specifying multiple style sheets per document. These style sheets can be intented for different media and there can be alternative style sheets for a particular media. When the Print As window is opened, the default selection in the Author’s Style pop-up menu should be the primary author style sheet for the print media.
Print is not the only useful media type, however. Style sheets for the screen and projection media types should be selectable also. The user may want to have a hard copy that resembles the screen presentation as closely as feasible and the printing functionality can be used for printing transparencies or slides. The media type of each style sheet should be indicated in the menu.
User style sheets can be optionally cascaded in with the author styles. Users may want to override the authors choices for color for example. The default setting of the My Style pop-up menu should be a preference. (See below.)
The author’s idea of suitable image size, spacing, etc. might not suit the user’s needs. This can be remedied with an ability to apply scaling to physical lengths and pixel lengths that are converted to physical lengths for the purpose of printing.
Experience shows that the font size is a very important aspect of readability of a document and also affects directly the number of paper sheets required for printing. For this reason, there is a need for an font zoom in addition to general scaling of units.
Margins are important in printing and some user will want to have a good control over them. Overly large margins waste paper. Small margins may cause problems with the restrictions on the imaging area of the printer or make the document hard to read.
While margins appear to be a trivial concept in word processors, the effective margins of a style HTML or XML document depend on many factors. The effective margin can consist of margins and padding on multiple boxes. <table>s can also be used to create margin-like empty areas. Ideally the UI would let the user modify the effective margin be dragging with the mouse in a way that would hide the details of the box areas that make up the effective margin.
When borders are not used or the borders are of the same color as the background, the inner edge of the effective left margin coincides with the left edge of the content area of the leftmost that has text or an image directly in it. Being able to change this effective margin would be user-friendly but non-trivial to implement. Ideally the effective margin would be indicated on the above-mentioned rulers in such a way that the user could change the effective margin with the mouse without knowing the details of boxes.
A couple of additional preferences would be useful:
Generally, the optimal font size is different for different media. Therefore there should be different preferences for different media.
Modification to style via the DOM causes problems with printing. It is straight-forward that images should be printed in the state of the DOM they are at the printing moment. However, style sheets can set different visibility and display properties for elements on different media. DOM applications typically modify these properties, too. Using the “correct” style in printing is a tricky issue if the style properties have been modified via the DOM and a print style sheet is used also.