feat(export): laat de voetnootplaatsing meereizen in het geprojecteerde .md

brenno commented

2026-08-19 08:55:48 +00:00

Owner

Gevonden bij het gelijktrekken van FILE_FORMAT met de code (#1568). Het staat daar nu als open eind in §14.4; dit is de plek om het op te lossen of bewust te laten.

Wat er nu gebeurt

Een document mag de plaatsing van zijn voetnoten vastleggen met reference-location: in de front matter (§14.9): achteraan het document, of onderaan de bladzijde waar de verwijzing op valt. Bij het exporteren naar een geprojecteerd .md verdwijnt die keuze. De noten zelf reizen wél mee — dat is gewone tekst in de body — maar de ontvanger krijgt ze op de plek die zíjn lezer kiest.

De oorzaak is niet een vergissing in de logica maar de vorm van het exportpad: writeDocumentExport vertrekt vanuit projectedDocumentBody(bundle), en dat is de body van het geprojecteerde deck. De front matter van de bron komt daar per constructie niet in voor. De paginaopmaak wordt daarom expliciet weer aangezet (withDocumentPageSetup, sinds #1544); voor reference-location: gebeurt dat niet.

Waarom het volgens onze eigen redenering wél mee zou moeten

§14.4 hakt de knoop door met een onderscheid dat ik goed vind: een maat reist mee, een verwijzing niet. theme: is een verwijzing naar een profiel dat alleen op deze machine bestaat, dus die blijft thuis en wordt vóór de export opgelost. papersize:/geometry: zijn millimeters die overal hetzelfde betekenen, dus die reizen.

reference-location: valt aan de kant van de maat. Het is een Pandoc- en Quarto-sleutel die die gereedschappen echt uitvoeren, hij verwijst nergens naar, en hij beschrijft — net als een afloop — een eigenschap van dít stuk drukwerk en niet een voorkeur van de lezer. Wie zijn noten achterin wil, wil ze ook achterin bij de ontvanger.

Voorgestelde vorm

In de md-tak van writeDocumentExport, naast de bestaande withDocumentPageSetup-aanroep, de geldende plaatsing terugschrijven met withDocumentFrontMatterKey(out, 'reference-location', …). De sleutel staat al in kDocumentOwnedKeys, dus de assert laat het toe en er is geen nieuw vocabulaire nodig.

Twee dingen om bij het bouwen te wegen:

Alleen schrijven wat afwijkt, of altijd? Bij de paginaopmaak is gekozen voor "altijd, ook als het uit de instellingen kwam", omdat de ontvanger die instellingen niet heeft. Bij voetnoten is de standaard (onderaan de bladzijde) juist de standaard van Pandoc zelf, dus daar valt iets voor te zeggen om alleen document te schrijven en de standaard stil te laten. Dat scheelt front matter in een bestand dat anders geen front matter had — en §14.9 belooft nu net dat de standaard níets schrijft.
De HTML-export verandert niet. Die zet noten altijd achteraan, omdat een HTML-pagina geen bladzijden heeft (KNOWN_LIMITATIONS). Dit gaat alleen over de .md-uitvoer; de LaTeX-uitvoer honoreert de plaatsing al direct.

Klaar wanneer

Een document met reference-location: document levert een geprojecteerd .md op dat die sleutel draagt, en een document zonder de sleutel levert (bij de gekozen variant hierboven) geen front matter waar het er geen had.
Een test in de trant van document_export_page_size_test.dart, die dezelfde weg voor de voetnootsleutel afloopt.
FILE_FORMAT §14.4 en §14.9 bijgewerkt: het open eind is dan geen open eind meer, en dat hoort op de record zoals de rest van §14 dat doet.

Gevonden bij het gelijktrekken van FILE_FORMAT met de code (#1568). Het staat daar nu als open eind in §14.4; dit is de plek om het op te lossen of bewust te laten. ## Wat er nu gebeurt Een document mag de plaatsing van zijn voetnoten vastleggen met `reference-location:` in de front matter (§14.9): achteraan het document, of onderaan de bladzijde waar de verwijzing op valt. Bij het exporteren naar een geprojecteerd `.md` verdwijnt die keuze. De noten zelf reizen wél mee — dat is gewone tekst in de body — maar de ontvanger krijgt ze op de plek die zíjn lezer kiest. De oorzaak is niet een vergissing in de logica maar de vorm van het exportpad: `writeDocumentExport` vertrekt vanuit `projectedDocumentBody(bundle)`, en dat is de *body* van het geprojecteerde deck. De front matter van de bron komt daar per constructie niet in voor. De paginaopmaak wordt daarom expliciet weer aangezet (`withDocumentPageSetup`, sinds #1544); voor `reference-location:` gebeurt dat niet. ## Waarom het volgens onze eigen redenering wél mee zou moeten §14.4 hakt de knoop door met een onderscheid dat ik goed vind: een **maat** reist mee, een **verwijzing** niet. `theme:` is een verwijzing naar een profiel dat alleen op deze machine bestaat, dus die blijft thuis en wordt vóór de export opgelost. `papersize:`/`geometry:` zijn millimeters die overal hetzelfde betekenen, dus die reizen. `reference-location:` valt aan de kant van de maat. Het is een Pandoc- en Quarto-sleutel die die gereedschappen echt uitvoeren, hij verwijst nergens naar, en hij beschrijft — net als een afloop — een eigenschap van dít stuk drukwerk en niet een voorkeur van de lezer. Wie zijn noten achterin wil, wil ze ook achterin bij de ontvanger. ## Voorgestelde vorm In de `md`-tak van `writeDocumentExport`, naast de bestaande `withDocumentPageSetup`-aanroep, de geldende plaatsing terugschrijven met `withDocumentFrontMatterKey(out, 'reference-location', …)`. De sleutel staat al in `kDocumentOwnedKeys`, dus de assert laat het toe en er is geen nieuw vocabulaire nodig. Twee dingen om bij het bouwen te wegen: - **Alleen schrijven wat afwijkt, of altijd?** Bij de paginaopmaak is gekozen voor "altijd, ook als het uit de instellingen kwam", omdat de ontvanger die instellingen niet heeft. Bij voetnoten is de standaard (onderaan de bladzijde) juist de standaard van Pandoc zelf, dus daar valt iets voor te zeggen om alleen `document` te schrijven en de standaard stil te laten. Dat scheelt front matter in een bestand dat anders geen front matter had — en §14.9 belooft nu net dat de standaard níets schrijft. - **De HTML-export verandert niet.** Die zet noten altijd achteraan, omdat een HTML-pagina geen bladzijden heeft (KNOWN_LIMITATIONS). Dit gaat alleen over de `.md`-uitvoer; de LaTeX-uitvoer honoreert de plaatsing al direct. ## Klaar wanneer - Een document met `reference-location: document` levert een geprojecteerd `.md` op dat die sleutel draagt, en een document zonder de sleutel levert (bij de gekozen variant hierboven) geen front matter waar het er geen had. - Een test in de trant van `document_export_page_size_test.dart`, die dezelfde weg voor de voetnootsleutel afloopt. - FILE_FORMAT §14.4 en §14.9 bijgewerkt: het open eind is dan geen open eind meer, en dat hoort op de record zoals de rest van §14 dat doet.

brenno added the

enhancement

label

2026-08-19 08:55:48 +00:00

brenno referenced this issue from a commit

2026-08-19 08:56:17 +00:00

docs(bestandsformaat): het open eind in §14.4 wijst naar zijn issue

brenno referenced this issue

2026-08-19 08:56:24 +00:00

docs(bestandsformaat): het open eind in §14.4 wijst naar zijn issue #1570

brenno added the

in-progress

label

2026-08-19 13:20:10 +00:00

brenno commented

2026-08-19 13:20:11 +00:00

Author

Owner

Opgepakt op tak fix/voetnootplaatsing-reist-mee.

De keuze die in de issue open stond — altijd schrijven, of alleen de afwijkende waarde — beslist de code eigenlijk zelf al: withDocumentFootnotePlacement schrijft niets voor page, omdat onderaan-de-bladzijde is wat elke lezer zonder aanwijzing al doet. De export volgt diezelfde regel, dus een document zonder noten-achterin krijgt geen front matter waar het er geen had (§14.9).

Opgepakt op tak `fix/voetnootplaatsing-reist-mee`. De keuze die in de issue open stond — altijd schrijven, of alleen de afwijkende waarde — beslist de code eigenlijk zelf al: `withDocumentFootnotePlacement` schrijft niets voor `page`, omdat onderaan-de-bladzijde is wat elke lezer zonder aanwijzing al doet. De export volgt diezelfde regel, dus een document zonder noten-achterin krijgt geen front matter waar het er geen had (§14.9).

brenno referenced this issue from a commit

2026-08-19 13:35:00 +00:00

fix(export): de voetnootplaatsing reist mee in het geprojecteerde .md (#1569)

brenno referenced this issue

2026-08-19 13:35:23 +00:00

fix(export): de voetnootplaatsing reist mee in het geprojecteerde .md #1581

brenno commented

2026-08-19 13:40:30 +00:00

Author

Owner

Gebouwd en gemerged in #1581 (7f3acceb).

De export schrijft reference-location: opnieuw in het geprojecteerde .md, om dezelfde reden als de paginaopmaak: het is een instructie die Pandoc en Quarto zelf uitvoeren, dus een maat en geen verwijzing. De standaard blijft niets schrijven — noten onderaan de bladzijde is wat elke lezer uit zichzelf al doet, dus een document dat niets bijzonders wil wordt nog altijd zonder front matter geëxporteerd.

Drie tests, waarvan twee eerst rood tegen de onherstelde code. FILE_FORMAT §14.4 stond op het tegenovergestelde en is omgedraaid, met de correctie op de record; §14.9 noemt het nu ook. Beide talen bij.

Gebouwd en gemerged in #1581 (`7f3acceb`). De export schrijft `reference-location:` opnieuw in het geprojecteerde `.md`, om dezelfde reden als de paginaopmaak: het is een instructie die Pandoc en Quarto zelf uitvoeren, dus een maat en geen verwijzing. De standaard blijft niets schrijven — noten onderaan de bladzijde is wat elke lezer uit zichzelf al doet, dus een document dat niets bijzonders wil wordt nog altijd zonder front matter geëxporteerd. Drie tests, waarvan twee eerst rood tegen de onherstelde code. FILE_FORMAT §14.4 stond op het tegenovergestelde en is omgedraaid, met de correctie op de record; §14.9 noemt het nu ook. Beide talen bij.

brenno

2026-08-19 13:40:30 +00:00

closed this issue
removed the
in-progress
label

Rows
Columns

feat(export): laat de voetnootplaatsing meereizen in het geprojecteerde .md #1569

Wat er nu gebeurt

Waarom het volgens onze eigen redenering wél mee zou moeten

Voorgestelde vorm

Klaar wanneer