KompoZer User Guide - Appendix 7
When web pages are printed the results are sometimes unsatisfactory. Using CSS, authors can often improve this significantly though browser support for some print rules is still somewhat limited.
Although web pages are most commonly viewed on screen site visitors sometimes wish to print them to hard copy. This is particularly so with pages carrying information about an order or order confirmation, though it could occur for almost any page.
One approach is to offer a special 'printer friendly' version of a page. This is accessed via a link on the page and can be formatted to produce a good printed result. One penalty is that two versions of a page must be maintained with concomitant risk that the content of the two may differ; another is that the visitor may miss the link and use the normal method of printing so the effort is wasted.
Fortunately CSS styles provide an alternative approach. A special printer style sheet can be developed; all pages on a site can be linked to it and no special editing of individual pages is required. A page may then be printed using menu instructions such as File > Print in a browser.
Those unfamiliar with CSS should return to Section 4 of the User Guide and learn how to use Styles in KompoZer before proceeding further.
Printer stylesheets can be either internal or external (linked) sheets. What is needed is some means of identifying such sheets with the purpose for which they are intended. This is done using one of two methods.
The normal form of a link to an external style sheet, in the header of a file, is .
The normal form for the opening tag for an internal style sheet is
With KompoZer, when you open CaScadeS and click a sheet, in the general tab the 'Media list' shows 'all'. This indicates that the styles in the file apply to all media.
Normal style sheets can be changed to 'print' style sheets very easily. Proceed as follows
If you now inspect the code it will have been changed to
For an external stylesheet
For an internal stylesheet
Note. When using KompoZer, if you re-open CaScadeS the entry in the 'Media list' box will not have changed. This is a bug. To correct this save the file and revert.
This shows that the sheet applies only to print media. In the absence of a media attribute a sheet applies to all media.
Note Although CaScadeS may show the media list as 'all' and this is in fact a recognised media type the stylesheet itself does not contain this information. However it will default to applying to all media types.
Sheets that apply to all media may have individual rules tagged to apply only to print media. To do this rules must be enclosed in the @media rule.
For example the body could be styled to remove the margin and background and specify the font size in printer units
@media print {
body { margin: 0; background-image: none; font-size: 12pt; }
}
This shows a single rule being changed but rules may be grouped.
@media print {
p { font-size: 10pt; }
h1 { font-size: 14pt; }
h2 { font-size: 12pt; }
}
KompoZer does not offer any way of implementing this method automatically so if you want to use the @media rule you must edit the style sheet to add the @media by hand. Once created CaScadeS can be used to edit, add or delete rules.
This appendix is about 'Print' type media. The CSS specification includes the following types: Braille, Embossed, Handheld, Print, Projection, Screen, Speech, tty and TV. At present only Screen and, to a lesser extent, print are widely supported.
An earlier version of the specification had an 'Aural' type but this has been replaced by 'Speech'.
So what changes might you want to make to make a page print better?
The first thing to consider is probably whether the dimensions and units of measurement in the style sheet are appropriate for printing.
The CSS Specification provides specific methods for specifying the characteristics of the printed page which includes size and margin and allows different margins for first, left- and right-hand side pages and even allows classes to be applied to different parts of a document to allow these to be changed. The method is based on the @page rule. Unfortunately support for this rule is almost non-existent with current browsers so this guide recommends alternative, albeit not as flexible, methods.
Printed pages are usually presented with much wider margins than pages viewed on screen. The body element of a web page frequently has margins of only about 10px. How wide this appears on a printed page depends on the resolution of a printer and, with a high resolution printer, may be little more than a gnats whisker. For a printed page this should be quite satisfactory as will be explained.
Many printed pages use generous margins of up to 3cm. The minimum margin should probably not be less than 1.2 cm since some printers may require this. Visitors needing to file printed pages and punch them to do so may prefer a left margin of about 2cm.
All browsers apply some default margin to a printed page and the main browsers allow this to be altered. Any margin specified within a web page will be applied in addition to the margin set in the browser. Web authors should therefore not apply large margins to pages for printing but leave it to the visitor to set the browser. Where the standard style sheet applies a margin of 10 or 15px this can probably be ignored but where it is greater the print style sheet should set this to zero.
(The competition between the two sets of margins may well account for the fact that browsers avoid supporting the @page rule.)
If the style of the page is to have a wide space on each side with centralised content, it is quite possible to specify the width, which should be in inches or centimetres, and set left and right margins to auto.
After margins the most important thing to consider is fonts. Although the CSS rules allow font size for printed media to be specified in any of the normal ways the unit almost universally used for print media is the point and there appears to be no good reason to use any other.
A possible print style sheet might look like
@media print {
p, h4, ul, ol, td, a { font-size: 12pt; }
h1 { font-size: 24pt; }
h2 { font-size: 18pt; }
h3 { font-size: 14pt; }
h5 { font-size: 10pt; }
}
Font colour also needs to be considered. Many printers print in monochrome. Rather than hope that any colours used will be interpreted suitably it is better to take the bull by the horns and change color
to black.
Where items are positioned, indented or given sizes on a web page this is frequently expressed in pixels. The specification does not include any rules for mapping these to paper dimensions, so those wanting to be really fussy may wish to substitute inches or centimetres. In practice the effort is rarely justifiable as browsers make reasonable assumptions. Dimensions expressed as percentages work as normal.
The second issue is exactly what should be printed — is there material on the page that does not need printing?
The issues are twofold.
On a page like the HTML version of this, to print the navigation menu is a waste of time. Items like this can be prevented from printing by using the style rule display: none;
available on CSS editor Box tab. This rule can then be attached to any item which is not to be printed by using a class like 'noprint'. A rule to do this could be:
@media print {
.noprint { display: none; }
}
Simply tag any item not to be printed with the class 'noprint'. This will have no effect on screen since it is defined only for print media. Being able to tag items with several classes is convenient since adding the noprint class has no effect on any other class attached to an item.
The menu of this page is enclosed in its own division so the treatment described is easy. Depending on the structure of the document it may be helpful to enclose several items in a div rather than tag each individually to suppress printing.
Many authors don't show the URL of external links on screen. This makes the page tidier and links still work when clicked. When printed such links become unrecognisable and useless. An alternative is to repeat the URL after each link but to style it as display: none;
in the general style sheet and display: inline;
in the print style sheet. Just take care that it is surrounded by spaces when printed, otherwise it will look ugly.
As an example here is how I coded the first reference in section A7.4 below.
CSS2 Specification
http://www.w3.org/TR/CSS21/ introduces media in section 7 and covers paged media in section 13
The words 'CSS2 Specification' form a clickable link. The URL of the link is then repeated but enclosed in a which has the class 'extlink'.
The page is linked to two stylesheets. The sheet applicable to all media is loaded first and includes the rule
.extlink { display: none; }
The print stylesheet is loaded later and includes the rule
.extlink { display: inline; text-decoration: underline; }
Underlining the links makes them stand out and you may like to consider printing them in blue.
The order of loading the sheets is important because, if the print stylesheet were loaded first and the unspecific ('all') sheet loaded subsequently this would override the print sheet. See section 7.3.1
Images are the raison d'être of some pages so must be printed, in others they vary from major irritants to incidental material which may be omitted to save time and ink. The same approach can be used as for menus or, if all images are to be suppressed, the img element may be given the style display: none;
Some browsers will not print backgrounds at all. Others offer options, but this cannot be relied on. This applies both to background images and solid colour. On a page like this, if the menu is not suppressed it is likely to print unreliably. The background colour, if printed, may bleed into the white text, particularly with low quality paper, and become unreadable. In such cases it is much better to set up a new set of styles for the buttons using colour schemes which are workable.
Having decided what to print and where to print it, the next thing to consider is page breaks. This is a concept completely alien to screen devices. Of course the page author cannot know the size of the sheet that the page will be printed on, so manual page breaks are out of the question and we must resort to using automatic page breaks. Anyone who has used a word processor or desk top publisher will know that this is a 'dodgy' process. No less with web pages, but the CSS Specification does provide some assistance.
CaScadeS offers a tab for developing style sheets for 'aural' media (this type is now deprecated) but not print media. As a result what follows can be implemented only by editing the code by hand.
The CSS2.1 Specification covers paged media in section 13. As already stated, the @page method is largely unsupported as yet, but two properties which may improve printed layout are page-break-before and page-break after. These may be set to a value of 'always, 'avoid' or 'auto'.
Typically authors may force a page break before a major heading, for instance:
h1 {page-break-before: always}
Similarly other headings can be kept with their associated content by:
h3 {page-break-after: avoid}
The 'page-break-after' property is less well supported, at least with the value 'avoid'.
The specification also includes the property page-break-inside. This is intended to keep together associated content such as a table or div. Potentially this is an extremely useful property and overcomes one of the most annoying and spoiling features of printed pages but as of 2007 appears to be unsupported.
To keep a block item together use a class like:
.keeptogether {page-break-inside: avoid}
Having set up printer style sheets as described, all should be well but there are a few precautions to take.
Normally there will be two sets of styles, one for printed media, one for all media. If the two sets were for printed media and screen media no ambiguity could result but there are good reasons to avoid this approach:
Instead of this, it is normal to use a style sheet covering all media and a separate one for print media which includes only a few styles – those few that need to be different for print.
The specifications that control the cascading order for styles dictate that the later encountered style rules override those encountered earlier. Thus, if the rules for print media are read first, followed by those for all media, the latter will prevail and the print media rules will be ignored. It is therefore important that the link to the print style sheet should appear after that to the normal style sheet.
CaScadeS enters style sheets in the head section in the same order as shown in the 'Sheets and rules' window.
To alter the order of linked, or internal, style sheets:
As a general rule, styles for print media cannot be applied using inline styles. Possible exceptions are the page-break properties. These apply only to paged media and are therefore meaningless and will be ignored by screen and most other devices, however both print and projection are paged media so may require different breaks.
The cascading rules dictate that inline styles have precedence over all others. Authors will probably use inline styles sparingly and, other than the above, should certainly avoid specifying any styles which do not apply to all media. Inline style declarations will override any print styles so any which could give problems must be avoided.
Here are a few of the issues that you might meet when checking how your pages print. Some are undoubtedly due to the poor support for print media that browsers manage to achieve in late 2007 others may more properly be laid at the door of an inadequate definition in the CSS specification of what should happen.
The comments here are more empirical than theoretical and are based on the most recent versions of the main Browsers – Internet Explorer, Firefox and Opera.
Page breaks will usually take place in the position determined by the natural flow of the material encountered though this may be modified using page-break-before. This is usually satisfactory but may not be optimal for lists and material in table cells however page-break-inside is unsupported there is little you can do about it.
Images are the one element that require the statement just made to be modified a little. Images are not normally broken so, when they will not fit in the space remaining on a page, a page break will be thrown and the image will appear on the following page. This is entirely natural and what would be expected.
Where elements are floated a number of problems can occur. A simple way to overcome these is to avoid floating anything on a print style sheet. This is quite easy to achieve if all floats are done using a class. For instance, to float something right you might set up a rule in the general style sheet
.floatr { float: right; margin-left: 4px; }
while in the print style sheet you might have
.floatr { float: none; }
If you find this over restrictive you need to look at the problem areas. These are mainly images and tables.
Images contained in block elements (e.g. paragraphs or divisions) which are floated will behave, as far as page breaks are concerned, in the same way as if the blocks (and images) were not floated.
Images placed directly in the body or in non floated block elements and then floated are liable to be split across a page boundary or to be truncated depending on the browser. The simple solution to this is to float the block in which the image is located if necessary creating one specifically to hold it.
Floated tables appear prone to a variety of problems including locking up browsers. Avoid if at all possible.
Long columns, as used for instance in some layout schemes, are to be avoided if they are likely to overflow from one page to the next.
As usual the advice is avoid if possible otherwise check, check and check again.
Pages and style sheets designed as suggested will be rendered satisfactorily, though not perfectly, on most browsers. At the time of writing (late 2007) all of the major browsers have difficulty with some aspect of print styles. Authors should not hope to be really prescriptive about how the final output appears. Web Devout has a useful page detailing Web browser CSS support. Coverage will undoubtedly improve with time.
Readers will know that KompoZer masquerades as a passable browser. This can be pressed into use when developing print style sheets. For testing purposes, once the style sheets have been linked in the correct order it is simple to relink the print style sheet as an 'all' style sheet (reversing the process described in A7.1.2.1). After closing and reloading the file the Normal view or Preview mode then become print view modes. The style sheet can then be refined while immediately seeing the result. Don't forget to change back to 'print' before finalising!
[1] CSS2 Specification http://www.w3.org/TR/CSS21/ introduces media in section 7 and covers paged media in section 13
[2] Web Devout http://www.webdevout.net/browser-support-css has a useful page detailing CSS support for several modern browsers.
[3] WestCiv http://www.westciv.com/style_master/academy/browser_support/index.html has summary information about a wide range including older browsers .
A number of sites cover various aspects of printing though none are at all comprehensive.
[4] A List Apart http://www.alistapart.com/articles/alaprintstyles has an excellent article by Eric Meyer on choosing styles for printing. Probably the best available.
[5] http://webdesign.about.com/cs/css/a/aa042103a.htm gives a general introduction by Jennifer Kyrnyn to considerations for printed pages.
[6] Opera offers some useful general information. http://my.opera.com/community/dev/device/css-media/
[7] WestCiv offers more specific information about @page and page properties. http://www.westciv.com/style_master/academy/css_tutorial/advanced/printing.html
[8] Rich in style has a fairly informative page about paged media. href="http://www.richinstyle.com/guides/fontface2.html This will become more useful when @page is better supported.