Pagina-einde in Markdown voor PDF: begin een nieuwe pagina precies waar jij wilt

Waarom Markdown geen pagina-einde kent

Markdown is geschreven voor het web, en een webpagina heeft geen pagina's. Noch de oorspronkelijke syntax noch CommonMark definieert een pagina-einde. Het dichtst in de buurt komt een regel met drie streepjes ---, een thematische scheiding: die wordt een <hr>-lijn, geen nieuwe pagina. Veel mensen proberen die eerst als pagina-einde en vragen zich dan af waarom er niets gebeurt.

Wat Markdown wel toestaat, is ruwe HTML. De meeste exporters zetten Markdown eerst om in HTML en printen die HTML dan als PDF; een pagina-einde is dus eigenlijk een CSS-regel op een HTML-element. De uitzondering is de standaardroute van Pandoc, die via LaTeX loopt en in plaats daarvan een LaTeX-commando verwacht.

Snippets voor een pagina-einde die werken

Kies de regel die bij jouw exporter past en zet hem op een eigen regel, met een lege regel ervoor en erna, zodat de Markdown-parser hem als HTML-blok behandelt:

Last paragraph of the first part.

<div style="page-break-after: always"></div>

## Part two

This heading starts a new page.

• Modern CSS: <div style="break-after: page"></div>, of break-before: page op het element waarmee de pagina moet beginnen.
• Direct op een kop: <h2 style="page-break-before: always">Deel twee</h2>, als je het niet erg vindt om die kop in HTML te schrijven.
• VS Code-extensie Markdown PDF: de README noemt <div class="page"/>; het stylesheet van de extensie zorgt voor het pagina-einde. Dat is het gebruikelijke antwoord voor VS Code, en de inline-stijl hierboven werkt daar ook.
• Pandoc met LaTeX (de standaardroute naar PDF): een regel met \newpage. De extensie raw_tex geeft die alleen ongewijzigd door aan de writers voor LaTeX en ConTeXt. Het newpage-commando van Pandoc is niet bedoeld voor HTML-uitvoer; gebruik je een HTML-engine voor de PDF, neem dan de div.

Waarom twee namen? De CSS-specificatie voor fragmentatie heeft page-break-before en page-break-after vervangen door break-before en break-after en houdt de oude namen als aliassen: page-break-after: always gedraagt zich als break-after: page. De oude vorm is de veiligste keuze voor oudere tools; MDN documenteert beide.

Hoe onze exporter een handmatig pagina-einde behandelt

Tot 19 okt 2026 negeerde onze exporter handmatige pagina-eindes en koos hij elke breuk zelf. Nu leest hij de berekende waarden break-before en break-after van elk element in het gerenderde document, dus een pagina-einde via CSS in een style-attribuut wordt gerespecteerd, in de oude en in de nieuwe schrijfwijze. Het livevoorbeeld tekent een gestippelde lijn met het label 'Pagina-einde' waar de nieuwe pagina begint, en na het exporteren laat een melding zien hoeveel handmatige pagina-eindes zijn toegepast.

Een paar regels houden de uitvoer netjes:

• Een pagina-einde helemaal aan het begin of eind van het document wordt genegeerd, dus je krijgt nooit een lege eerste of laatste pagina.
• Twee pagina-eindes achter elkaar tellen als één. Chrome print er een lege pagina tussen; wij gaan ervan uit dat dat zelden de bedoeling is.
• De waarden left, right, recto en verso beginnen een nieuwe pagina. We voegen geen lege pagina toe om op een linker- of rechterpagina uit te komen.
• --- blijft een horizontale lijn, zoals Markdown het definieert.
• Automatische pagina-eindes gelden nog steeds binnen lange delen en vermijden nog steeds dat een regel, een tabelrij of een afbeelding wordt doorgesneden.

Wat we hebben getest, vergeleken met printen vanuit Chrome

We schreven 9 kleine documenten die elk één schrijfwijze voor een pagina-einde testen, exporteerden ze allemaal met de echte knop PDF downloaden en lazen de pagina's terug met pdfinfo en pdftotext om te zien welke tekst op welke pagina terechtkwam. Ter referentie printten we dezelfde HTML ook met de PDF-printer van Chrome. In onze tests gaven alle 9 gevallen de verwachte pagina's zonder lege pagina's, en 8 van de 9 kwamen pagina voor pagina overeen met Chrome.

Koppen bij hun tekst houden, en andere onhandige breuken

Handmatige pagina-eindes lossen de plekken op die je kent. De rest doet de exporter, en de klassieke fout is een kop die alleen onderaan een pagina staat terwijl de tekst op de volgende begint. Tekstverwerkers noemen de oplossing 'bij volgende alinea houden'. In CSS is de passende regel break-after: avoid op koppen, maar de ondersteuning van de avoid-waarden bij printen verschilt per engine; test dus voordat je erop vertrouwt.

Onze exporter doet dit zonder markup: een kop blijft bij de eerste regel erna, en tabelrijen en afbeeldingen worden niet gesplitst als ze op één pagina passen. Vind je het toch niet mooi waar een pagina eindigt, zet dan direct vóór de kop een handmatig pagina-einde. De afbeelding hieronder laat zien waar een breuk wel en niet kan vallen.

Tabellen vragen extra aandacht. Onze gids over tabellen printen behandelt lange en brede tabellen, en een korte export met MD naar PDF is de snelste manier om een opmaak uit te proberen vóór het echte document.

Veelgemaakte fouten met pagina-eindes

Als een pagina-einde niets doet, ligt het bijna altijd aan een van deze vier punten:

• Geen lege regel na de div. In CommonMark loopt een HTML-blok dat met <div> begint door tot de volgende lege regel. Tekst direct eronder wordt in de HTML opgeslokt en verschijnt zonder opmaak, met ## en ** als letterlijke tekens.
• De div staat in een lijst, citaat of tabel. Zet hem op het hoogste niveau van het document, waar elke exporter hem als eigen blok ziet.
• Ruwe HTML staat uit. Sommige renderers schakelen HTML standaard uit en tonen de tag als tekst. Zet HTML aan in de instellingen of gebruik de eigen pagina-eindesyntax van de tool, als die er een heeft.
• Oordelen op basis van het voorbeeld. Voorbeelden die HTML opschonen halen vaak inline-stijlen weg, waardoor het pagina-einde op het scherm lijkt te ontbreken maar bij het exporteren toch werkt. Ons voorbeeld toont de gestippelde markering, maar de echte test is het geëxporteerde bestand.

Nog een gewoonte die helpt: zet elk handmatig pagina-einde direct boven de kop van het deel dat op een nieuwe pagina moet beginnen, nooit eronder. Zo blijven kop en eerste alinea altijd samen, en als je het pagina-einde later weghaalt, leest het document nog steeds in de juiste volgorde.

Snelle controle voordat je de PDF deelt

1. Scrol door alle pagina's en let op lege pagina's; meestal betekenen die twee pagina-eindes achter elkaar of een pagina-einde aan het eind.
2. Controleer of elk deel bovenaan zijn pagina begint, met de kop eerst.
3. Zoek een woord van de laatste pagina om te bevestigen dat de tekstlaag echt is.
4. Wordt de PDF dubbelzijdig geprint en moeten hoofdstukken rechts beginnen, gebruik dan een tool die break-before: right ondersteunt; de onze behandelt het als een gewone nieuwe pagina.