Skip links en inhoudsopgave

Een pagina met behulp van css printvriendelijk maken

www.css-voorbeelden.nl

Dit artikel is van toepassing op Firefox, Safari, Google Chrome, Opera en Internet Explorer 7, 8 en 9. Voor zover er verschillen zijn tussen deze browsers op Windows, OS X en Linux, vermeld ik dat ook (hoewel ik daar best wat in gemist kan hebben vanwege de grote hoeveelheid uit te voeren tests).
Links in dit artikel, vooral links naar andere sites, kunnen verouderd zijn. Op de pagina met links vind je steeds de meest recente links.
Laatst herzien op .

LEES DIT EERST

(Aanvulling 15 april 2012: de oorspronkelijk tekst van dit artikel dateert uit juli 2010. Het testen van wat hierin staat, kost ongelooflijk veel tijd. Bij latere herzieningen heb ik daarom lang niet alles opnieuw getest. Maar wel genoeg om de belangrijkste conclusie overeind te houden: maak een pdf als de pagina ook maar enigszins lastige onderdelen heeft. Sommige dingen werken inmiddels wat beter, maar sommige dingen werken vreemd genoeg slechter dan in juli 2010.)

Delen van de tekst die om een of andere reden echt belangrijk zijn, staan in een rood kadertje. Hierin staat vaak bijvoorbeeld een hele korte samenvatting van mogelijke problemen.

Vanwege de vele bugs en afwijkingen is uitgebreid testen in alle bekende browsers absoluut nodig, als je een pagina printvriendelijk wilt maken. Vaak is het veel beter (en makkelijker) om een pdf te maken, als iets printbaar moet zijn.

In alle browsers zitten grotere en kleinere fouten bij het afdrukken. Soms verdwijnen er zelfs stukken tekst. Eigenlijk zijn alleen simpele tekst, afbeeldingen, borders, en dergelijke betrouwbaar af te drukken, maar ook daarbij heb je geen volledige controle over de lay-out. Als die lay-out echt belangrijk is, kun je veel beter een pdf maken.

Zodra je met tabellen en andere iets ingewikkelder zaken gaat werken, wordt de kans dat er dingen echt misgaan (verdwijnen van stukken tekst bijvoorbeeld) snel groter. Dingen als nieuwe pagina's maken (of juist niet) en printen in landschap-mode kun je helemaal vergeten. Voor zover ze al zijn geïmplementeerd, werken ze vrijwel zonder uitzondering niet goed.

Kortom: zodra de lay-out echt belangrijk is, of zodra het drukwerk iets ingewikkelder is: maak een pdf.

Dit artikel is niet goed te volgen als je niet ook een geprinte versie hebt. Zonder een geprinte versie kun je niet zien, wat voor effect bepaalde css heeft, omdat die alleen voor een geprinte versie werkt. Een geprinte versie hoeft niet op papier te worden geprint. Er zijn de volgende mogelijkheden:

Algemeen

Kun je 'n afgedrukte pagina van je site er bij iedereen altijd hetzelfde uit laten zien?

Ja, dat kan. Met behulp van de meest moderne technieken is het tegenwoordig mogelijk om een pagina zo te bewerken, dat hij perfect geschikt is om af te drukken. Nadat je zo'n voor printen geoptimaliseerde pagina hebt gemaakt, druk je deze af met 'n printer. Daarna kun je met 'n ander wonder van de moderne techniek, de kopieermachine, op magische wijze deze eerste afdruk vermenigvuldigen. En 't mooie is: al die kindertjes van de afdruk zien er precies hetzelfde uit.

Vervolgens koppel je hier 'n andere moderne techniek aan: de postbode. Of je gebruikt 'n iets oudere techniek: de fiets. De echte fanatiekeling opteert natuurlijk voor de postduif. Met al deze methoden kun je de lezer 'n afdruk van je pagina bezorgen, die er precies zo uitziet als de bedoeling is.

(Inmiddels zijn opeenvolgende regeringen met CDA, VVD, PvdA en D66 er in eendrachtige samenwerking in geslaagd de postbode binnenkort uit te roeien, dus alleen fiets en postduif blijven over.)

Serieus: het is onmogelijk om zeker te weten dat 'n afgedrukte pagina er bij iedereen hetzelfde uitziet. Sterker nog: je weet zeker dat dat niet het geval is. Drukwerk kan na het drukken niet meer worden gewijzigd. Daarentegen hebben browsers en printers verschillende mogelijkheden, papierformaten verschillen, mensen kunnen kiezen voor 'n afdruk in zwart-wit of kleur, achtergronden kunnen wel of niet worden geprint, enz.

Een aardige illustratie van hoe weinig controle je eigenlijk hebt: ik heb een eerdere versie van dit artikel op papier geprint. Gewoon met standaard-instellingen, zoals de meeste mensen die zullen hebben, op een Canon Pixma iP4000. Voor exact hetzelfde document gebruikte Firefox op Windows 45 pagina's en op Linux 48. Google Chrome op Windows gebruikte er 58 en op Linux 44. Opera op Windows 33 en op Linux maar liefst 61. Safari op Windows gebruikte er 44 en op OS X 52. Internet Explorer 7 gebruikte er 38, Internet Explorer 8 50 en Internet Explorer 9 ten slotte 42.

Deze verschillen ontstonden onder andere door verschillen in lettergrootte, marges aan de buitenkant van het papier, en marges tussen kopjes en tekst. De verhoudingen klopten overal wel: bij een kleinere basisletter werden kleinere letters gewoon nóg kleiner. Op dit aantal pagina's heb je eigenlijk geen enkele invloed. Je kunt de letter wel kleiner maken, maar dan wordt hij in sommige browsers weer té klein. En niet alle printers gehoorzamen de lettergrootte volledig.

Naast het gebrek aan controle over de lay-out is de ondersteuning voor printen eigenlijk erbarmelijk slecht. De meeste mogelijkheden die css biedt, zijn in de meeste browsers nog niet geïmplementeerd. Verder zitten er echt regimenten bugs en afwijkingen van de standaard in de diverse browsers. Printen met enige kans op succes kan eigenlijk alleen bij vrij simpele pagina's zonder al te veel lay-out.

Je kunt wel proberen 'n afdruk er zo goed mogelijk uit te laten zien. Daarbij gaat het dan om algemene dingen. 'n Link die je aan kunt klikken, heeft op papier weinig nut, om maar iets te noemen. Dat prachtige logo bovenaan je site staat daar heel leuk, maar je bezoekers worden echt niet gelukkig, als dat de bovenste helft van alle pagina's bedekt.

Als het echt heel belangrijk is dat de lay-out van je pagina precies door jou gecontroleerd kan worden, is het maken van 'n pdf een goed alternatief. Daarbij kun je dingen als pagina-indeling, lengte van regels, enz. exact aangeven. En als dat wordt afgedrukt, ziet het er altijd (vrijwel) hetzelfde uit.

Op deze site is de uitleg in de downloads bij de voorbeelden 'n pdf. Dat werkt veel preciezer dan proberen de uitleg van de site printbaar te maken. Dat kan misschien wel, maar dat zou echt ongelooflijk veel werk zijn. En er bovendien bij iedereen toch weer (heel erg) anders uitzien. Een pdf is veel makkelijker te maken en geeft een veel grotere controle over de uiteindelijke lay-out.

Bijkomend voordeel van 'n pdf is dat je er ook links en ankers (links binnen het document) in kunt stoppen. Op het scherm zit bijvoorbeeld een complete inhoudsopgave onder 'n knop. Die kun je in 'n pdf in het document zetten, met ankers naar de juiste plaatsen. En omdat 'n pdf zo handig is, gaan mensen 't dan hopelijk niet afdrukken, zodat er weer 'n paar stukjes papier en drukinkt worden uitgespaard en 'n Braziliaanse milieu-activist mogelijk niet wordt vermoord.

Tip: alle pdf's die op deze site in de downloads zitten, zijn gemaakt met het gratis LibreOffice. Daarmee kun je minstens evenveel als met Office van Windows, en vaak zelfs meer, zoals het maken van een pdf. Gratis, open source en houdt zich aan open standaarden, wat wil je nog meer...

In dit artikel komen alle algemene problemen, waar je bij printen tegenaan kunt lopen, aan bod. Omdat ik het artikel op deze pagina zelf als voorbeeld neem, komen ook dingen die specifiek op deze pagina spelen aan bod. Of feitelijk: dingen die spelen op álle pagina's met artikelen op mijn site, want die hebben allemaal ongeveer dezelfde opmaak. Elke pagina die afgedrukt moet kunnen worden, zal een combinatie van algemene en voor die pagina specifieke problemen hebben.

Overigens is ook niet iedereen het eens over wat je wel of niet moet afdrukken. Moet je bijvoorbeeld een advertentie afdrukken of niet, om maar iets te noemen.

Het is niet nodig om 'n aparte pagina te maken om af te kunnen drukken. Met 'n beetje geluk hoef je helemaal niets aan de html te veranderen om de pagina te kunnen afdrukken. Bij afdrukken wordt automatisch 'n stylesheet gekozen waar media="print" bij staat:

<link rel="stylesheet" href="print.css" media="print">

Als er geen media aan de style wordt toegevoegd, wordt de standaard-instelling gebruikt: media="all". Dat wil zeggen dat de style geldig is voor álle apparaten. Vaak wordt media="all" erbij gezet, maar dat is eigenlijk niet nodig, omdat dat automatisch de standaard-instelling al is.

Omdat de style met media="all" (of helemaal zonder media) voor álle apparaten geldt, geldt deze ook voor de printer. In de style voor de printer hoef ik dan ook alleen maar css neer te zetten voor de dingen, die bij printen anders moeten dan in de algemene css.

De style voor de printer moet ná de algemene style komen. Bij gelijke specificiteit (gewicht) van de css wordt in principe de laatste css gebruikt. Als de algemene style ná die voor de printer zou komen, is er een grotere kans dat de style voor de printer wordt overruled door de algemene style.

Het maken van een stylesheet voor één pagina is vaak behoorlijk wat werk. Maar meestal is zo'n stylesheet voor meerdere pagina's te gebruiken, en dan valt het weer mee. Zo heb ik zelf deze stylesheet gebruikt voor alle andere pagina's met artikelen. Ook van komende artikelen is er nu gelijk een printbare versie beschikbaar.

Overigens wordt hier een van de grote voordelen van het scheiden van inhoud en opmaak zichtbaar. Had ik op de verouderde manier bijvoorbeeld overal font in de html gezet, dan had ik dat op al die plaatsen moeten aanpassen. En dat had alleen gekund door een complete tweede pagina voor het printen te maken. Nu hoef ik alleen een apart stylesheet voor printen te maken. En die is gelijk geldig voor álle pagina's, waar ik het aan koppel.

Op deze pagina zijn heel veel dingen opgenomen die te maken hebben met printen én css. De pagina heeft mede daardoor relatief veel css. En daardoor is het ook een wel heel ingewikkelde pagina geworden om af te drukken. Normaal genomen zou het (veel) simpeler moeten zijn. Als een pagina zoveel wijzigingen nodig heeft als deze, is het echt veel beter, sneller en makkelijker om een pdf te maken.

Sterker nog: het is op dit moment in geen enkel browser mogelijk deze pagina ook maar enigszins correct af te drukken. Vooral de tabel die in landschap-mode zou moeten worden afgedrukt, wordt door vrijwel alle browsers mishandeld op een manier, waar een middeleeuwse beul nog iets van zou kunnen leren.

Op een normale pagina zullen selectors vaker worden gecombineerd dan op deze pagina gebeurt, waardoor je minder css nodig hebt.

Bij het schrijven van dit artikel heb ik onder andere de volgende bronnen gebruikt:
Printing Web Documents and css
css Design: Going to Print
Een hele reeks pagina's op de site van Sitepoint.

Voorgrondkleur (color)

Op papier lezen gewone zwarte letters het makkelijkst. Bij veel printers zitten verschillende kleuren inkt in één cartridge. Als één kleur op is, moet de hele cartridge worden vervangen, dus ook de kleuren die nog (lang) niet op zijn. Zwart zit wel altijd in een aparte cartridge. Dus zowel voor de leesbaarheid als voor het inktverbruik kun je tekst het best in zwart afdrukken.

Omdat bij mij de standaard-voorgrondkleur, en dus de tekst, op de site al zwart is, hoef ik hier niets aan te veranderen in de css. De code heeft op het scherm een afwijkende kleur, maar die wil ik ook in een afwijkende kleur geprint hebben, dus daar hoef ik ook niets aan te veranderen.

Zou je denken, maar dat klopt niet. Veel mensen laten de printer standaard alleen in zwart-wit afdrukken. Daar gaan je mooie kleurtjes. Je kunt hier niets aan doen, de gebruiker bepaalt (terecht) hoe er wordt geprint. Om de code ook in zwart-wit te laten opvallen, geef ik die daarom ook nog een afwijkend lettertype.

Lettersoort (font-family)

Op het scherm leest een sans-serif letter het makkelijkst. Dat is een letter zonder schreven, zonder 'dwarsstreepjes'. Maar op papier leest juist serif, met schreven, makkelijker. Georgia is een font dat standaard op Windows, Mac en veel Linux-distributies aanwezig is. Om er voor te zorgen dat in ieder geval een letter met schreef wordt gebruikt, voegen we serif toe. Als Georgia nu mist, wordt een ander serif-font gebruikt, afhankelijk van wat er aanwezig is en/of de voorkeuren van de gebruiker. De css voor het printen wordt dan:

body {font-family: Georgia, serif;}

In de tekst staat ook code. Die is op het scherm bruin, waardoor hij goed opvalt. Maar veel mensen printen in zwart-wit, dus de kleurherkenning is niet betrouwbaar. Daarom geef ik hem, net als trouwens op het scherm, ook een ander lettertype. (Het andere lettertype op het scherm zorgt ervoor dat ook kleurenblinden de code herkennen.)

De gewone tekst op het scherm is schreefloos, en de code heeft juist wel een schreef. Bij printen heeft de gewone tekst een schreef, want dat leest prettiger. Daarom maak ik de code schreefloos. En omdat dat op papier nog wat weinig onderscheid van de gewone tekst oplevert, gebruik ik ook nog een niet-proportioneel font. Dat is een font waar de 'i' evenveel ruimte krijgt als de 'M'.

Met de fonts Lucida Console bestrijk ik Windows, met Andale Mono de Mac en de meeste Linux-distributies. Voor de zekerheid voeg ik er nog monospaced aan toe, zodat ook bij het ontbreken van deze fonts in ieder geval een niet-proportioneel font wordt gebruikt. De volledige regel wordt dan:

code {font-family: "Lucida Console", "Andale Mono", monospaced;}

(Alle code staat binnen de tag <code>.)

N N miiimmmiiimmmiiim miiimmmiiimmmiiim
Met schreef (serif) Schreefloos (sans-serif) Niet-proportioneel
(monospaced)
Proportioneel

Lettergrootte (font-size)

Als de lettergrootte wordt veranderd, heeft dat bij de meeste browsers geen enkele invloed op de grootte van wat er wordt geprint. Safari is de uitzondering. Als de gebruiker in Safari de letters vergroot, ontstaat bij printen aan de linkerkant een grote, lege ruimte over de volle hoogte van de print. De letters worden niet vergroot, maar er wordt een hoeveelheid ruimte gebruikt alsof ze wél vergroot zijn. Als de letters worden verkleind, worden ze verkleind geprint.

In- en uitzoomen heeft ook alleen bij Safari invloed, bij andere browsers niet. Bij uitzoomen (verkleinen) worden letters en dergelijke kleiner, bij inzoomen (vergroten) ontstaat weer de vreemde lege ruimte aan de linkerkant.

(Opmerking 15 april 2012: op OS X schijnt dit niet meer te spelen bij Safari. Op Windows is de vreemde lege ruimte verdwenen, maar een andere lettergrootte heeft nog wel invloed op de grootte van de letter bij printen.)

Een computerscherm wordt gemeten in pixels (px). In de breedte kunnen bijvoorbeeld 1024 px voorkomen, een veel voorkomende breedte. De grootte van de px kan iets afwijken tussen bijvoorbeeld een Mac en een pc. Maar een letter met een grootte van 12 px beslaat op alle schermen evenveel px. In alle browsers behalve Internet Explorer kan de gebruiker een in px opgegeven lettergrootte veranderen.

Omdat Internet Explorer een in px opgegeven lettergrootte niet kan veranderen, wat vervelend is voor mensen die bijvoorbeeld slecht zien, kun je de lettergrootte in de regel het best opgeven in em. 1 em was oorspronkelijk gelijk aan de breedte van de hoofdletter M. En omdat die hoofdletter groter of kleiner kan zijn, is een em een relatieve maat: hij is afhankelijk van de lettersoort. (Inmiddels klopt dat verhaal over de hoofdletter M niet meer helemaal, maar een em is nog steeds een relatieve maat.) Op een computer is 1 em ongeveer gelijk aan 16 px.

Een printer kent geen relatieve maten. Als iets eenmaal is geprint, kan het daarna niet meer worden vergroot of verkleind, behalve door ondernemende kleuters, maar daar worden pa en ma meestal niet blij van. Een eenheid als em heeft dan ook niet veel nut bij printen. En een printer kent ook geen px, dus daar schiet je ook niet zoveel mee op.

Een printer kent wel dpi, dots per inch: puntjes per inch. Maar dat zegt alleen iets over de kwaliteit van de print, het heeft niets te maken met de grootte.

Uit de drukkerij stamt de eenheid punt (point, pt). In een inch (2,54 cm) gaan 72 pt. Wat eigenaardige eenheden, maar dat komt omdat ze al heel oud zijn en nog van ver voor het metrieke stelsel stammen. Deze eenheid is wel bruikbaar voor printen, maar wordt weer vrijwel nooit gebruikt op de computer. Daar is hij ook niet echt geschikt voor.

De oplossing is, om in de algemene css gewoon em te gebruiken, en in de css voor het printen pt. Een standaardlettergrootte op een monitor is ongeveer 16 px, en dat is weer ongeveer 12 pt. Niet precies, want het zijn dus totaal verschillende systemen, maar als vuistregel kun je zeggen: 16 px = 1 em = 12 pt.

Als ik een lettergrootte voor body opgeef, heb ik een standaard-lettergrootte om de andere elementen op te baseren. Als ik bij andere elementen geen eigen lettergrootte opgeef, wordt bij printen ongeveer de normale standaardgrootte voor het element gebruikt. Een <h1> is dus, ook als ik geen lettergrootte opgeef, ook bij printen vrij groot. Op het scherm geef ik alleen lettergroottes op, als die afwijken van de standaard, en bij printen gaat dat net zo.

Overigens is het absoluut onmogelijk lettergroottes volledig te controleren. Niet alle computers hebben alle letters geïnstalleerd, papiergroottes verschillen, kantlijnen verschillen, er is verschil tussen Linux, Apple en Windows, enz., enz. Als je echt volledige controle wilt, moet je een pdf maken.

Op deze pagina heb ik voor de volgende elementen eigen maten opgegeven:

body: 110%

Ik heb op het scherm graag een iets grotere letter dan standaard. Op papier is dat voornamelijk papierverspilling, daarom verander ik dat in een normale lettergrootte. In de css voor de printer komt dan te staan: body {font-size: 12pt;}

<h1>: 1.3 em; font-weight: normal;

Voor de weergave op het scherm heb ik de letters van de <h1> kleiner gemaakt dan ze voor een <h1> eigenlijk zijn, en niet vet gemaakt. Daardoor is de titel van de pagina nu kleiner geworden dan andere kopjes. Op papier is dat geen goed idee. Voor het printen maak ik daarom de letters weer wat groter en vet met de volgende css voor het printen:

h1 {font-weight: bold; font-size: 20pt;}

h2 span:not([lang="en"]): 0.6em

Het tweede, kleinere, deel van de kopjes waarin tussen haakjes de namen van de attributen en/of elementen staan. Dit deel staat in een span binnen de <h2>. Deze namen moeten kleiner dan de rest van de kop worden weergegeven.

Binnen een enkel kopje wordt <span> echter ook gebruikt om aan te geven dat het een Engelstalig woord is, zoals bij 'header' en 'footer'. En dit moet níét kleiner worden weergegeven. Daar zorgt het laatste deel van deze selector voor.

h2 span: de spans binnen een <h2>

h2 span:not(...): binnen de haakjes staat iets dat niet zo mag zijn.

h2 span:not([...]): de teksthaken [] worden in selectors gebruikt om een voorwaarde in te sluiten. Dat :not() toevallig ook nog twee haakjes heeft, maakt niet uit: gebruiken we gewoon vrolijk teksthaken én haakjes.

h2 span:not([lang="en"]): het lang-attribuut mag niet "en" zijn. Oftewel: dit geldt voor alle spans binnen een <h2>, tenzij er lang="en" in de tag staat: <span lang="en">

Deze regel heeft dus geen invloed op het woord 'header' in <h2><span lang="en">header</span><h2>.

(Internet Explorer 8 en eerder kennen :not niet. Die negeren daarom deze regel en printen het hele hoofdstukkopje in een grote letter af.)

1 em is ongeveer 12 pt, dus 0.6 em is 0.6 x 12 = 7.2 pt, afgerond 7 pt. 7 pt vind ik op papier te klein, dus maak ik hier toch 10 pt van met de volgende css voor het printen:

h2 span:not([lang="en"]) {font-size: 10pt;}

.naar-links: 0.8em

Dit is de verwijzing boven- en onderaan het artikel naar de pagina met links, waar mogelijk meer informatie staat. Deze wordt niet geprint, want het lijkt wat overdreven om zo'n algemene verwijzing ook te printen. Zonder aanklikbare link heb je er niet zo heel veel aan. Dus hoef ik geen aangepaste lettergrootte voor het printen op te geven.

p#herzien, p.onderschrift: 0.8em

Wanneer het artikel voor het laatst is herzien en op welke browsers het betrekking heeft, en het onderschrift bij foto's en dergelijke. Dit moet wel worden geprint. 1 em is ongeveer 12 pt, dus 0.8 em is 0.8 x 12 = 9.6 pt, afgerond 10 pt. De css voor het printen wordt:

p#herzien {font-size: 10pt;}

code: 1.2em.

Binnen deze tag staat alle code. Deze moet even groot zijn als de normale tekst. Maar door de lettersoort die op Windows wordt gebruikt, is dit een iets kleinere letter. Daarom corrigeer ik dat door hem iets groter te maken. Omdat Windows het meest wordt gebruikt, richt ik me daarop met de correctie.

Op Linux worden op het scherm, althans bij mij, deze letters nu iets te groot, maar dat is nauwelijks 'n probleem.

Op het scherm heb ik de letters voor de code dus iets vergroot. Maar bij het printen wordt de voor de code gebruikte letter juist de standaardletter, en de standaardletter op het scherm wordt voor de code gebruikt. Bij het printen moet ik de letters voor de code dus juist iets verkleinen. In dit geval probeer ik het even uit en blijkt 12 pt 'n goede grootte. Grappig genoeg dus nu wel even groot als de standaardletter. De css voor het printen:

code {font-size: 12pt;}

span.schreef: 72px

De twee grote letters 'N', de voorbeelden voor schreefloos en met schreef. 16 px is ongeveer 12 pt. 72 : 16 = 4,5. Dus het aantal pt wordt 4,5 x 12 = 54. De css voor het printen:

span.schreef {font-size: 54pt;}

span.prop: 24px

De voorbeelden voor proportioneel en niet-proportioneel. 16 px is ongeveer 12 pt. 24 : 16 = 1,5. Dus het aantal pt wordt 1,5 x 12 = 18 pt. De css voor het printen:

span.prop {font-size: 18pt;}

div.onderschrift-4: 13px

De onderschriften bij de voorbeelden over schreef en proportioneel. 16 px is ongeveer 12 pt. 13 : 16 = 0,8125. Dus het aantal pt wordt 0.8125 x 12 = 9,75, afgerond 10 pt. De css voor het printen:

div.onderschrift-4 {font-size: 10pt;}

div#inhoud-art: 0.9em en div#header-i div#inhoud-art h2: 1.0 em

Deze elementen zijn onderdeel van de inhoudsopgave, die openklapt als je over 'Inhoudsopgave' hovert. Omdat alleen mensen die kunnen toveren dit bij een gewoon stuk papier voor elkaar krijgen, laten we de hele inhoudsopgave maar weg bij het printen. Ik hoef dus ook geen lettergroottes op te geven.

Regelhoogte (line-height)

Als je niets aan de regelhoogte verandert, is deze bij een lettergrootte van 1 em ongeveer 1,2 em. Vaak wordt deze voor het scherm iets groter gemaakt, omdat een scherm minder prettig leest dan papier.

De regelhoogte wordt op verschillende manieren berekend, afhankelijk van hoe je hem opgeeft. Dat zou tot bergen rekenwerk leiden, als je gaat printen. Op het scherm kun je dingen simpel uitproberen, met printen is dat wat lastiger. Bovendien verschillen browsers onderling ook nog enigszins.

Gelukkig is er een simpele oplossing. Bij alle elementen waar de regelhoogte is aangepast moet de volgende css voor het printen komen te staan:

naam-element {line-height: normal;}

Nu wordt de standaard regelhoogte van de browser gebruikt. Deze wordt berekend aan de hand van de lettergrootte waar de regel bij hoort, dus je krijgt altijd de juiste regelhoogte bij de juiste lettergrootte. Mogelijk vallen wat speciale effecten, die je op het scherm wel ziet, weg. Maar het wordt in ieder geval goed leesbaar en kost niet meer papier dan nodig is.

Afkortingen (<abbr>)

Stippellijntje toevoegen en weghalen

Bij gebruik van de tag <abbr> wordt in Opera en Firefox, als die afkorting een titel heeft, een stippellijntje onder de afkorting gezet. Als je over zo'n afkorting met titel hovert, verschijnt de titel. Daarin staat normaal genomen de afkorting voluit geschreven. Omdat ik dat graag in alle browsers zo zie, heb ik in de algemene css het volgende opgegeven:

abbr[title] {border-bottom: dotted black 1px;}

abbr[title]

De abbr is gewoon een afkorting. De toevoeging [] betekent, dat er 'n voorwaarde aan de afkorting wordt gesteld. Alleen als aan die voorwaarde wordt voldaan, is de css van toepassing. Dus eigenlijk precies hetzelfde als bij een class of id, alleen staat er geen naam van een class of id tussen de [], maar een voorwaarde.

title

Dit is de voorwaarde: de afkorting moet een title hebben. Alleen als de afkorting een titel heeft, wordt er een stippellijntje aan de onderkant van de afkorting gezet.

Dit stippellijntje heeft op papier geen nut. Met de volgende css voor het printen haal je dat lijntje weg:

abbr[title] {border: 0;}

Dit werkt ook bij Firefox en Opera, die uit zichzelf al zo'n stippellijntje onder de afkorting zetten.

Omdat het stippellijntje is neergezet met behulp van abbr[title], moet ik dat hier ook gebruiken. Als ik alleen abbr zou gebruiken, heeft dat minder specificiteit (gewicht) dan abbr[title]. De selector abbr[title] zou 'winnen' van abbr, waardoor de regel met alleen abbr niet zou werken.

Afkorting voluit printen

In alle nieuwere browsers, dus niet in Internet Explorer 7, is het mogelijk om bij het printen de uitleg van de afkorting weer te geven. Dat kan met behulp van de volgende css voor het printen:

abbr[title]:after {content: " (" attr(title) ") ";}

abbr[]

De abbr is gewoon een afkorting. De toevoeging [] betekent dat er 'n voorwaarde aan de afkorting wordt gesteld. Alleen als aan die voorwaarde wordt voldaan, is de css van toepassing. Dus eigenlijk precies hetzelfde als bij een class of id, alleen staat er geen naam van een class of id tussen de [], maar een voorwaarde.

title

Dit is de voorwaarde: de abbr moet een title hebben.

:after

Dit pseudo-element geeft aan dat er iets moet worden tussengevoegd ná het element waar het achter staat. In dit geval zijn dat dus de afkortingen die aan de voorwaarde van de selector voldoen: [title].

content: " (" attr(title) ") ";

Achter content: komt te staan wat er moet worden tussengevoegd.

De delen tussen aanhalingstekens worden letterlijk tussengevoegd, inclusief de spaties. Dus vooraan komt bij printen ( en achteraan komt ) te staan, met ervoor en erna een spatie.

attr()

Geeft aan dat daar een attribuut moet komen te staan. Tussen de haakjes komt de soort attribuut te staan: title. Dus de inhoud van title komt tussen de ( en de ) te staan. Oftewel: de verklaring van de afkorting wordt er tussen haakjes achter gezet.

Op mijn site, en ook op deze pagina, zet ik alleen de eerste keer de titel bij een afkorting. Dus alleen de eerste keer dat een afkorting voorkomt, wordt bij printen de uitleg erachter gezet, zoals het hieronder staande voorbeeld laat zien:

De VVD heeft steeds minder met Volk, Vrijheid en Democratie te maken.

De VVD heeft wel steeds meer met Elite, Onvrijheid en Schijndemocratie te maken.

html:

De <abbr title="Volkspartij voor Vrijheid en Democratie">VVD</abbr> heeft steeds minder met Volk, Vrijheid en Democratie te maken. De <abbr>VVD<abbr/> heeft wel steeds meer met Elite, Onvrijheid en Schijndemocratie te maken.

algemene css:

abbr[title] {border-bottom: dotted black 1px}

Dit zorgt voor de stippellijn onder de eerste afkorting.

css voor het printen:

abbr[title] {border: 0;} abbr[title]:after {content: " (" attr(title) ") ";}

De bovenste regel verwijdert bij het printen de stippellijn. De tweede regel zorgt ervoor dat, als de afkorting een titel heeft, deze tussen haakjes achter de afkorting wordt gezet. Dit is het geval in de eerste html-regel, dus wordt daar achter VVD toegevoegd: (Volkspartij voor Vrijheid en Democratie).

css-pop-ups (:hover en :focus)

Je kunt met behulp van :hover of :focus een pop-up boven een link of ander element laten verschijnen. Maar dit wordt niet afgedrukt, het verdwijnt gewoon. Net als op het scherm geldt: binnen een pop-up mag geen belangrijke informatie staan.

Achtergrond (background)

Op het wel of niet afdrukken van een achtergrond heb je nauwelijks of geen invloed. Dat geldt voor zowel achtergrondkleuren als achtergrond-afbeeldingen. Verschillende printers en verschillende browsers laten gebruikers dit zelf instellen. Meestal staat dit standaard uit.

Omdat hoogstwaarschijnlijk achtergronden niet worden geprint, moet je daar vanuit gaan. Als het goed is staat onmisbare informatie ook niet in achtergrondkleuren of achtergrond-afbeeldingen, maar in gewone afbeeldingen. (En ook dat is eigenlijk niet echt veilig, onmisbare info hoort, als het enigszins kan, in tekst te staan.)

Je leest nogal eens dat het toevoegen van !important aan de css voor de achtergrond ervoor zorgt, dat de achtergrond toch wordt afgedrukt. Bij mij is dat in geen enkele browser gelukt, dus ik denk dat dit niet klopt. Mogelijk werd dit vroeger door de browser geregeld met een standaard stylesheet. Die kun je inderdaad overrulen. Maar tegenwoordig kan dat kennelijk niet meer. Maakt trouwens weinig uit, want ook veel printerprogramma's geven de mogelijkheid de achtergronden niet af te drukken, en daar heb je hoe dan ook geen invloed op.

Dat achtergronden normaal genomen niet worden geprint, heeft goede redenen. Als het goed is, staat er geen belangrijke info in, maar wordt een achtergrond alleen gebruikt om de boel op te leuken. Een grote achtergrond-afbeelding of -kleur vreet inkt. Het maakt op papier de tekst bepaald ook niet leesbaarder. Dus kan een achtergrond beter niet worden geprint.

Omdat je dus toch niets hebt aan de achtergrond, haal ik deze voor de zekerheid helemaal weg. Als iemand dan toch achtergronden mee print, wordt geen halve cartridge verspild aan een grijze achtergrond, die de tekst ook nog 'ns vrijwel onleesbaar maakt. Ik zou tekst alleen op deze manier onleesbaar maken, als je aandelen in een cartridge-fabriek én een glasverzekering hebt.

In dit artikel worden op diverse plaatsen achtergrondkleuren gebruikt. Een witte achtergrondkleur is om voor de hand liggende redenen geen probleem: wit wordt niet geprint. De achtergrondkleuren in de header zijn ook geen probleem, want de hele header wordt niet geprint. Alleen de achtergrondkleur van de body zou een probleem kunnen zijn. Om dat te voorkomen voeg ik aan de css toe:

body {background: none;}

Afbeeldingen (<img>)

Aan het gebruik van afbeeldingen bij printen zitten nogal wat haken en ogen. Sommige printers en/of browsers geven de mogelijkheid om afbeeldingen niet af te drukken om inkt en papier te sparen. Ook kan worden geprint in zwart-wit, waardoor een kleurenafbeelding natuurlijk totaal kan veranderen. Om deze redenen zijn afbeeldingen volstrekt onbetrouwbaar als belangrijke bron van informatie.

Daarnaast is de kwaliteit van geprinte afbeeldingen vaak erbarmelijk. Vlakken en lijnen worden soms nog wel goed geprint, maar bijvoorbeeld foto's absoluut niet.

Op een monitor is een afbeelding nog uitstekend bij gebruik van een relatief klein bestand met weinig informatie. Maar een printer heeft minimaal 600 dpi nodig om een enigszins fatsoenlijke afbeelding te kunnen printen, en eigenlijk nog meer. Dat kan wel, maar een bestand met voldoende dpi voor de printer wordt heel erg groot. Veel te groot voor 'n normale site, want die gaat daardoor erg traag laden. Een goede kwaliteit afbeelding vreet ook nog inkt.

Als je afbeeldingen in goede kwaliteit wilt kunnen printen, is het beter de bezoeker de mogelijkheid te geven daar expliciet voor te kiezen. Als een bezoeker bijvoorbeeld graag een acceptabele print van een schilderij wil hebben, dan zal die bezoeker het ook geen probleem vinden als het downloaden daarvan langer duurt en als die afbeelding (veel) meer inkt kost.

Daarnaast kun je ook nog overwegen om zoveel mogelijk niet-essentiële afbeeldingen te verwijderen bij printen. Als het toch niet mooi wordt en veel inkt kost, waarom zou je het dan afdrukken?

Het verschil tussen de hieronder staande afbeeldingen is alleen te zien als daadwerkelijk in een goede kwaliteit op papier wordt afgedrukt. Door het verschil in weergave op een monitor en op papier zie je geen verschil in een afdrukvoorbeeld, omdat deze ook op het scherm staat. In een pdf zie je misschien wel, misschien geen verschil, afhankelijk van hoe de pdf is gemaakt.

Geschikt om te printen, 76,3 kB groot Niet geschikt om te printen, 17,3 kB groot

(Als je jezelf toevallig herkent op deze foto, genomen op 30 april 2010 in het Vondelpark in Amsterdam, stuur dan even een mail naar info@css-voorbeelden.nl, als je het origineel wilt hebben.)

Bij bovenstaande kleine afbeeldingen is bij printen in goede kwaliteit een duidelijk verschil te zien. De linkerafbeelding is redelijk scherp, maar het bestand is 76,3 kB groot. De rechterafbeelding is duidelijk slechter van kwaliteit bij printen, maar is slechts 17,3 kB groot, meer dan vier keer zo klein. Op het scherm zien beide er goed uit.

En dit zijn dan nog tamelijk kleine afbeeldingen. Bij grotere afbeeldingen of bij veel afbeeldingen op 'n pagina wordt het verschil in hoeveelheid te downloaden gegevens enorm. En voor een echt goede afdruk is ook de linkerafbeelding eigenlijk niet goed genoeg.

Als je inzoomt op de foto's op het scherm, ga je op het scherm trouwens ook verschil in kwaliteit zien, als je maar genoeg vergroot.

Als je een hoogte en/of breedte hebt opgegeven bij de afbeelding, wordt die ook gebruikt door de printer. Dat zou niets moeten uitmaken, omdat de hoogte en breedte de échte hoogte en breedte van de afbeelding in px horen te zijn.

Vergroten en verkleinen van afbeeldingen in een browser is een bijzonder slecht idee, omdat een browser daar veel minder goed in is dan een gespecialiseerd grafisch programma. Vergroten levert eigenlijk altijd slechte resultaten op, verkleinen kán goed uitpakken, als je geluk hebt, maar dan is hoe dan ook het bestand te groot. Een groot bestand downloaden en dan in de browser de afbeelding verkleinen is niet erg efficiënt.

Doorzichtigheid (opacity, rgba)

Doorzichtige kleuren en dergelijke afdrukken is op dit moment in de praktijk onmogelijk.

De resultaten van het afdrukken van doorzichtige kleuren en dergelijke zijn nogal wisselend, voorzichtig uitgedrukt. Doorzichtigheid wordt vaak gebruikt in combinatie met achtergrond-afbeeldingen of -kleuren. Als die niet worden afgedrukt, heb je er dus hoe dan ook al niets aan. Daarnaast gaan verschillende printers er nogal verschillend mee om.

Ik heb nog even overwogen om hier afbeeldingen toe te voegen, maar eigenlijk is dat zinloos. Behalve in Firefox is het afdrukken van doorzichtige elementen momenteel gewoon niet goed mogelijk.

De door mij gebruikte testbestanden zijn te vinden op www.css-voorbeelden.nl/tekst-effecten. Als je die print, zie je precies wat ik bedoel.

Zichtbaarheid (visibility)

Elementen met visibility: hidden; worden niet getoond op het scherm of bij afdrukken. Maar hoewel je ze niet ziet, zijn ze er eigenlijk wel: ze nemen gewoon ruimte in. Dat is anders dan bij display: none;, waarbij ze ook geen ruimte innemen en echt daadwerkelijk afwezig zijn.

Als 'n element problemen zou kunnen opleveren bij het printen, maar het moet eigenlijk aanwezig blijven vanwege de lay-out of zo, kun je dus visibility: hidden; gebruiken om afdrukken te voorkomen. Voor de lay-out blijft het gewoon aanwezig, ook al zie je het niet.

Dit zal vaak wel 'n leeg stuk papier opleveren, dus echt milieuvriendelijk is dit niet.

Elementen niet printen (display: none;)

Op het scherm staat een hele serie elementen die geen enkel nut hebben voor een afdruk. En niet alleen dat ze op papier geen enkel nut hebben: ze kosten wel papier en inkt. Je maakt je dus niet populair als je die af laat drukken.

Skip-link niet printen

Helemaal bovenaan de pagina staat een link om in één keer de inhoudsopgave en dergelijke te kunnen passeren. Deze link heeft op papier geen enkel nut: hij werkt niet en er staat op papier ook helemaal geen inhoudsopgave.

Normaal genomen is deze link niet te zien, omdat hij ver links buiten het scherm staat. Alleen als hij focus heeft is hij te zien. Bij het printen wordt deze link helemaal weggehaald met de volgende css:

a#skippy {display: none;}

Header niet printen

Bovenaan het venster van de browser staat een header met daarin onder andere twee witte rechthoeken met daarin links. Los van dat deze blokken geen enkel nut hebben op een afdruk, geeft de header nog veel meer problemen bij afdrukken. Dat komt omdat hij een fixed positie heeft. Bij position: fixed; wordt dat verder uitgelegd.

Het simpelst is om gewoon de hele header niet af te drukken. Daarmee onderdruk ik ook gelijk de inhoudsopgave. Op het scherm klapt die netjes uit als je eroverheen hovert, op papier is de kans dat de inhoudsopgave spontaan openvliegt vrij klein. Weg ermee dus. Omdat de hele header binnen div#header staat, kan dat met wat simpele css voor het printen:

div#header {display: none;}

Verhaal over geprinte versie niet printen

Bovenaan de pagina staat binnen een kadertje, hoe je aan een geprinte versie kunt komen. Maar als je de geprinte versie al bekijkt, mogen we aannemen dat dat is gelukt en is het weinig zinvol bovenaan 'n halve pagina vol te kalken hoe je aan 'n geprinte versie kunt komen. Dus dat verhaal halen we weg, scheelt weer 'n halve pagina papier.

Maar de bovenste alinea over het lezen van omkaderde tekst moet wel blijven staan. Dus ik kan niet zonder meer deze hele tekst weghalen. Daarom geef ik de paragrafen en de lijst waarin de teksten staan, die niet moeten worden geprint, een class="niet-printen". Dan wordt de css voor het printen:

.niet-printen {display: none;}

En omdat ik aan de bovenste paragraaf die class niet meegeef, wordt die wel afgedrukt.

Verwijzing naar pagina met links niet printen

Boven- en onderaan het artikel staat een verwijzing naar de pagina met links, waar mogelijk meer info is te vinden. Die heeft op papier weinig nut, dus die laten we ook weg. Deze verwijzingen staan in elementen met class="naar-links". Met behulp van de volgende css voor printen worden ze onderdrukt:

.naar-links {display: none;}

Afbeelding War Child niet printen

Onderaan de pagina staat een logo van War Child, waar een link naar hun site onder zit. Die afbeelding vervang ik bij het printen door een link, zoals beschreven bij Apart geval. Zo'n zwart vlak vreet inkt en op papier is dit logo ook niet echt fraai, zeker niet als in zwart-wit wordt geprint.

De hele alinea over War Child zit in een paragraaf met id="warchild-art". Het printen van de afbeelding kun je voorkomen met de volgende css voor printen:

p#warchild-art img {display: none;}

Elementen wel printen, niet op scherm

Op dezelfde manier als waarop je elementen kunt laten zien op het scherm, maar verbergen bij het afdrukken, kun je ook het omgekeerde doen. Als je deze pagina afdrukt, staat bovenaan de afdruk in een letter voor slechtzienden het adres van de site.

De html:

<p class="printkop">www.css-voorbeelden.nl</p>

In de algemene css voorkomt de volgende regel dat dit zichtbaar is op het scherm:

.printkop {display: none;}

In de css voor het printen staat het volgende:

.printkop {display: block; margin-bottom: 30px; font-size: 40pt; text-align: center;}

De display: block; zorgt ervoor dat de tekst nu wel zichtbaar wordt, oftewel: afgedrukt. De andere css is alleen om te zorgen dat de kop er wat netjes uit komt te zien. De maat van de letters wordt weer in pt opgegeven, de beste maat voor printen.

Op dezelfde manier kun je natuurlijk ook logo's, afbeeldingen, je pincode, noem maar op, printen. Alleen geldt ook hier weer, dat je nooit zeker weet of er wel in kleur wordt geprint en of afbeeldingen wel worden geprint.

Headers en footers

Veel browsers en/of printerprogramma's kunnen een header en/of footer toevoegen met dingen als datum, paginanummer en titel. Maar op deze dingen heb je geen invloed op, ze worden door de gebruiker ingesteld.

Het automatisch toevoegen vanaf de site van headers en/of footers aan een te printen pagina, is op dit moment nog niet mogelijk. De ontwerpspecificatie voor css3 biedt hier een aantal mogelijkheden voor, zoals het invoegen van paginanummers. Maar op dit moment is dit soort dingen nog in geen enkele browser geïmplementeerd.

Als je een header en/of footer wilt toevoegen aan elke pagina, moet je dit met de hand coderen. En dat wordt heel moeilijk, omdat je nooit helemaal zeker weet waar een nieuwe pagina begint. page-break-before en page-break-after werken op z'n zachtst gezegd niet helemaal betrouwbaar, áls de browser ze al kent. Nog los van het risico op enorme papierverspilling door grote lege stukken.

Als je aan elke pagina een header en/of footer wilt toevoegen, is de enige reële mogelijkheid een pdf. LibreOffice bijvoorbeeld biedt de mogelijkheid een pdf te maken met headers en/of footers, inclusief dingen als automatische paginanummers.

position: fixed;

Het gebruik van position: fixed; bij printen kan tot de wildste problemen leiden, waaronder het verdwijnen van tekst en dergelijke.

Een fixed positie wordt gebruikt om elementen op het scherm altijd op dezelfde plaats te laten staan, ook als wordt gescrold.

Bij mijn weten is de enige algemeen gangbare soort papier die gescrold kan worden wc-papier, en de kans dat daarop wordt geprint, lijkt me eigenlijk vrij klein. Een fixed positie heeft dus geen enkel nut bij een afdruk, maar zorgt wel voor problemen. Op deze pagina zijn de header, met daarin de witte blokken met links en de inhoudsopgave, en de titel van de pagina gefixeerd. Dat levert de volgende problemen op bij afdrukken:

Internet Explorer 7 is de enige printer die het doet, zoals het tot voor kort in de specificatie stond. Inmiddels heeft de specificatie het kennelijk opgegeven en zegt, vrij vertaald: zie maar wat je ermee doet. Overigens is deze specificatie (paged media) nog hevig in ontwikkeling en verandert dus regelmatig.

Ook als het niet om een header bovenaan het venster van de browser gaat, maar om een element dat ergens anders fixed is gepositioneerd, doen zich dit soort problemen voor. Je moet dus bij afdrukken alle fixed posities verwijderen of veranderen.

Op deze pagina heeft de header een fixed positie. Binnen die header zitten alleen de twee witte blokken met links en de inhoudsopgave die opent als je eroverheen hovert. Deze elementen hebben geen enkel nut in een afdruk, dus druk ik ze gewoon niet af. De hele header staat binnen div#header, dus met deze simpele css voor het printen los ik het fixed probleem voor de header op:

div#header {display: none;}

Naast de header heeft op deze pagina ook de <h1> met de titel van de pagina een fixed positie. Die zorgt dus ook voor problemen. Maar ik wil de titel ook op papier wel graag zien, dus gewoon weglaten is hier geen oplossing. Het enige wat ik in dit geval hoef te doen is de fixed position in de standaard static te veranderen met behulp van de volgende css voor het printen:

h1 {position: static;}

De top, right en left uit de algemene css kan ik gewoon laten staan, want die hebben geen invloed bij een static position.

position: absolute; en position: relative;

Het gebruik van position: absolute; bij printen kan tot de wildste problemen leiden, waaronder het verdwijnen van tekst en dergelijke.
(Aanvulling 15 april 2012: de specificatie (paged media) verandert nog voortdurend. Inmiddels wordt over relatief en absoluut gepositioneerde elementen gezegd, dat deze op 'onhandige' plaatsen kunnen komen te staan, en eventueel zelfs buiten het papier. Dus niet worden geprint. Kortom: gewoon niet gebruiken!)

Absoluut gepositioneerde elementen

Absoluut gepositioneerde elementen geven ook problemen bij printen, maar minder groot dan fixed elementen. Hoewel: als je echt pech hebt, worden ze gewoon niet geprint.

Een absoluut gepositioneerd element wordt gepositioneerd ten opzichte van de eerste ouder die zelf een fixed, absolute of relatieve positie heeft. Als die er niet is, wordt gepositioneerd ten opzichte van het venster van de browser.

Een printer heeft natuurlijk geen venster, dus moet hier worden gepositioneerd ten opzichte van de pagina. En daardoor is het dus gelijk een beetje een gok waar het absoluut gepositioneerde element precies wordt neergezet. Als ik in dit artikel redelijk bovenin een absoluut gepositioneerde div op 300 px vanaf rechts neerzet, wordt die door verschillende browsers op verschillende afstand van de linkerkant neergezet. Hetzelfde geldt voor de afstand vanaf de bovenkant.

Dit heeft allerlei oorzaken. px zijn eigenlijk niet geschikt om een afdruk mee te maken, dus de afstand moet worden omgerekend. Dat levert verschillen tussen browsers en systemen op. De specificatie is niet echt duidelijk. Is de rand van de afdruk de rand van het papier, of is het de rand van de tekst? Enz.

Als ik de hele pagina relatief positioneer, zodat de absoluut gepositioneerde div een houvast heeft, maakt dat weinig uit. Ik verplaats dan alleen het probleem van de absoluut gepositioneerde div naar z'n relatief gepositioneerde ouder. Bovendien zet Internet Explorer 8 nu de absoluut gepositioneerde div om duistere redenen op de tweede pagina.

Veel ernstiger nog wordt het als het absoluut gepositioneerde element niet op het papier past. De specificatie van css 2.1, en ook die van css3, zegt hier over, vrij vertaald: probeer er maar het beste van te maken, en als het niet lukt, laat je het maar gewoon weg.

Op deze site staat een aantal voorbeelden met pop-ups. Als je ergens overheen hovert, verschijnt een pop-up. Die pop-up is vaak gewoon al aanwezig, al zie je hem niet. Tot hij tevoorschijn moet komen, staat hij met behulp van position: absolute; ergens buiten het venster van de browser geparkeerd. Als hij dan moet verschijnen, hoef ik hem alleen maar binnen het venster te plaatsen. Bij printen worden deze pop-ups niet weergegeven, hoewel ze wel 'zichtbaar' zijn. Ze vallen weg omdat ze een absolute positie buiten het venster van de browser hebben.

Kortom: ook absoluut gepositioneerde elementen moet je niet printen of je moet de absolute positie in de normale position: static; veranderen. Als de exacte plaats echt heel belangrijk is voor de lay-out, moet je 'n papieren afdruk maken en die opsturen, of je moet een pdf maken. Dan heb je min of meer absolute controle over het eindresultaat.

Voor kleinere absoluut gepositioneerde elementen bestaat wel een oplossing, die kun je hieronder lezen.

Relatief gepositioneerde elementen

Zie de aanvulling in het rode kadertje hierboven!

Omdat een relatief gepositioneerd element wordt verplaatst ten opzichte van zichzelf, levert dit geen problemen op. Alleen geldt ook hier weer dat je, anders dan op het scherm, geen controle tot op 'n tiende millimeter hebt.

Absoluut gepositioneerd binnen relatief gepositioneerd

Zie de aanvulling in het rode kadertje hierboven!

Kleinere elementen kunnen wel absoluut gepositioneerd worden, als ze maar binnen een relatief gepositioneerd element staan. Een relatief gepositioneerd element staat, anders dan bij fixed of absoluut gepositioneerd, gewoon binnen de normale lay-out van de pagina. Daarom is de kans groter dat dit bij printen geen problemen oplevert. Let wel: kans.

Elementen die absoluut zijn gepositioneerd binnen een relatief gepositioneerd element, worden gepositioneerd ten opzichte van het relatief gepositioneerde element. Zo kun je bijvoorbeeld vier afbeeldingen absoluut positioneren binnen een relatief gepositioneerde div.

Omdat die div gewoon 'normaal' wordt geprint, zijn er geen problemen met de plaats van die div binnen de afdruk (hoewel die plaats dus nooit tot op de px precies bekend zal zijn). En omdat die div gewoon goed wordt geprint, zullen ook de vier afbeeldingen daarbinnen goed komen te staan.

Dit gaat alleen maar goed als je zeker weet dat de relatief gepositioneerde ouder op één pagina komt te staan en niet wordt verdeeld over meerdere pagina's. En eigenlijk weet je dat nooit helemaal zeker. page-break-inside, dat een nieuwe pagina binnen de div zou moeten kunnen voorkomen, werkt in de regel niet of niet goed.

Als de relatief gepositioneerde ouder te hoog is voor één pagina, zullen ook de daarin staande absolute elementen niet op één pagina passen. En de specificatie zegt bij absolute elementen die niet op de pagina passen, in vrije vertaling: probeer er maar het beste van te maken en als 't niet lukt, laat je het gewoon maar weg.

Een relatief gepositioneerde div met daarin absoluut gepositioneerde elementen, die niet volledig op één pagina past, geeft de volgende resultaten:

Als de relatief gepositioneerde ouder te breed is, zijn de verschillende browsers ook weer heel creatief:

Het zal duidelijk zijn dat deze methode alleen geschikt is voor kleine elementen, waarvan zeker is dat die in z'n geheel op één pagina komen te staan en niet te breed zijn. En aangezien je dat eigenlijk nooit helemaal zeker weet...

Ik zag ook ergens op internet de briljante tip alles in divs te zetten. Elke div maak je dan even hoog als een pagina. De divs relatief positioneren en hoppa: ik kan gewoon alles absoluut positioneren ten opzichte van de paginagrote div. Als je dat dan nog combineert met een opdracht voor een nieuwe pagina na die div...

Ik zou dit alleen doen als je een goede levensverzekering hebt en serieus mee wilt doen aan de wedstrijd voor minst populaire webmaster.

Anders dan bij drukwerk heb je geen volledige controle over een afdruk, en als de bezoeker 'n iets grotere letter of 'n iets korter papier gebruikt, past het woordje 'het' misschien net niet meer op de pagina. Waardoor je dus 'n volledig lege pagina krijgt met alleen het woordje 'het' aan de bovenkant.

float

In alle browsers is er een grotere of kleinere kans dat tekst en dergelijke verdwijnt.
Wat hier over float staat, heb ik niet opnieuw getest bij het herschrijven van dit artikel. Dit stukje tekst dateert dus uit 29 juli 2010. Gezien het grote aantal problemen met floats is testen zinloos: gewoon niet gebruiken bij printen. Zelfs als nieuwere versies van browsers een aantal problemen zouden hebben opgelost,

Op internet zijn zoveel problemen te vinden over het printen van floats, dat ik zelf nooit een float zou gebruiken in een te printen pagina. Die problemen hebben vrijwel allemaal te maken met het verdwijnen van inhoud. Mogelijk gaat het dan om exotische combinaties van css of zo, maar je zal maar net die pech hebben.

Alle problemen kunnen worden opgelost door bij het printen de standaardwaarde float: none; te gebruiken. Maar dat verandert vaak wel de hele lay-out, omdat nu elementen die naast elkaar stonden soms onder elkaar zullen komen te staan.

Floats die verticaal binnen één pagina vallen.

Floats die niet hoger zijn dan een pagina en die ook niet op de grens van twee pagina's staan (en daar heb je nauwelijks controle over!) leveren relatief weinig problemen op. Met de nadruk op relatief. Als bij de handleiding voor een noodstop van een locomotief de laatste regel wegvalt, is dat in procenten misschien heel weinig tekst. Maar als nou net daar staat welke knop de noodrem is...

Ik wil maar zeggen: ook als er maar weinig verdwijnt, kan dat natuurlijk heel vervelend zijn.

Ik heb de diverse browsers getest met een aantal pagina's van mijn eigen site, waarop floats staan. Omdat ik die pagina's goed ken, werkte dat het beste. Naast de hieronder genoemde problemen veranderden alle browsers regelmatig op kleinere punten de lay-out.

In alle gevallen kun je alles zichtbaar maken door in de css voor het printen de standaardwaarde float: none; te geven aan gefloate elementen.

Floats op de grens tussen twee pagina's

Als een float toevallig over twee pagina's wordt verdeeld, omdat hij niet op één pagina past, gaat dat in de meeste browsers goed. Maar bij Opera wordt soms een deel twee keer afgedrukt, en soms valt er inhoud weg. Bij Internet Explorer 7 valt soms inhoud weg.

Floats die te hoog zijn voor één pagina

Als een float te hoog is voor 'n vel papier, komt hij altijd op meerdere vellen te staan. Zoiets kan bijvoorbeeld gebeuren als je met kolommen werkt. Op het scherm maakt de hoogte niets uit, want dan kun je scrollen, maar op papier móéten er dan dus nieuwe pagina's worden gemaakt.

Bij alle browsers werd alle inhoud weergegeven. Dat is wel 'ns anders geweest in het verleden. Maar wel werd bijvoorbeeld een footer soms tússen de rechter- en linkerkolom gezet in plaats van eronder.

Deze pagina

Op deze pagina zijn alleen de twee foto's gefloat: een naar links en een naar rechts. Dat gaat in alle browsers goed, behalve in Internet Explorer 8 (maar het kan evengoed een andere browser kunnen zijn, die problemen geeft). In Internet Explorer 8 worden de foto's onder elkaar gezet. Dat is niet zo erg, maar er verdwijnt een deel van de tekst. Kennelijk komt dat onder de foto's te staan.

Met de volgende css voor het printen voorkom ik dit:

img.links, img.rechts {float: none;}

Omdat de foto's inline-elementen zijn (<img>), komen ze nog steeds naast elkaar te staan, maar nu tegen elkaar aan. Als ze niet op dezelfde regel passen, komen ze onder elkaar te staan. Dat spoort niet helemaal met de tekst, maar het is beter dan dat er tekst verdwijnt.

Eventueel zou je bij het printen aan de linkerkant van de rechterfoto nog een marge kunnen toevoegen. Maar dat maakt de kans groter dat ze niet meer op dezelfde regel passen en onder elkaar komen te staan in plaats van naast elkaar.

Kolommen met tekst (column-width, column-gap, column-count)

In Opera kunnen stukken tekst wegvallen als je in kolommen print.

Dit stuk tekst wordt met behulp van css3 over drie kolommen verdeeld. Dat wil zeggen: als je Google Chrome, Opera, Safari of Firefox gebruikt. Andere browsers negeren dit, omdat ze het (nog) niet kennen.

Kolommen met behulp van position en dergelijke

Soms wordt tekst in kolommen naast elkaar gezet. Je kunt dan het hele venster van de browser gebruiken, zonder dat de regels zo lang worden dat ze niet meer prettig lezen. Deze kolommen worden vaak gemaakt met behulp van eigenschappen als float, position, margin en padding.

Hoewel css3 speciale eigenschappen heeft voor kolommen, werken die niet in Internet Explorer. Anders zou je dit soort ingewikkelde constructies niet meer hoeven te gebruiken.

Bij dit soort nepkolommen moet de tekst met de hand worden verdeeld over de kolommen. Als je aan de eerste kolom tekst toevoegt, wordt die eerste kolom langer. De tekst wordt niet automatisch opnieuw over de kolommen verdeeld. Bij afdrukken kan dat fabelachtig mis gaan, afhankelijk van de eigenschappen die je hebt gebruikt. position en float zijn eigenlijk niet geschikt om af te drukken, dus de kolommen komen onder elkaar staan. En worden dan dus mogelijk veel en veel te smal.

Als je op deze manier handmatig kolommen hebt gemaakt, moet je er dus goed voor zorgen dat het bij het afdrukken gewone normale tekst onder elkaar wordt. Bij smalle kolommen moet je vooral niet vergeten de breedte aan te passen, zodat je bij printen niet alleen een smalle kolom met heel veel wit papier krijgt.

Kolommen met behulp van css3

css3 kent speciale eigenschappen voor kolommen. De belangrijkste daarvan zijn column-width, column-count en column-gap.

column-count geeft het aantal kolommen naast elkaar aan. De breedte wordt dan automatisch berekend. Je kunt ook de breedte van de kolommen aangeven met column-width, waarna het aantal kolommen automatisch wordt berekend. column-gap geeft de ruimte tussen de kolommen aan.

In tegenstelling tot wanneer je de kolommen met de hand indeelt, loopt hier de tekst automatisch door van de ene kolom in de andere. Als je aan de eerste kolom iets toevoegt, wordt de tekst automatisch weer opnieuw over de kolommen verdeeld, zodat deze even hoog blijven.

Op het scherm zijn de kolommen even lang als de hele pagina (of als een deel van de pagina, zoals in dit artikel het geval is). Je moet dus eerst de hele linkerkolom lezen, daarna de tweede van links, enz. Bij afdrukken is het de bedoeling dat de kolommen even lang worden als de pagina, zodat je gewoon pagina na pagina kunt lezen.

Firefox, Google Chrome, Safari en Opera herkennen deze eigenschappen. Maar omdat css3 nog geen officiële specificatie is, zitten ze in sommige browsers nog in het experimentele stadium. In Google Chrome en Safari worden ze daarom voorafgegaan door -webkit- en in Firefox door -moz-: -webkit-column-width, -moz-column-width, -webkit-column-count, -moz-column-count, -webkit-column-gap en -moz-column-gap.

Zodra ze uit het experimentele stadium zijn, wordt -webkit- of -moz- verwijderd. In de css heb ik ook al de eigenschappen zonder -webkit- en -moz- neergezet, zodat de kolommen ook blijven werken als de experimentele vorm in de definitieve verandert. En Opera herkent deze officiële vorm nu al.

Browsers die deze eigenschappen niet kennen, negeren ze gewoon. De tekst wordt in Firefox, Google Chrome, Safari en Opera in kolommen weergegeven en in andere browsers gewoon over de volle breedte.

Bij het afdrukken verwijderen Google Chrome en Safari de kolommen. De tekst wordt dus gewoon over de volle breedte afgedrukt. Firefox print de tekst in kolommen, waarbij de tekst onderaan de pagina bovenaan de volgende kolom verder gaat, net zolang tot de hele pagina is gevuld.

Voor zover ik kon zien leveren kolommen, behalve in Opera, geen enkel probleem op bij het afdrukken. Althans: niet meer dan op het scherm. Een te brede afbeelding zal niet in de kolom passen, dat soort dingen. css3 heeft ook voor dat soort problemen eigenschappen, maar die zijn in nog geen enkele browser geïmplementeerd. In Opera kunnen stukken van de tekst wegvallen, als het stuk met kolommen niet op één pagina past. Het lijkt erop dat de tekst gewoon doorloopt tussen de pagina's, maar uiteraard niet wordt afgedrukt.

Er doet zich wel een eigenaardig probleem voor bij de weergave op het scherm. In Firefox, Google Chrome, Opera en Safari, dus in alle browsers die deze eigenschappen herkennen, verdwijnt de marge tussen de kolommen en de daarboven staande tekst. Opera en Safari laten wel een marge staan boven het hoofdstukje, maar niet boven de kolommen met gewone tekst daarnaast. Terwijl het afdrukken dus wel goed gaat. Vreemd.

Ik heb dit opgelost door bovenaan de div met de tekst over de kolommen een extra padding aan te brengen. Maar dat levert bij Internet Explorer 7, 8 en 9 weer een te grote ruimte op boven het kopje over de kolommen. Daarom haal ik bij die kop de marge aan de bovenkant weg. Nu staat het in alle browsers én bij het printen min of meer goed.

De eigenschappen voor kolommen die beginnen met -webkit- en -moz- zijn geen van alle geldige css, dus je css valideert niet. Omdat de reden hiervan bekend is, lijkt me dat in dit geval geen probleem.

z-index

De z-index heeft geen invloed bij afdrukken. Dat wil zeggen: het werkt hetzelfde als op het scherm.

Marges (margin)

Op het scherm kunnen marges zonder enig probleem eindeloos (nou ja, eindeloos...) worden gebruikt. Bij papier ligt dat anders. Op het scherm kun je tekst prima 8 cm breed maken, op papier leidt dat tot een gigantische papierverspilling.

De meeste browsers en/of printerprogramma's laten de gebruiker bij het printen een marge aan de buitenkant van het papier instellen. Op deze marges heb je geen enkele invloed. Je hebt wel invloed op de marges die binnen de pagina worden gebruikt.

Op deze pagina worden nogal wat marges gebruikt. Bij al die marges moet in principe worden gecontroleerd, of ze wel zinvol zijn bij afdrukken. Gelukkig valt een groot deel gelijk af, bijvoorbeeld alle marges binnen de header, omdat de hele header gewoon niet wordt afgedrukt.

Een tweede groep marges wordt gebruikt om dingen echt op de juiste plaats te zetten. Dat soort marges blijft meestal gewoon staan. Alleen als bijvoorbeeld kolommen naast elkaar worden gezet met behulp van een heel brede marge, moet je zoiets mogelijk weghalen. Als de kolommen bij het printen ónder elkaar komen te staan, is de brede marge alleen maar papierverspilling.

De marges die echt bekeken moeten worden, zijn wat ik noem de standaardmarges. Onder elke <p> staat op het scherm een marge van 8 px, bijvoorbeeld. Dat maakt het op het scherm een stuk leesbaarder, maar op papier is het niet echt nodig, en het vreet papier. Van zichzelf heeft een <p> ook een marge aan de bovenkant, maar die heb ik weggehaald. In de algemene css geef ik deze marges aan een paragraaf:

p {margin: 0; margin-bottom: 8px;}

Alle marges, dus ook die aan de bovenkant, worden weggehaald. Aan de onderkant komt een marge van 8 px. In de css voor het printen hoef ik dus alleen de marge aan de onderkant weg te halen:

p {margin-bottom: 0;}

Alleen dit scheelt al ongeveer 15% in de lengte van de tekst, en dus in het aantal vellen papier. Enige nadeel is dat op 'n enkele plaats toch 'n marge zou horen te staan. Dat zou je met de hand kunnen nalopen en daar dan invoegen in de css voor het printen, maar als het zo precies moet, is een pdf echt beter en sneller.

div.anker {padding-top: 4.8em; margin-top: -4.8em;}

Deze eigenaardige constructie is nodig om ankers (links binnen de pagina) te kunnen maken. Dat komt omdat de header een fixed positie heeft.

Zonder deze constructie komt een anker op de verkeerde plaats op het scherm te staan. Op papier heeft dit geen enkel nut. Alle browsers hebben bij het afdrukken wat problemen met deze constructie. Als hij toevallig bovenaan een pagina komt te staan, wordt regelmatig een extra grote marge aan de bovenkant neergezet. Dus haal ik hem weg met de volgende css voor het printen:

div.anker {padding-top: 0; margin-top: 0;}

padding

Padding binnen de pagina kan meestal gewoon blijven staan, anders zouden veel lege ruimtes verdwijnen en bijvoorbeeld teksten tegen elkaar aan komen te staan. Alleen als bijvoorbeeld kolommen op hun plaats zijn gezet met een heel brede padding, moet die mogelijk worden weggehaald. Als de kolommen bij het printen ónder elkaar komen te staan, is een heel brede padding alleen papierverspilling.

Padding aan de buitenkant van de pagina is een ander verhaal. De printer geeft bij het printen al een marge, dus padding aan de buitenkant is dubbelop en kost alleen maar papier.

Deze hele pagina staat in een div met id="uitleg-content". Die heeft onder andere de volgende css:

div#uitleg-content {padding: 5.8em 10px 30px 10px;}

De grote padding aan de bovenkant heeft te maken met de fixed header. Die header wordt helemaal niet afgedrukt, dus die grote opening aan de bovenkant is al helemaal papierverspilling. Maar ook de padding links en rechts is overbodig. Zo'n padding links en rechts over de lengte van dit artikel scheelt zo 'n hele pagina. Daarom komt bij de css voor het printen te staan:

div#uitleg-content {padding: 0;}

Breedte (width)

Als de inhoud te breed is voor een element, zal op het scherm meestal een horizontale scrollbalk verschijnen. Bij printen wordt het te brede deel meestal gewoon helemaal weggelaten.

Volle breedte papier gebruiken, maar niet meer dan dat

Vaak zal op een scherm niet de volle breedte van het venster van de browser worden gebruikt. Op een scherm maakt dat weinig uit, op papier wel. De bezoeker kan meestal zelf een kantlijn opgeven in browser en/of printerprogramma. Een smalle pagina laat meer papier ongebruikt dan alleen deze kantlijn, en daar zal de gebruiker niet op zitten te wachten. En het bos ook niet.

Er is nog een belangrijke reden om de breedte bij printen goed te bekijken. Als een pagina breder is dan op het papier past, laten alle browsers gewoon weg wat niet past. Dat geldt dus ook voor tekst. Op een scherm kun je scrollen, op papier niet. Safari op Windows print wat te breed is wel, maar doet dit door álles, de hele pagina, zo klein te maken dat het te brede deel op de pagina past. Dat levert dus onleesbaar kleine letters op. Opera doet het goed: die gebruikt gewoon de hele breedte van het papier in een normale letter en laat niets weg. Dit zal wel vaak de lay-out veranderen.

Een te grote breedte leidt dus vrijwel altijd tot het wegvallen van tekst en dergelijke.

Ook op deze pagina beslaat de tekst niet de volle breedte van het venster van de browser. De breedte van de kolom waar de tekst in staat is 750 px. Die breedte haal ik weg, zodat de volle breedte van het papier kan worden gebruikt. Als de gebruiker een extra kantlijn wil, kan die dat zelf opgeven.

De algemene css die de breedte van de tekst bepaalt:

div#uitleg-content {width: 750px; margin: 0 auto;}

De margin: 0 auto; zorgt voor het horizontaal centreren van de kolom met de tekst.

De css voor het printen:

div#uitleg-content {width: auto;}

Door de breedte op auto te zetten, haal ik hem in feite weg. En uit zichzelf wordt een div even breed als zijn ouder, hier het venster van de browser of de pagina. Dus wordt nu de volle breedte van het papier gebruikt.

De marge kan ik gewoon laten staan, want als de volle breedte wordt gebruikt, heeft deze toch geen enkele invloed.

Helaas heeft het weghalen van deze een vervelende bijwerking: de onderschriften bij de voorbeelden van letters met en zonder schreef en wel en niet proportioneel staan nu niet meer helemaal op de juiste plaats. Dit is een aardige illustratie van hoe je bij 'n beetje ingewikkelde pagina door het oplossen van het ene probleem het volgende juist veroorzaakt, en waarom een pdf in zo'n geval echt beter is.

Normaal genomen zou ik hier dus een pdf van maken. Maar in dit geval ram ik even snel een correctie voor bovenstaand probleem in elkaar, die absoluut niet netjes is, maar wel redelijk werkt:

div.onderschrift-4, div.demo-4 {width: 16.5cm;} div.demo-4 span, div.onderschrift-4 span {width: 4cm;}

De twee divs waar de voorbeelden en de onderschriften in staan maak ik 16,5 cm breed. Dat past altijd op het papier, want het gebruikelijke A4 is 21 cm breed. De erin staande spans met voorbeelden en onderschriften maak ik 4 cm breed. Er is 'n halve cm speling vanwege afrondingsverschillen en zo, anders passen de vier spans niet altijd naast elkaar. Niet netjes, maar nu staat het in ieder geval goed. (Behalve in Opera, maar dat heeft een andere reden.)

Smalle tekst breder printen

Los van deze algemene instellingen kunnen ook bepaalde delen van een venster een afwijkende breedte hebben:

Deze tekst staat in een div, die maar 300 px breed is. De div is horizontaal gecentreerd. Dit ziet er op het scherm ongelooflijk mooi en kunstzinnig en zo uit. Je kunt door middel van dit technische hoogstandje ook goed zien, dat ik heel mooie sites kan maken.

De subtiele tegenstelling tussen de trieste leegte links en rechts doet de literaire kwaliteit van deze tekst nog beter uitkomen dan hij van zichzelf al uitstraalt.

Merk ook op hoe vloeiend de laatste zin loopt. Ja, hier is aandacht aan besteed. Over elke letter is nagedacht. Ik ben een genie!

Goed, medicijnen genomen en het gaat wel weer, dank je.

Als je een of andere lay-out hebt gemaakt met een smalle tekst, zoals hierboven, kan dat op het scherm best leuk en zo zijn. Op papier vaak niet. Weinig mensen barsten uit in vreugdegezang, als ze zien dat het overgrote deel van het papier wit blijft en dus gewoon wordt verspild.

Voor bijvoorbeeld een gedicht ligt dit natuurlijk anders, daar is 'n smalle tekst vaak juist wel goed.

De algemene css voor de div waar de smalle tekst in staat:

div#breedte {width: 300px; margin: 0 auto;}

De css voor het printen:

div#breedte {width: auto;}

Door de breedte op auto te zetten, haal ik hem in feite weg. En uit zichzelf wordt een div even breed als zijn ouder, hier het venster van de browser of de pagina. Dus nu wordt de volle breedte van het papier gebruikt.

De marge kan ik gewoon laten staan, want als de volle breedte wordt gebruikt, heeft deze toch geen enkele invloed.

Het is mogelijk op het scherm tekst in kolommen neer te zetten. Als die bij het printen onder elkaar in plaats van naast elkaar worden gezet om een of andere reden, vergeet dan vooral niet de breedte aan te passen (weg te halen). Een 37 pagina's lange smalle krantenkolom op een verder leeg vel papier, die makkelijk op 8 pagina's had gepast, brengt de lezer niet de rust, die voor lezen nodig is.

Hoogte (height)

Hoogte heeft eigenlijk geen invloed op afdrukken. Als het niet op één pagina past, wordt gewoon verder gegaan op een nieuwe pagina. Alleen de combinatie van een hoogte met overflow op auto of hidden kan problemen opleveren, zoals je gelijk hieronder kunt lezen.

Horizontale en/of verticale scrollbalk (overflow, overflow-x, overflow-y)

Als op het scherm een scrollbalk is te zien, zal bij het printen tekst en dergelijke meestal gewoon verdwijnen. (Dit geldt niet voor de verticale scrollbalk helemaal rechts.)

Horizontale scrollbalk

Dit stukje gaat over kleinere elementen met een horizontale scrollbalk. Voor elementen die te breed zijn voor het papier, zoals tabellen, moet je kijken bij Landschap of portret.

Als aan een blok-element zoals een div een bepaalde breedte wordt opgegeven, kan er meer inhoud in komen te staan dan past. De standaard-instelling is, dat het dan toch wordt weergegeven, en dus ook geprint. Dit wordt geregeld door de eigenschap overflow, die standaard op visible staat.

overflow werkt in horizontale én verticale richting. overflow-x, een css3-eigenschap, werkt precies hetzelfde, maar alleen in horizontale richting.

Als ik de breedte combineer met overflow: auto; of overflow: scroll;, ontstaan scrollbalken. Bij auto verschijnen alleen scrollbalken als dat nodig is, bij scroll altijd, ook als dat niet nodig is. Je kunt dan de inhoud volledig bekijken met behulp van de scrollbalk(en), terwijl de breedte van het blok-element toch hetzelfde blijft. Op papier werkt dit natuurlijk niet, omdat papier geen scrollbalken heeft.

Alleen Opera toont netjes alle inhoud van zo'n te klein blok-element. Nadeel is dan weer wel, dat Opera hier nogal in doorschiet. Het toont ook alles als overflow op hidden is gezet, zoals bij de voorbeelden van proportionele en niet-proportionele lettertypen hierboven. Daar levert dat geen echte problemen op, maar er zijn zat situaties te bedenken, waarin het bij printen wél tot (grote) problemen kan leiden.

Bij alle andere browsers wordt wat niet past in de div gewoon niet getoond. Internet Explorer 7 en 9, Google Chrome en Safari op OS X zetten bovendien als extra bonus een horizontale scrollbalk over de onderste tekst. Pardon, een scrollbalk? Bij een afdruk? Ja. De logica ontgaat mij ook, maar er wordt dus echt een scrollbalk over de onderste tekst geprint.

(Aanvulling 15 april 2012: Safari was kennelijk zo trots over de uitvinding van de scrollbalk op papier, dat deze inmiddels ook op XP en Windows 7 is verschenen. In Google Chrome daarentegen is de scrollbalk op papier verdwenen in XP, maar blijven staan in OS X, Windows 7 en Linux. Mogelijk heeft Apple, die zich tot een echte patenttrol heeft ontwikkeld, patent aangevraagd op de papieren scrollbalk?)

Hieronder staat nog eens dezelfde smalle tekst als die van een eind hierboven. De paragrafen in de div zijn 500 px breed, de div is maar 300 px breed en heeft overflow op auto staan, zodat een horizontale scrollbalk ontstaat. Grote delen van deze tekst vallen, behalve bij Opera, dus weg bij printen.

Deze tekst staat in een div, die maar 300 px breed is. De div is horizontaal gecentreerd. Dit ziet er op het scherm ongelooflijk mooi en kunstzinnig en zo uit. Je kunt door middel van dit technische hoogstandje ook goed zien, dat ik heel mooie sites kan maken.

De subtiele tegenstelling tussen de trieste leegte links en rechts doet de literaire kwaliteit van deze tekst nog beter uitkomen dan hij van zichzelf al uitstraalt.

Merk ook op hoe vloeiend de laatste zin loopt. Ja, hier is aandacht aan besteed. Over elke letter is nagedacht. Ik ben een genie!

De normale css:

div#te-breed {width: 300px; overflow: auto; margin: 0 auto;} div#te-breed p {width: 500px;}

Door de paragrafen 200 px breder te maken dan de div, ontstaat er een horizontale scrollbalk. Daarvoor is ook nog nodig dat bij de div overflow op auto wordt gezet, omdat standaard alles zichtbaar is, ook als het eigenlijk niet past.

Moraal van het verhaal: zorg dat alles gewoon zichtbaar is. En als er ergens scrollbalken zijn op het scherm, zet dan bij die elementen overflow op visible bij het printen. Of haal de breedte weg. De volgende css voor het printen werkt allebei:

div#te-breed {width: auto;}

of

div#te-breed {overflow: visible;}

(Eigenlijk moet je ook bij de <p> de breedte weghalen, omdat anders nog niet de volle papierbreedte wordt gebruikt. Verschillende browsers zetten de 500 px brede tekst ook niet allemaal op dezelfde plaats neer. Dit laatste zou je kunnen opvangen door aan de css voor het printen bij de <p> toe te voegen: margin: 0 auto;. Nu staat de tekst horizontaal gecentreerd.)

Verticale scrollbalk

Dit stukje gaat over kleinere elementen met een verticale scrollbalk. Als de pagina gewoon te lang is voor een blad papier, gaan alle browsers probleemloos door met een volgend vel papier.

Als aan een blok-element zoals een div een bepaalde hoogte wordt opgegeven, kan er meer inhoud in komen te staan dan past. De standaard-instelling is dat het dan toch wordt weergegeven, en dus ook geprint. Dit wordt geregeld door de eigenschap overflow, die standaard op visible staat.

overflow werkt in horizontale én verticale richting. overflow-y, een css3-eigenschap, werkt precies hetzelfde, maar alleen in verticale richting.

Als ik de hoogte combineer met overflow: auto; of overflow: scroll;, ontstaan scrollbalken. Bij auto verschijnen alleen scrollbalken als dat nodig is, bij scroll altijd, ook als dat niet nodig is. Je kunt dan de inhoud volledig bekijken met behulp van de scrollbalk(en), terwijl de hoogte van het blok-element toch hetzelfde blijft. Op papier werkt dit natuurlijk niet, omdat papier geen scrollbalken heeft.

Hieronder staat een div met een gedicht. De div heeft een hoogte van 150px en overflow op auto. Binnen die div staat een gedicht van 20 regels, dus dat past nooit. Op het scherm verschijnt dan ook een verticale scrollbalk. Omdat het een gedicht is, heb ik de tekst horizontaal gecentreerd. Er is ook een kleine marge aan boven- en onderkant. De css:

div#te-hoog {height: 150px; overflow: auto; margin: 20px 0; text-align: center;}

En de div met het gedicht:

Ik ben twintig regels hoog
Ach, was ik maar een theoloog
Dit is nummer drie
Hoera, een voetbalknie
Nummer vijf
Haal je poten van m'n lijf
Nummer zeven
Moderne dichtkunst is net 't leven
Geen touw aan vast te knopen
Nu ben ik negen misgelopen
Dus dit is nummer elf
Mijn hoofd is een gewelf
Ik heb dertien jubeltenen
Kon ik die maar belenen
Vijftien regels moderne dichtkunst
Eigenhandig in elkaar geklunsd
Hoera, nog maar vier
Dan is het uit met dit geklier
Ach lief, je bent een ijspegel
Hèhè de laatste regel

(Gedicht, 1480, gevonden in kerker in Genua, dichter onbekend.)

Bij printen worden alleen de bovenste regels afgedrukt, ongeveer wat in het zichtbare deel van het venster past. Ook Opera drukt nu niet alles af, anders dus dan bij een horizontale scrollbalk.

(Ook Opera drukt nu een scrollbalk af, zodat alleen Firefox en Internet Explorer 8 dit niet doen.)

Als de tekst een eind omlaag is gescrold, drukken Safari en Google Chrome een lager deel van de tekst af, maar niet altijd het dan op het scherm zichtbare deel. Hoe dan ook: bij alle browsers verdwijnt er dus een deel van de tekst.

Door de hoogte op auto of overflow op visible te zetten, zou alles zichtbaar worden op het scherm. Dus ook worden afgedrukt. Ik herhaal de div met het gedicht nog eens, maar met een andere id. De css is echter hetzelfde.

Ik ben twintig regels hoog
Ach, was ik maar een theoloog
Dit is nummer drie
Hoera, een voetbalknie
Nummer vijf
Haal je poten van m'n lijf
Nummer zeven
Moderne dichtkunst is net 't leven
Geen touw aan vast te knopen
Nu ben ik negen misgelopen
Dus dit is nummer elf
Mijn hoofd is een gewelf
Ik heb dertien jubeltenen
Kon ik die maar belenen
Vijftien regels moderne dichtkunst
Eigenhandig in elkaar geklunsd
Hoera, nog maar vier
Dan is het uit met dit geklier
Ach lief, je bent een ijspegel
Hèhè de laatste regel

Voor deze div heb ik voor het printen wat css toegevoegd, die ervoor zorgt dat alles wordt afgedrukt:

div#te-hoog-print {height: auto;}

of

div#te-hoog-print {overflow: visible;}

Met de tweede regel drukken Firefox, Google Chrome en Internet Explorer 8 en 9 het gedicht wel volledig af, maar ze zetten het gedeeltelijk over de erop volgende tekst heen. Dus alleen de eerste mogelijkheid is in de praktijk bruikbaar: de hoogte op auto zetten.

Weer een aardige illustratie van hoeveel er getest moet worden en waarom een pdf vaak veel simpeler is.

border

Borders worden in principe gewoon geprint. Alleen is er geen enkele zekerheid dat ze in kleur worden geprint. Als de gebruiker in zwart-wit print, worden de borders ook zwart of een of ander soort grijs.

Op deze pagina staat een aantal elementen met een border, zoals de header. Omdat die elementen toch niet worden geprint, hoef ik daar niets aan te doen.

Om een aantal stukken tekst die moeten opvallen, staat een rode border. Die laat ik gewoon staan. Als het in rood wordt geprint, prima, en als het in zwart-wit wordt geprint, is dat ook niet het eind van de wereld.

Rondom de middelste kolom staat, als afscheiding tussen het grijs en het wit, een zwarte border. Die is op papier volkomen zinloos. Maar hij kost wel ruimte en inkt, dus haal ik hem weg met de volgende css voor het printen:

div#uitleg-content {border: 0;}

outline

Outline werkt hetzelfde als op het scherm. Dat wil zeggen dat het gewoon wordt geprint, hoewel je dus nooit zeker kunt weten of iemand in zwart-wit of kleur print. En Internet Explorer 7 kent geen outline, dus die laat het gewoon weg.

Formulieren (<form>)

Formulieren worden probleemloos door alle browsers afgedrukt. Omdat formulieren vaak worden opgemaakt met eigenschappen als float en position, kan dat wel problemen opleveren, maar knoppen en dergelijke worden netjes afgedrukt.

Wel valt natuurlijk bij keuzelijsten het uitklapbare deel weg. Persoonlijk zou ik trouwens niet weten, waarom je 'n formulier zou willen afdrukken. Een formulier is per definitie bedoeld om via internet te versturen. Maar goed, het kan.

Frames

Frames zijn ontoegankelijke rotdingen, waarvan het gebruik al ruim tien jaar wordt afgeraden. In html5, dat op het moment wordt ingevoerd, zijn ze helemaal niet meer mogelijk. Bij printen leveren ze grote problemen op. Frames horen niet gebruikt te worden en zeker niet als een pagina moet kunnen worden geprint. Omdat frames al zolang worden afgeraden, ga ik er hier verder niet op in.

Lijsten (<ul>, <ol>, <dl>)

Ongeordende en geordende lijsten en definitielijsten lijken door alle browsers zonder problemen geprint te worden. Alleen bij 'n zeer ingewikkelde lijst gaf Opera kleine problemen, maar dat had meer met position dan met de lijst te maken.

iframe en object (<iframe>, <object>)

In alle browsers wordt alleen het op het scherm zichtbare deel afgedrukt. Als iframe of object meer inhoud heeft dan in het venster past, verschijnt op het scherm een scrollbalk. Maar bij afdrukken verdwijnt dat teveel dus gewoon helemaal.

Het veiligste is om gewoon geen iframe of object te gebruiken. Als je het toch doet, zorg er dan absoluut voor dat de inhoud altijd binnen het venster past. (En omdat je daar eigenlijk niet met honderd procent zekerheid voor kunt zorgen, kun je ze dus beter gewoon niet gebruiken.)

content

Het toevoegen van tekst en dergelijke door middel van de eigenschap content werkt in alle browsers hetzelfde als op het scherm.

Nieuwe pagina maken (page-break-before, page-break-after)

Deze eigenschappen zijn volstrekt onbetrouwbaar. Misschien werken ze, maar misschien ook wel niet. Of ze geven nieuwe pagina's op andere plaatsen dan waar dat zou moeten. Of ze stoppen er spontaan 'n extra lege pagina tussen. Als je verder leest, moet je dus steeds in gedachten houden dat het gebruik van deze attributen eigenlijk 'n soort gokspel is.
Dit stukje tekst is niet aangepast, het dateert dus nog uit 29 juli 2010. Ik heb even gespeeld met deze eigenschappen, en er zijn evenveel fouten uitgehaald als er nieuwe in zijn gekomen. Het heeft dus weinig zin, dit heel uitgebreid te gaan testen. De oplossing die hieronder staat, werkt echter nog steeds. Toevallig. In dit geval. Als Saturnus in de ascendant van Pluto staat en Jomanda de zon heeft ingestraald. Oftewel: maak een pdf als dit soort dingen belangrijk zijn. Printen heeft overduidelijk geen prioriteit bij de makers van browsers.

Zoals de naam al zegt, kun je page-break-before gebruiken om een nieuwe pagina te laten beginnen vóór een element, en page-break-after na een element. Het element moet een blok-element zijn.

Deze eigenschap heeft een aantal waarden. Er is nogal verschil in ondersteuning door de verschillende browsers. Voor de volledigheid de belangrijkste waarden:

Deze tekst over een nieuwe pagina (vanaf het kopje Nieuwe pagina maken) staat in een div met id="a-nieuwe-pagina". Op het scherm zie je helemaal niets aan deze div.

Bij printen begint deze tekst op een nieuwe pagina, en het volgende hoofdstukje begint ook op een nieuwe pagina. Zoals je kunt zien op de print vreet dit papier en moet je het dus alleen doen als er 'n heel goede reden voor is.

De css voor het printen waarmee je dit voor elkaar krijgt:

div#a-nieuwe-pagina {page-break-before: always; page-break-after: always;}

Helaas echter wordt in Safari en Google Chrome foutief een nieuwe pagina begonnen achter het hierboven staande kopje outline. De tekst daaronder wordt vervolgens gewoon op deze pagina gezet. Dat kan vervelend uitpakken als je bijvoorbeeld een tabel op één pagina wilt hebben. Het wordt eentonig, maar alweer een reden om, als je écht controle wilt hebben, een pdf te maken.

Als ik een extra page-break-after toevoeg bij de div voor div#a-nieuwe-pagina, gaat het goed in Safari en Google Chrome. Maar Firefox, Opera en Internet Explorer 7 zetten er nu 'n extra lege pagina tussen. Behalve Internet Explorer 8, die doet 't ook goed. Overigens doen Internet Explorer 7 en 8, Opera en Firefox het allemaal volgens de specificatie, want die zegt alleen dat 'overbodige' lege pagina's moeten worden voorkomen, dus dat is nogal vaag.

In dit geval heb ik het opgelost door de css aan te passen. Er staat nu een page-break-after bij de div vóór de div waar deze tekst in staat (dat is div#a-content), en eentje bij de div waar deze tekst in staat. De css voor het printen wordt dan:

div#a-content, div#a-nieuwe-pagina {page-break-after: always;}

Ha, dacht ik, opgelost. Maar nu gooit Opera er om een of andere duistere reden een extra lege pagina tussen. Uiteindelijk moet ik een page-break-after bij de voorgaande div zetten, en een page-break-before bij de div die hierna komt (div#a-geen-nieuwe). En dan werkt het eindelijk in alle browsers goed:

div#a-content {page-break-after: always;} div#a-geen-nieuwe {page-break-before: always;}

Dit is wel een aardige illustratie van de gebrekkige implementatie van printcommando's in diverse browsers. En van het gebrek aan échte controle dat je over het afdrukken hebt. Dus als dat écht belangrijk is: maak een pdf en verspreidt die.

Nieuwe pagina voorkomen (page-break-inside)

Volgens allerlei elkaar tegensprekende bronnen zou dit wel/niet werken in Opera, Safari, Google Chrome en Internet Explorer 8. Het lijkt ook te werken in Google Chrome. Lijkt? Ondanks uitvoerig testen kan ik het gebruik van deze eigenschap niet anders omschrijven dan als Russisch roulette: als je geluk hebt, werkt het; als je pech hebt, werkt het niet of doet het andere dingen dan je zou verwachten. Als je verder leest, moet je dus steeds in gedachte houden dat dit attribuut eigenlijk onder de Wet op de Kansspelen zou horen te vallen.

Dit attribuut kent twee waarden: auto en avoid. auto is de standaardwaarde. avoid wordt verondersteld het beginnen van een nieuwe pagina binnen een blok-element te voorkomen.

In Google Chrome leek het, als je dat opgeeft, bij het testen te voorkomen dat een paragraaf <p> op meerdere pagina's wordt gezet. Maar een afbeelding wordt wel vrolijk over meerdere pagina's gesplitst, als het zo uitkomt, ook bij gebruik van dit attribuut. En het niet-splitsen van een afbeelding lijkt me toch wat belangrijker dan het niet-splitsen van een paragraaf.

In Internet Explorer 8 werd het splitsen van sommige <p>'s en <div>'s voorkomen, maar niet van alle. Volgens Microsoft zou splitsen van een element met een border altijd zoveel mogelijk voorkomen moeten worden bij printen, ook zonder dit attribuut. Maar zelfs met dit attribuut werd tekst met een border regelmatig over meerdere pagina's verdeeld, terwijl daar geen noodzaak voor was.

In Opera werkt het wel, maar om een of andere reden wordt aan het begin een lege pagina tussengevoegd als je het bij alle <p>'s gebruikt. Als je het echter, zoals ik hieronder doe, alleen gebruikt bij bijvoorbeeld .kader werkt het prima. Het heeft in Opera geen invloed op de cellen binnen een tabel.

In Internet Explorer 9 werkt deze eigenschap helemaal goed. Hij zorgt er zelfs voor dat de cellen binnen de tabel helemaal onderaan deze pagina op één pagina blijven staan.

In Safari zag ik geen enkel effect, waar ik het ook neerzette.

Alles bij elkaar is dit attribuut dus gewoon niet bruikbaar. Maar omdat het verder geen nadelen heeft, heb ik het op deze pagina toch gebruikt bij de teksten waar een rode border om staat en bij de cellen in de tabel onderaan deze pagina. Opera en vooral Internet Explorer 9 printen het dan toch iets beter af. In de css voor printen staat:

.kader, td {page-break-inside: avoid;}

Landschap of portret (size, transform, writing-mode)

Er is op dit moment stomweg geen betrouwbare methode die in elke browser voor het printen als landschap of portret zorgt. Als dat echt belangrijk is, moet je een pdf maken.

Meestal wordt een pagina in 'portret'-mode gedrukt: staand. Als je heel brede tekst hebt, bijvoorbeeld een tabel, kan het soms nodig zijn in 'landschap'-mode te printen: liggend. In theorie kun je dit voor het hele drukwerk of per pagina opgeven. De woorden 'In theorie' staan daar niet per ongeluk.

Alle pagina's landschap of portret

Alle pagina's in dezelfde richting afdrukken is relatief makkelijk. Elke browser en/of printerprogramma heeft namelijk de mogelijkheid dit in te stellen. Het enige dat je moet doen, is een duidelijke melding aan de bezoeker geven dat hij landschap of portret moet instellen. Landschap hoeft trouwens normaal genomen niet te worden ingesteld, want dat is vrijwel altijd de standaard-instelling.

Dit is, naast het maken van een pdf, de enige min of meer betrouwbare methode die in elke browser werkt.

Daarnaast werken in afzonderlijke browsers de volgende manieren:

Opera

In css2 is @page ingevoerd. Daarmee kunnen eigenschappen voor één of meer pagina's worden opgegeven. In css3 is een aantal nieuwe eigenschappen toegevoegd, waaronder size. Op dit moment is Opera de enige browser die hiermee uit de voeten kan. Omdat dit attribuut hier speciaal voor is gemaakt, wordt echt álles aangepast. Ook bijvoorbeeld de afbeeldingen worden gekanteld.

Ik kan dit al gewoon gebruiken, want browsers die dit niet kennen, negeren het gewoon. En als ze het ooit wel herkennen: des te beter. Het zou wel kunnen botsen met een van de andere manieren die hieronder staan aangegeven voor andere browsers. Zoiets van twee keer 90 graden draaien levert 180 graden op, waarbij de pagina dus niet als landschap, maar ondersteboven wordt geprint. Maar dat is raden. En dat is het (kleine) risico dat je loopt bij het gebruiken van css3, wat nog geen officiële standaard is.

De css voor het printen:

@page body {size: landscape;}

Een regel in de css voor een pagina begint altijd met @page.

Omdat in dit geval alle pagina's in landschap-mode moeten worden geprint, komt hierachter body te staan. Daarbinnen staan immers alle pagina's.

Het attribuut size kent de waarden landscape en portrait. Bij landscape wordt liggend afgedrukt. portrait is de standaardwaarde, dus die zal niet vaak worden gebruikt voor alle pagina's.

Je kunt bij size ook nog papierformaten opgeven. Ik ga daar niet verder op in, omdat alleen Opera dit attribuut herkent. Bovendien weet je vrijwel nooit zeker welk papierformaat de bezoeker zal gebruiken, dus een papierformaat is alleen veilig te gebruiken binnen een intranet of zo, waar iedereen hetzelfde formaat papier gebruikt.

Ik moet overigens nog opmerken dat bij het daadwerkelijk printen (Windows XP, nieuwste versie van Opera, Canon Pixma ip4000) deze instelling resulteerde in egaal grijze pagina's waarop slechts het adres uit de adresbalk en de titel van de pagina veelvuldig werden herhaald. Ik zal het zo zeggen: helemaal overtuigd van de goede werking van deze eigenschap in Opera ben ik niet. (Ja, klopt, ik heb ooit in de politiek gezeten.) Haal ik de @page-regel weg, dan is de afdruk wel goed.

Firefox, Safari, Google Chrome en Internet Explorer 7

Voor deze browsers bestaat er op het ogenblik geen enkele manier om de hele tekst met behulp van css in landschap af te drukken. Ook met JavaScript en dergelijke bestaan er geen methoden.

Dat wil zeggen: je kunt wel de hele tekst met behulp van css gedraaid afdrukken, maar na de eerste pagina gaat het gigantisch mis. Er verdwijnen hele delen van de tekst en het papier blijft voor het grootste deel leeg. Dat draaien gebeurt trouwens niet door het gebruik van size, maar door grotelijks misbruik te maken van experimentele eigenschappen die daar niet voor zijn bedoeld: -moz-transform en -webkit-transform.

Het enige wat overblijft, is dus het waarschuwen van de bezoeker en deze de instellingen laten veranderen, of het maken van een pdf.

Internet Explorer 8

In Internet Explorer 8 kan de hele tekst min of meer in landschap-mode worden geprint. Min of meer. De tekst wordt volledig geprint, er vallen geen delen weg. Maar de lay-out wordt wel behoorlijk veranderd. Zo springen bijvoorbeeld alle kopjes plotseling een eind naar binnen. Omdat dit alleen binnen Internet Explorer 8 werkt, zorg ik dat alleen Internet Explorer 8 de volgende code leest:

<!--[if IE 8]> <style media="print"> body {ms-writing-mode: tb-rl;} img {filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=1); </style> <![endif]-->

<!--[if IE 8]> tot en met <[endif]-->

Dit is een echte slimmigheid van Microsoft. Omdat dit begint met <!--, is wat volgt commentaar. Het wordt door de browser genegeerd. Tot aan <![endif]-->. Dit eindigt op -->, en geeft dus het einde van het commentaar aan. Precies zoals bij gewoon commentaar in html gebeurt.

Binnen commentaar mag je vrijwel alles neerzetten wat je wilt. Microsoft gebruikt die vrijheid om er code neer te zetten, die alleen door (een bepaalde versie van) Internet Explorer wordt herkend. Het stukje [if IE 8] betekent: als het Internet Explorer versie 8 is. Oftewel: alleen Internet Explorer 8 leest de code tussen <!--[if IE 8]> en <![endif]-->.

Binnen de begin- en eindtag voor commentaar staat css voor het printen. Je kunt hier ook een link naar een extern stylesheet neerzetten.

Het is belangrijk dat de spaties in <!--[if IE 8]> en <![endif]--> precies zo worden neergezet, als ze hier staan.

body {ms-writing-mode: tb-rl;}

Deze eigenschap is door Microsoft bedacht. Hij is bedoeld om talen, die in een andere volgorde lopen dan de westerse, correct weer te geven, dus eigenlijk niet om in landschap-mode te printen. Inmiddels is writing-mode opgenomen in een ontwerpspecificatie voor css3.

Het is nog onduidelijk hoe writing-mode uiteindelijk gaat werken. Om duidelijk te maken dat de eigenschap op dit moment nog alleen werkt zoals Microsoft dat heeft bedacht, wordt het voorvoegsel ms- voor writing-mode gezet. Dan bijt het de 'echte' writing-mode niet als die ooit werkelijk gebruikt kan worden.

Het betekent: geef de tekst van boven naar onder en van rechts naar links weer. En dit levert bij een westerse taal landschap-mode op. Maar niet helemaal. Logisch, want het is er eigenlijk niet voor bedoeld.

Alle kopjes springen plotseling een eindje in. De onderschriften onder de voorbeelden met letters met en zonder schreef en met en zonder proportioneel schrift, staan tegen elkaar aan en niet onder, maar naast de bijbehorende voorbeelden. De afbeeldingen worden niet gedraaid en staan dus 90 graden verkeerd. Ik neem aan dat er ook wel problemen zullen zijn met dingen als tabellen.

Maar er valt in ieder geval geen tekst weg. En als je zorgvuldig test, is dit mogelijk bruikbaar. Hoewel ik denk dat het testen zoveel tijd kost, dat je echt beter een pdf kunt maken.

img {filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=1);

Omdat de afbeeldingen niet mee draaien met de tekst, staan die 90 graden verkeerd. Dit stukje css, dat alleen werkt in Internet Explorer, zorgt ervoor dat de afbeeldingen in de goede richting komen te staan. Zo zijn er waarschijnlijk voor alle problemen wel oplossingen te vinden.

Blijft staan: het wordt ook in Internet Explorer 8 nooit zo goed als met een pdf.

Internet Explorer 9

Mogelijk werkt wat hierboven staat voor Internet Explorer 8 ook voor Internet Explorer 9. Ik heb dat verder niet uitgeprobeerd, omdat het in de praktijk toch niet bruikbaar is. Steeds meer mensen gaan (gelukkig) andere browsers dan Internet Explorer gebruiken, en die mensen zouden dan niet kunnen printen. En had ik al gezegd dat een pdf makkelijker te maken is en voor iedereen werkt?

Eén pagina landschap of portret

De tabel hieronder is veel te breed voor het venster van de browser. Op het scherm krijgt hij gewoon een scrollbalk. Bij printen moet de tabel op een aparte pagina worden gezet en in landschap-mode worden geprint. Ik heb een tabel genomen omdat juist een tabel vaak te breed voor papier zal zijn.

Om te kijken wat er met een afbeelding gebeurt, staat in de bovenste rij een kleine smiley. De tabel is verder gewoon in elkaar geramd. Ik zou zelf niet direct durven beweren, dat het een meesterwerk op het gebied van literatuur of lay-out is, maar je hebt natuurlijk het volste recht om wel in opperste bewondering amechtig neer te zijgen.

MaandagDinsdagWoensdagDonderdagVrijdagZaterdagZondag
Eerste uur smileyEerste uurEerste uurEerste uurEerste uurEerste uurEerste uur
Tweede uurTweede uurTweede uurTweede uurTweede uurTweede uurTweede uur
Derde uurDerde uurDerde uurDerde uurDerde uurDerde uurDerde uur
Vierde uurVierde uurVierde uurVierde uurVierde uurVierde uurVierde uur
Vijfde uurVijfde uurVijfde uurVijfde uurVijfde uurVijfde uurVijfde uur
Zesde uurZesde uurZesde uurZesde uurZesde uurZesde uurZesde uur
Zevende uurZevende uurZevende uurZevende uurZevende uurZevende uurZevende uur
Achtste uurAchtste uurAchtste uurAchtste uurAchtste uurAchtste uurAchtste uur
Negende uurNegende uurNegende uurNegende uurNegende uurNegende uurNegende uur
Tiende uurTiende uurTiende uurTiende uurTiende uurTiende uurTiende uur
Elfde uurElfde uurElfde uurElfde uurElfde uurElfde uurElfde uur
Twaalfde uurTwaalfde uurTwaalfde uurTwaalfde uurTwaalfde uurTwaalfde uurTwaalfde uur
Dertiende uurDertiende uurDertiende uurDertiende uurDertiende uurDertiende uurDertiende uur
Veertiende uurVeertiende uurVeertiende uurVeertiende uurVeertiende uurVeertiende uurVeertiende uur
Vijftiende uurVijftiende uurVijftiende uurVijftiende uurVijftiende uurVijftiende uurVijftiende uur
Zestiende uurZestiende uurZestiende uurZestiende uurZestiende uurZestiende uurZestiende uur
Zeventiende uurZeventiende uurZeventiende uurZeventiende uurZeventiende uurZeventiende uurZeventiende uur
Achttiende uurAchttiende uurAchttiende uurAchttiende uurAchttiende uurAchttiende uurAchttiende uur
Negentiende uurNegentiende uurNegentiende uurNegentiende uurNegentiende uurNegentiende uurNegentiende uur
Twintigste uurTwintigste uurTwintigste uurTwintigste uurTwintigste uurTwintigste uurTwintigste uur

Opera

css3 kent de eigenschap transform. Opera ondersteunt deze eigenschap in experimentele vorm, daarom heeft hij het voorvoegsel -o-. Met behulp van deze eigenschap kun je onder andere een element draaien. De volgende css voor het printen werkt in Opera:

div#een-landschap table {-o-transform: rotate(90deg); page-break-before: always; page-break-after: always;}

De tabel staat binnen een div met id="een-landschap". Om te zorgen dat de css alleen voor déze tabel werkt, is deze div aan de selector toegevoegd.

Om de tabel op een aparte pagina te krijgen, wordt voor de tabel een page-break-before en na de tabel een page-break-after gezet.

-o-transform wordt, door het voorvoegsel -o-, alleen herkend door Opera. Het is geen valid css, maar omdat je precies weet waardoor de foutmelding wordt veroorzaakt, kun je die negeren. Met rotate(90deg) wordt de hele tabel 90 graden gedraaid, oftewel: in landscape afgedrukt.

Hoewel transform hier niet direct voor is bedoeld, werkt het prima. Ook de afbeelding wordt netjes gedraaid. Als de gedraaide tabel te breed is voor het papier, dus als er te veel regels in staan, wordt het teveel gewoon niet afgedrukt. Als de gedraaide tabel te hoog is voor het papier, dus als er te veel kolommen in staan, wordt het teveel niet afgedrukt. Het is dus belangrijk dat je zeker weet dat de tabel op het papier past. (Had ik al gezegd dat je dat alleen bij een pdf enigszins zeker weet?)

Omdat -o-transform geen geldige css is, valideert je css niet. Omdat de reden ervan duidelijk is, lijkt me dat in dit geval geen probleem.

Goed, nog 'n aanvulling. Bij het printen op papier en bij het maken van de uiteindelijke pdf liet Opera de hele tabel gewoon maar weg. Terwijl het eerst dus wel goed ging. Een aardige illustratie van de betrouwbaarheid van printen op het ogenblik. Ik heb geen flauw idee waarom, want de code was niet ingrijpend gewijzigd tussen testen en uiteindelijk printen. Ik ga het waarom ook niet uitzoeken: alles wijst gewoon in de richting dat je een pdf moet maken als het om meer dan de meest simpele tekst gaat.

En nog 'n aanvulling: de keer daarna werd de tabel weer wel goed geprint... Met exact dezelfde code...

Firefox

Firefox heeft een soortgelijke experimentele eigenschap als Opera: -moz-transform. Alleen lukt het niet om een tabel op een nieuwe pagina te krijgen, waardoor grote delen buiten het papier vallen of over andere tekst komen te staan. Op dit moment kan dit gewoon niet in Firefox.

Safari en Google Chrome

Voor Safari en Google Chrome geldt precies hetzelfde verhaal als voor Firefox hierboven, alleen heet de experimentele eigenschap hier -webkit-transform.

Internet Explorer 7

Ook Internet Explorer kent een manier om een element te draaien: een filter dat alleen in Internet Explorer werkt: <!--[if IE 7]> <style media="print"> div#een-landschap table {filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=3); width: 100%;} </style> <![endif]-->

<!--[if IE 7]> tot en met <[endif]-->

Dit is een echte slimmigheid van Microsoft. Omdat dit begint met <!--, is wat volgt commentaar. Het wordt door de browser genegeerd. Tot aan <![endif]-->. Dit eindigt op -->, en geeft dus het einde van het commentaar aan. Precies zoals bij gewoon commentaar in html gebeurt.

Binnen commentaar mag je vrijwel alles neerzetten wat je wilt. Microsoft gebruikt die vrijheid om er code neer te zetten, die alleen door (een bepaalde versie van) Internet Explorer wordt herkend. Het stukje [if IE 7] betekent: als het Internet Explorer versie 7 is. Oftewel: alleen Internet explorer 7 leest de code tussen <!--[if IE 7]> en <![endif]-->.

Binnen de begin- en eindtag voor commentaar staat css voor het printen. Je kunt hier ook een link naar een extern stylesheet neerzetten.

Het is belangrijk dat de spaties in <!--[if IE 7]> en <![endif]--> precies zo worden neergezet, als ze hier staan.

De te printen tabel staat binnen een div met id="een-landschap". Het daarachter staande koeterwaals is de manier waarop Microsoft een element laat draaien. Met het getal 3 geef je de richting aan.

In Internet Explorer 7 werkt dit alleen maar als het element hasLayout heeft. Dit is een raar bedenksel van Microsoft, dat je alleen maar indirect kunt instellen. Een pagina wordt totaal anders weergegeven met hasLayout aan of uit. In de verschillende versies van Internet Explorer werkt dit dan ook nog 'ns totaal verschillend. Gelukkig bestaat het kreng in Internet Explorer 8 niet meer.

hasLayout wordt onder andere aangezet door een breedte te geven aan het element. Dat komt goed uit, want hier staat een breedte. Als ik een breedte van 100% opgeef, wordt de volledige tabel geprint, ook als deze eigenlijk te breed is voor het papier. Hij wordt dan verkleind tot hij past.

Als de tabel te hoog is voor het papier, valt ook hier wat niet past weg.

Een nieuwe pagina werkt niet bij een tabel, dus de tabel wordt gewoon tussen de andere tekst gezet. Maar afgezien hiervan werkt dit in Internet Explorer 7 met voorsprong het beste. Ook de afbeelding wordt netjes gedraaid.

Internet Explorer 8

In Internet Explorer 8 kun je een tabel draaien op dezelfde manier als in Internet Explorer 7. Maar er vallen, wat je ook probeert, grote delen van de tabel weg. Dus werkt dit gewoon niet in Internet Explorer 8.

Internet Explorer 9

Ik heb niet geprobeerd of dit werkt in Internet Explorer 9. Het is toch niet bruikbaar, omdat het geen betrouwbare methode is die voor iedereen werkt. Dus in de praktijk hoe dan ook onbruikbaar.

Een aantal pagina's landschap of portret

Ja, dat was het plan. Maar aangezien de resultaten hierboven voor één pagina in afwijkende mode sterk doen denken aan de resultaten van de laatste verkiezingsuitslag van het CDA onder de bezielende leiding van Balkenende (gehalveerd), zoek ik dit verder maar niet uit. Het enige verschil met die uitslag is, dat ik van die uitslag vrolijk werd. Van bovenstaande resultaten niet. (Gelukkig blijkt Verhagen het zegenrijke werk van Balkenende voort te zetten. Nog nooit zo laag gestaan in de peilingen. Toch nog een vrolijke noot bij dit meest asociale kabinet aller tijden.)

Wezen en weduwen (orphans, widows)

Een wees is een regel die eenzaam onderaan een pagina achterblijft, de eerste regel van een alinea bijvoorbeeld. Overigens is dit in de grafische wereld beter bekend onder een benaming die met het nageslacht van een dame met een bepaald beroep te maken heeft.

Een weduwe is het tegenovergestelde. Het is de laatste regel van bijvoorbeeld een alinea, die eenzaam bovenaan de volgende pagina wordt neergezet.

Met orphans geef je het minimale aantal regels aan dat onderaan een pagina moet staan, met widows het minimale aantal dat bovenaan een pagina moet staan. Dit werkt natuurlijk alleen maar als de alinea minimaal dat aantal regels heeft.

Op dit moment werkt dit alleen maar in Opera en Internet Explorer 8 en 9. Op deze pagina staat de volgende css voor het printen:

p {widows: 2; orphans: 2;}

Dit zorgt ervoor dat, als dat enigszins mogelijk is, er minimaal twee regels van een paragraaf onder- en bovenaan de pagina komen te staan. Browsers die dit niet kennen, negeren het gewoon.

Tabellen (<table>)

Bij tabellen sla ik twee vliegen in een klap. Jesses, wat 'n agressief spreekwoord. Opnieuw.

Bij tabellen maak ik van de nood een deugd. Ik gebruik het voorbeeld om de css van deze pagina in te zetten. Hieronder staat 'n tabel met in de linkerkolom de algemene css. In de middelste kolom staat de css voor het printen. En in de rechterkolom staat het waarom daarvan. Als er in de middelste kolom niets staat, is gewoon de algemene css geldig.

Bij zo'n lange verticale tabel gaat er nogal het een en ander mis. Alleen Internet Explorer 8 doet het enigszins goed, en Internet Explorer 9 doet het helemaal goed. Ook hier geldt dus weer: als je zeker wilt zijn dat het wordt, zoals de bedoeling is, maak een pdf.

Alle browsers behalve Internet Explorer 9 beginnen onbekommerd een nieuwe pagina binnen een <td>, terwijl dat niet zou moeten omdat td {page-break-inside: avoid;} is gebruikt. Maar daar was ik niet echt verbaasd over, gezien de slechte werking van deze eigenschap.

De zwarte randjes vallen gedeeltelijk weg in Firefox en Internet Explorer 7. Nou ja, gedeeltelijk: het is feitelijk een ware slachting.

Boven de kolommen staan kopjes. Als je die binnen <thead> zet, herhalen Firefox en Internet Explorer 8 en 9 ze bovenaan elke pagina.

Over de tabel hieronder.

Normaal genomen is de css korter, omdat er veel meer gecombineerd kan worden. Dat ging hier vaak niet, omdat ik de css voor het printen naast de algemene css wilde hebben.

Als er in de middelste kolom niets staat, is er geen speciale css voor het printen nodig. Dan geldt dus de algemene css. (Tenzij natuurlijk in de derde kolom staat dat het helemaal niet wordt afgedrukt of zo.)

Normaal genomen houd ik bij de css zo goed mogelijk dezelfde volgorde als bij de html aan. Dat zoekt veel makkelijker. Omdat de algemene css naast de css voor het printen moest komen, kon ik die volgorde hier niet altijd aanhouden.

Algemene csscss voor printenReden
body{margin: 0;padding: 0;font-family: Arial, Helvetica, sans-serif;font-size: 110%;color: black;background: #bbb;} body{  font-family: Georgia, serif; font-size: 12pt; background: none;} Een letter met schreef (dwarsstreepjes) leest op papier beter.
pt is een goede eenheid voor printers.
Op een gekleurde achtergrond zit niemand te wachten.
a#skippy{position: absolute;left: -2000px;top: 0;z-index: 50;width: 10.5em;height: 4.8em;border: red solid 3px;background: white;line-height: 2.4em;text-align: center; } a#skippy{          display: none;} De link om in één keer de inhoud te passeren is op papier zinloos. Hij kan wel voor problemen zorgen, omdat hij absoluut is gepositioneerd. Gewoon helemaal weglaten dus.
a#skippy:focus{left: 10.5em;} Geen wijziging nodig.
a#skippy:active{left: 10.5em;border: red solid 4px;} Deze css geldt alleen voor Internet Explorer 7. Nodig om bug te omzeilen.
h1{position: fixed;top: 5px;right: 8.5em;left: 8.5em;z-index: 20;margin: 0;font-size: 1.3em;font-weight: normal;text-align: center;} h1{position: static;     font-size: 20pt;font-weight: bold; } Fixed positie levert bij printen enorme problemen op.
pt is de beste eenheid voor een printer.
Op papier staat vet beter.
div#header{z-index: 3;position: fixed;top: 0;left: 0;width: 100%;height: 4.8em;border-bottom: black solid 1px;border-top: black solid 1px;text-align: center;background: #ccc; } div#header{           display: none;} De header heeft een fixed positie. Dat zorgt voor problemen en op papier heb je er toch niets aan, dus niet printen.
div#header ul{list-style-type: none;margin: 0;padding: 0;} Valt binnen div#header en wordt dus niet geprint, omdat div#header bij het printen display: none; heeft.
ul#header-l-2{position: relative;float: left;width: 10.5em;height: 4.8em;margin: 0 3px 0 0;border-right: solid black 1px;border-left: solid black 1px;line-height: 2.4em;background: #eee;z-index: 1001;} Valt binnen div#header en wordt dus niet geprint, omdat div#header bij het printen display: none; heeft.
ul#header-l-2 li + li{border-top: #aaa solid 1px;} Valt binnen div#header en wordt dus niet geprint, omdat div#header bij het printen display: none; heeft.
div#header-r{position: relative;float: right;width: 10.5em; height: 4.8em;margin: 0 0 0 3px;border-left: solid black 1px;border-right: solid black 1px;line-height: 1.6em;background: #eee;z-index: 1000;} Valt binnen div#header en wordt dus niet geprint, omdat div#header bij het printen display: none; heeft.
div#header-i span#nep-link{text-decoration: underline;color: #00e;cursor: pointer;} Valt binnen div#header en wordt dus niet geprint, omdat div#header bij het printen display: none; heeft.
div#inhoud-art{position: absolute;top: -2000px;right: 0;width: 29em;max-height: 380px;border: black solid 2px;padding: 0 5px 5px 60px;text-align: left;font-size: 0.9em;line-height: 1.2em;background: white;color: black;overflow: auto;z-index: 1100;} Valt binnen div#header en wordt dus niet geprint, omdat div#header bij het printen display: none; heeft.
div#inhoud-art ul#inhoud-code-artikel{text-indent: -50px;} Valt binnen div#header en wordt dus niet geprint, omdat div#header bij het printen display: none; heeft.
div#header-i:hover div#inhoud-art, div#header-i:focus div#inhoud-art{top: 5.2em;} Valt binnen div#header en wordt dus niet geprint, omdat div#header bij het printen display: none; heeft.
div#header-i div#inhoud-art h2{margin: 0 0 10px -55px;font-size: 1.0em;} Valt binnen div#header en wordt dus niet geprint, omdat div#header bij het printen display: none; heeft.
div#header-i div#inhoud-art p{margin: 0;text-indent: -55px;} Valt binnen div#header en wordt dus niet geprint, omdat div#header bij het printen display: none; heeft.
div#header-i ul#inhoud-code-artikel{padding-bottom: 30px;} Valt binnen div#header en wordt dus niet geprint, omdat div#header bij het printen display: none; heeft.
div#header-i ul#inhoud-code-artikel p{text-indent: -53px;} Valt binnen div#header en wordt dus niet geprint, omdat div#header bij het printen display: none; heeft.
div#openhouden{position: absolute;top: 0;right: 0;width: 15em;border: red solid;border-width: 0 0 1px 1px;padding: 3px 17px 3px 3px;font-size: 0.8em;line-height: 1.1em;} Valt binnen div#header en wordt dus niet geprint, omdat div#header bij het printen display: none; heeft.
div#openhouden{display: none;} Deze css geldt alleen voor Internet Explorer 7. Nodig om bug te omzeilen.
.printkop{display: none;   } .printkop{display: block;margin-bottom: 30px;font-size: 40pt;text-align: center;} Wordt alleen geprint, niet op het scherm getoond.
Verder nog wat css voor de opmaak.
abbr[title]{border-bottom: dotted black 1px;} abbr[title]{border: 0; } De stippellijn geeft aan dat bij hoveren de volledige afkorting verschijnt. Heb je op papier niets aan.
abbr[title]:after{content: " (" attr(title) ") ";} Als de afkorting een titel heeft, dan deze tussen haakjes achter de afkorting zetten.
img{border: 0;} Geen wijziging nodig.
p{margin: 0;margin-bottom: 8px;text-indent: 20px;  } p{ margin-bottom: 0; widows: 2;orphans: 2;} Marge onderaan is niet nodig op papier, dus alleen maar papierverspilling.
Minimaal twee regels aan boven- en onderkant van papier.
div#uitleg-content{width: 750px;margin: 0 auto;border: black solid 1px;padding: 5.8em 10px 30px 10px;background: white;} div#uitleg-content{width: auto; border: 0;padding: 0;  } Volle breedte papier gebruiken.
Zwarte rand slaat op papier nergens op.
Padding aan de buitenkant is overbodig, papier heeft al 'n marge.
.kader{border: red solid 2px;padding: 5px; } .kader, td{  page-break-inside: avoid;} Teksten binnen kadertjes en cellen van een tabel op één bladzijde houden.
.naar-links{border: black solid 1px;margin: 20px 0;padding: 3px;font-size: 0.8em;text-align: center;background: #fdd; } .naar-links{      display: none;} Link naar de pagina met links is op papier nutteloos, dus niet afdrukken.
p#herzien, p.onderschrift{clear: both;text-indent: 0;font-size: 0.8em;} p#herzien, p.onderschrift{  font-size: 10pt;} pt is de beste maat voor een printer.
.anker{padding-top: 4.8em;margin-top: -4.8em;} div.anker{padding-top: 0;margin-top: 0;} Is op het scherm nodig voor ankers binnen pagina, maar geeft problemen bij printen.
'div' in selector is nodig voor meer gewicht.
h2{margin-top: 2em;} Geen wijziging nodig.
h2{padding-top: 3.5em;margin-top: -1.5em;} Deze css geldt alleen voor Internet Explorer 7. Nodig om bug te omzeilen.
div#a-kolommen h2{margin-top: 0;} Geen wijziging nodig.
div#a-kolommen h2{padding-top: 0;} Deze css geldt alleen voor Internet Explorer 7. Nodig om bug te omzeilen.
h2#hoofd-kop{margin: 30px 0;} Geen wijziging nodig.
h2 span:not([lang="en"]){font-weight: normal;font-size: 0.6em;} h2 span:not([lang="en"]){ font-size: 10pt;} pt is de beste eenheid voor de printer.
code{font-family: "Times New Roman", Georgia, "Bitstream Charter", "Century Schoolbook L", "Liberation Serif", Times, serif;font-size: 1.2em;line-height: 1em;color: #8f4700;} code{font-family: "Lucida Console", "Andale Mono", monospaced;   font-size: 12pt;  } Niet-proportioneel font gebruiken voor code.
pt is de beste eenheid voor de printer.
code.los{display: block;margin: 5px 0 5px 60px;text-indent: -40px;} Geen wijziging nodig.
div.demo-4{line-height: 60px;word-spacing: -5px; } div.demo-4{  width: 16.5cm;} Met 'grof geweld' voorbeelden van letters op hun plaats houden.
div.onderschrift-4{width: 16.5cm;} Met 'grof geweld' onderschriften bij letters van hierboven op hun plaats houden.
div.demo-4 span, div.onderschrift-4 span{width: 4cm;} Met 'grof geweld' onderschriften bij letters van hierboven gelijkmatig verdelen.
span.schreef{display: inline-block;width: 185px;font-size: 72px;font-family: Georgia, serif;text-align: center;} span.schreef{  font-size: 54pt;  } pt is de beste eenheid voor de printer.
span#zonder{font-family: sans-serif;} Geen wijziging nodig.
span.prop{display: inline-block;width: 178px;overflow: hidden;font-size: 24px;font-family: "Lucida Console", "Andale Mono", monospaced;} span.prop{   font-size: 18pt;   } pt is de beste eenheid voor de printer.
span#proportioneel{margin-left: 9px;font-family: Georgia, serif;} Geen wijziging nodig.
div.onderschrift-4{margin-top: -1.2em;text-align: center;font-size: 13px;font-style: italic;} div.onderschrift-4{  font-size: 10pt; } pt is de beste eenheid voor de printer.
div.onderschrift-4 span{display: inline-block;width: 24.4%;} Geen wijziging nodig.
p.kopje{margin: 20px 0 0;} Geen wijziging nodig.
h3, h4{margin-bottom: 0;font-weight: normal;font-variant: small-caps;} Geen wijziging nodig.
.print-url{display: none;  } .print-url{display: inline;font-size: 8pt;text-decoration: underline;} url niet tonen op het scherm, maar wel op de afdruk.
Verder wat css voor de opmaak.
img.links{float: left;} img.links{float: none;} Floaten levert problemen op bij het afdrukken.
img.rechts{float: right;} img.rechts{float: none;} Floaten levert problemen op bij het afdrukken.
div#a-kolommen{padding-top: 8em;-moz-column-count: 3;-webkit-column-count: 3;column-count: 3;-moz-column-gap: 10px;-webkit-column-gap: 10px;column-gap: 15px;-moz-column-rule: black solid 1px;-webkit-column-rule: black solid 1px;column-rule: black solid 1px;} Geen wijziging nodig.
div#breedte{width: 300px;margin: 0 auto;} div#breedte{width: auto; } Bij printen volle breedte papier gebruiken.
div#te-breed{width: 300px;overflow: auto;margin: 0 auto;} Geen wijziging nodig.
div#te-breed p{width: 500px;} Geen wijziging nodig.
div#te-hoog, div#te-hoog-print{height: 150px;overflow: auto;margin: 20px 0;text-align: center;} div#te-hoog-print{height: auto;    } Anders valt het deel van de inhoud, dat te hoog is voor de div, weg.
div#een-landschap{width: 750px;overflow: auto;} Geen wijziging nodig.
div#een-landschap table{width: 1600px;    } div#een-landschap table{ -o-transform: rotate(90deg);page-break-before: always;page-break-after: always;} In Opera tabel in landschap-mode afdrukken.
In alle printers voor en na tabel nieuwe pagina.
div#een-landschap table {filter:progid:
DXImageTransform.
Microsoft.BasicImage
(rotation=3);
width: 100%;}
Deze css is alleen voor Internet Explorer 7. Zorgt dat een tabel in landschap-mode wordt afgedrukt.
div#een-landschap table th{height: 1.2em;border: black solid 1px;text-align: center;} Geen wijziging nodig.
div#een-landschap table td{border: black solid 1px;padding-left: 5px;} Geen wijziging nodig.
div#a-tabellen table{width: 100%;border-collapse: collapse;} Geen wijziging nodig.
div#a-tabellen table td{width: 33%;border: black solid 1px;padding: 2px 5px;} Geen wijziging nodig.
div#a-tabellen table span{display: block;margin-left: 30px;text-indent: -15px;} Geen wijziging nodig.
div#a-tabellen table td span:first-child{margin-left: 15px;text-indent: -15px;} Geen wijziging nodig.
tr.ie-7{font-style: italic;} Geen wijziging nodig.
p#warchild-art{margin-top: 30px;} Geen wijziging nodig.
p#warchild-art a:after{content: " " attr(href);} url volledig afdrukken. Op het scherm is deze link een afbeelding.
p#warchild-art img{display: block;max-width: 100%;margin: 0 auto;padding-bottom: 30px;} p#warchild-art img{display: none;   } Afbeelding is een link, heeft dus op papier geen enkel nut.
a{text-decoration: none;color: black;} Algemene instelling voor links.
Niet onderstrepen.
Gewone zwarte tekst.
.niet-printen{display: none;} Voor elementen die niet geprint moeten worden.
.link-streep, .print-href{text-decoration: underline;} Links met deze classes wel onderstrepen.
a.print-href:after{content: " <<" attr(href) ">> ";font-size: 8pt;} Na links met deze class volledige url uitprinten tussen << en >>.
Iets kleinere letter.
p.kader a[href^="http"]:after, div#print-http a[href^="http"]:after, div#a-algemeen a[href^="http"]:after{content: " <<" attr(href) ">> ";font-size: 8pt;} Als link begint met 'http' de url volledig uitprinten.
Iets kleinere letter
Beide alleen binnen de paragraaf met class="kader" en de divs met id="print-http" en id="a-algemeen"
div#print-http a[href^="http"]{text-decoration: underline;} Als link begint met 'http' link onderstrepen, maar alleen binnen de divs met id="print-http" en id="a-algemeen"
div#a-content, div#a-landschap{page-break-after: always;} Nieuwe pagina beginnen na div#a-content en div#a-landschap.
div#a-geen-nieuwe{page-break-before: always;} Nieuwe pagina beginnen voor div#a-geen-nieuwe.

Iets gevonden waar je wat aan hebt? Mooi. Als je je waardering wilt uiten, maak dan een donatie over aan War Child Nederland, een organisatie die kinderen uit oorlogsgebieden helpt hun trauma's te verwerken. Of - nog beter - wordt donateur:War Child Nederland