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

Merged

brenno merged 1 commit from fix/voetnootplaatsing-reist-mee into main

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

brenno commented

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

Owner

Sluit #1569.

Wat er mis was

Koos je Voetnoten achterin het document, dan stond die keuze wel in je eigen bestand maar niet in de kopie die de deur uit ging. De ontvanger kreeg de noten op de plek die zíjn lezer koos.

De oorzaak is de vorm van het exportpad en niet een vergissing in de logica: writeDocumentExport vertrekt vanuit de geprojecteerde body, en die draagt per constructie geen front matter meer. Voor de paginaopmaak werd dat al opgevangen (#1544); voor reference-location: niet.

Waarom hij hoort mee te reizen

§14.4 hakt de knoop door met een onderscheid dat klopt: een maat reist mee, een verwijzing niet. theme: wijst naar een stijlprofiel dat alleen op deze machine bestaat — bij de ontvanger wijst die naam nergens naar, of erger, naar iets anders met dezelfde naam. reference-location: is een instructie die Pandoc en Quarto zélf uitvoeren en die overal hetzelfde betekent. Dat is een maat, en dus reist hij mee.

De standaard schrijft nog steeds niets

Dat was de open keuze in de issue, en de code besliste hem eigenlijk al: withDocumentFootnotePlacement schrijft niets voor "onderaan de bladzijde", omdat dát is wat elke lezer zonder aanwijzing al doet. De export hergebruikt die functie in plaats van de regel over te schrijven, dus een document dat niets bijzonders wil, wordt nog altijd zonder front matter geëxporteerd — de belofte die §14.9 over de bron doet, geldt zo ook voor de kopie.

Getoetst

Drie tests in document_export_write_test.dart, waarvan twee eerst rood gezien tegen de onherstelde code (de fix tijdelijk teruggedraaid met een tekstbewerking, niet met git — er stond ongecommit werk in dezelfde boom):

de keuze komt terug in het geëxporteerde .md en is er terug uit te lezen met documentFootnotePlacement, niet alleen tekstueel aanwezig;
de standaardplaatsing schrijft geen sleutel — die bleef groen, want het is de bewaker tegen tevéél schrijven;
paginaopmaak en notenplaatsing belanden in één front-matterblok, niet twee.

make check volledig groen; make check-secrets en make sast gedraaid.

Documentatie

§14.4 stond sinds vanochtend op het tegenovergestelde, met de kanttekening dat het een open eind was in plaats van een besluit. Daar staat nu het besluit, met de correctie op de record zoals de rest van §14 dat doet. §14.9 noemt het in één zin. Beide talen bij, wat de poort uit #1576 nu ook afdwingt.

Sluit #1569. ## Wat er mis was Koos je *Voetnoten achterin het document*, dan stond die keuze wel in je eigen bestand maar niet in de kopie die de deur uit ging. De ontvanger kreeg de noten op de plek die zíjn lezer koos. De oorzaak is de vorm van het exportpad en niet een vergissing in de logica: `writeDocumentExport` vertrekt vanuit de geprojecteerde *body*, en die draagt per constructie geen front matter meer. Voor de paginaopmaak werd dat al opgevangen (#1544); voor `reference-location:` niet. ## Waarom hij hoort mee te reizen §14.4 hakt de knoop door met een onderscheid dat klopt: een **maat** reist mee, een **verwijzing** niet. `theme:` wijst naar een stijlprofiel dat alleen op deze machine bestaat — bij de ontvanger wijst die naam nergens naar, of erger, naar iets anders met dezelfde naam. `reference-location:` is een instructie die Pandoc en Quarto zélf uitvoeren en die overal hetzelfde betekent. Dat is een maat, en dus reist hij mee. ## De standaard schrijft nog steeds niets Dat was de open keuze in de issue, en de code besliste hem eigenlijk al: `withDocumentFootnotePlacement` schrijft niets voor "onderaan de bladzijde", omdat dát is wat elke lezer zonder aanwijzing al doet. De export hergebruikt die functie in plaats van de regel over te schrijven, dus een document dat niets bijzonders wil, wordt nog altijd zonder front matter geëxporteerd — de belofte die §14.9 over de bron doet, geldt zo ook voor de kopie. ## Getoetst Drie tests in `document_export_write_test.dart`, waarvan **twee eerst rood gezien** tegen de onherstelde code (de fix tijdelijk teruggedraaid met een tekstbewerking, niet met git — er stond ongecommit werk in dezelfde boom): - de keuze komt terug in het geëxporteerde `.md` **en is er terug uit te lezen** met `documentFootnotePlacement`, niet alleen tekstueel aanwezig; - de standaardplaatsing schrijft geen sleutel — die bleef groen, want het is de bewaker tegen tevéél schrijven; - paginaopmaak en notenplaatsing belanden in **één** front-matterblok, niet twee. `make check` volledig groen; `make check-secrets` en `make sast` gedraaid. ## Documentatie §14.4 stond sinds vanochtend op het tegenovergestelde, met de kanttekening dat het een open eind was in plaats van een besluit. Daar staat nu het besluit, met de correctie op de record zoals de rest van §14 dat doet. §14.9 noemt het in één zin. Beide talen bij, wat de poort uit #1576 nu ook afdwingt.

brenno added 1 commit

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

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

scans / scans (pull_request) Successful in 1m51s

Details

static-gate / static-gate (pull_request) Successful in 4m27s

Details

45856025e6

Koos je *Voetnoten achterin het document*, dan stond die keuze wel in je eigen
bestand maar niet in de kopie die de deur uit ging. De oorzaak is de vorm van het
exportpad en niet een vergissing in de logica: `writeDocumentExport` vertrekt
vanuit de geprojecteerde *body*, en die draagt per constructie geen front matter
meer. Voor de paginaopmaak werd dat al opgevangen (#1544); voor
`reference-location:` niet.

Nu wel, en om dezelfde reden. §14.4 hakt de knoop door met een onderscheid dat
klopt: een maat reist mee, een verwijzing niet. `theme:` wijst naar een profiel
dat alleen op deze machine bestaat; `reference-location:` is een instructie die
Pandoc en Quarto zélf uitvoeren en die overal hetzelfde betekent. Dat is een
maat.

De standaard schrijft nog steeds niets. Onderaan de bladzijde is wat elke lezer
zonder aanwijzing al doet, dus een document dat niets bijzonders wil houdt een
export zonder front matter — de belofte die §14.9 over de bron doet, geldt zo ook
voor de kopie. Die regel zat al in `withDocumentFootnotePlacement`; de export
hergebruikt hem in plaats van hem over te schrijven.

Drie tests, waarvan twee eerst rood gezien tegen de onherstelde code: de keuze
komt terug én is terug te lézen uit het bestand, de standaard schrijft geen
sleutel, en paginaopmaak en notenplaatsing belanden in één front-matterblok in
plaats van twee.

FILE_FORMAT §14.4 stond op het tegenovergestelde, met de kanttekening dat het een
open eind was; daar staat nu het besluit, met de correctie op de record. §14.9
noemt het in één zin. Beide talen bij.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

brenno merged commit 7f3accebed into main

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

brenno referenced this pull request from a commit

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

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

brenno referenced this pull request

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

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