fix(export): een mislukte export zegt in welke stap hij omviel (#714) #718

Merged

brenno merged 3 commits from fix/pdf-export-invalid-argument-714 into main

2026-07-23 10:15:18 +00:00

brenno commented

2026-07-23 10:15:10 +00:00

Owner

Het derde punt van #714 — "ongeacht de oorzaak verdient de melding zelf een opknapbeurt" — plus de regressiepoort die punt 2 vroeg. De kernoorzaak zit hier niet in; zie onderaan.

De melding. Er stond alleen de kale uitzondering: Invalid argument(s): 1. Dat wijst nergens heen, en het verraadt niet eens of het renderen of het schrijven omviel — alle drie de stappen gooien uit dezelfde try, dus dat verschil was voor niemand te zien. Nu: de stap, wat je eraan kunt doen, en pas dáárna de technische regel. Die blijft staan; hij is het enige waarmee een oorzaak te vinden is.

Bij een gestrand render wijst de melding ook de weg: alleen PDF en PPTX renderen, dus de HTML-export van hetzelfde deck werkt dan meestal wél. Dat is precies de omweg die de melder zelf had gevonden en die de app hem niet vertelde.

De poort. Elk van de vierentwintig diatypes gaat nu door de héle PDF-keten — renderen zoals de app rendert, opbouwen, wegschrijven — plus het viertal uit de melding samen in één deck. De bestaande exporttests voerden een zelfgemaakte PNG in en konden dus niet zien wat één specifiek diatype aan beeldbytes oplevert.

Wat die poort níét bewaakt staat erin: hij draait op 640 px en niet op de 1920 van een echte export, omdat het capturen op exportresolutie onder de testbinding niet klaarkomt.

Wat dit over de bug zegt. De poort is groen. De PDF-export is dus niet altijd stuk en het ligt niet aan een diatype als zodanig — daarmee is vraag 2 uit het issue beantwoord. Wat overblijft is deckafhankelijk, en waarschijnlijk in de renderstap: dat is de stap die PDF en PPTX wél lopen en HTML niet, wat verklaart waarom HTML op hetzelfde deck lukte. Bewezen is dat niet; de nieuwe melding zegt het bij de volgende poging zelf.

Het issue blijft daarvoor open.

Poort: make check groen (5.888 tests).

Refs #714

Het derde punt van #714 — "ongeacht de oorzaak verdient de melding zelf een opknapbeurt" — plus de regressiepoort die punt 2 vroeg. **De kernoorzaak zit hier niet in**; zie onderaan. **De melding.** Er stond alleen de kale uitzondering: `Invalid argument(s): 1`. Dat wijst nergens heen, en het verraadt niet eens of het renderen of het schrijven omviel — alle drie de stappen gooien uit dezelfde `try`, dus dat verschil was voor niemand te zien. Nu: de stap, wat je eraan kunt doen, en pas dáárna de technische regel. Die blijft staan; hij is het enige waarmee een oorzaak te vinden is. Bij een gestrand render wijst de melding ook de weg: alleen PDF en PPTX renderen, dus de HTML-export van hetzelfde deck werkt dan meestal wél. Dat is precies de omweg die de melder zelf had gevonden en die de app hem niet vertelde. **De poort.** Elk van de vierentwintig diatypes gaat nu door de héle PDF-keten — renderen zoals de app rendert, opbouwen, wegschrijven — plus het viertal uit de melding samen in één deck. De bestaande exporttests voerden een zelfgemaakte PNG in en konden dus niet zien wat één specifiek diatype aan beeldbytes oplevert. Wat die poort níét bewaakt staat erin: hij draait op 640 px en niet op de 1920 van een echte export, omdat het capturen op exportresolutie onder de testbinding niet klaarkomt. **Wat dit over de bug zegt.** De poort is groen. De PDF-export is dus niet altijd stuk en het ligt niet aan een diatype als zodanig — daarmee is vraag 2 uit het issue beantwoord. Wat overblijft is deckafhankelijk, en waarschijnlijk in de renderstap: dat is de stap die PDF en PPTX wél lopen en HTML niet, wat verklaart waarom HTML op hetzelfde deck lukte. Bewezen is dat niet; de nieuwe melding zegt het bij de volgende poging zelf. Het issue blijft daarvoor open. Poort: `make check` groen (5.888 tests). Refs #714

brenno added 3 commits

2026-07-23 10:15:10 +00:00

test(export): elk diatype door de héle PDF-keten (#714 ) 459151b496

De bestaande exporttests voeren een zelfgemaakte PNG in. Die vangen wat er ná
het renderen misgaat, maar niet wat één specifiek diatype aan beeldbytes
oplevert — en dat is precies waar #714 zit: reproduceerbaar op een deck met
bevindings-, checklist-, scopematrix- en bevindingenoverzichtdia's, terwijl de
HTML-export van hetzelfde deck lukt.

Deze poort rendert elk van de vierentwintig types zoals de app dat doet en laat
er een echte PDF van schrijven, plus het viertal uit de melding samen in één
deck. Uitkomst: allemaal groen. Daarmee is jouw tweede vraag beantwoord — de
PDF-export is niet altijd stuk, en de oorzaak zit niet in een diatype als
zodanig.

Wat de poort níét bewaakt staat erin: hij draait op 640 px en niet op de 1920
van een echte export, omdat het capturen op exportresolutie onder de
testbinding niet klaarkomt ("did not complete", gemeten).

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

fix(export): een mislukte export zegt in welke stap hij omviel (#714 ) 0dd8b72507

Er stond alleen de kale uitzondering in het venster. Bij #714 was dat letterlijk
`Invalid argument(s): 1` — dat wijst nergens heen, en het verraadt niet eens of
het renderen of het schrijven omviel. Alle drie de stappen gooien uit dezelfde
`try`, dus dat verschil was voor niemand te zien: niet voor de gebruiker, en
niet voor wie de melding later leest.

Nu: de stap, wat je eraan kunt doen, en pas dáárna de technische regel. Die
blijft staan — hij is het enige waarmee een fout te vinden is, en hij hoort in
een foutrapport. Bij een gestrand render wijst de melding ook de weg: alleen
PDF en PPTX renderen, dus de HTML-export van hetzelfde deck werkt dan meestal
wél. Dat is de omweg die de melder zelf had gevonden en die de app hem niet
vertelde.

De tekstkeuze staat buiten het venster (`export_failure_text.dart`): het is
pure logica zonder toestand, het houdt _ExportDialogState onder zijn plafond,
en het is zo te toetsen zonder een dialoog te openen.

Eén ding om te weten voor de volgende die hieraan komt: de schrijfstap zegt
bewust niet "samenstellen". Dat woord is in export_dialog_error_test.dart de
vlag voor "het dialoog hangt nog", en een foutmelding die hem herhaalt zou die
toets stilletjes waardeloos maken. Staat als commentaar bij de string.

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

docs: de exportmelding noemt zijn stap (#714 ) a5baa9163e

CHANGELOG, SOURCE_MAP en de probleemoplossingsgids. Die laatste zegt ook waarom
het onderscheid de diagnose ís: alleen PDF en PPTX renderen, dus een fout in de
renderstap gaat over een dia en niet over het formaat — en de technische regel
is het enige deel dat een oorzaak aanwijst, dus die hoort in een melding
geciteerd te worden.

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

brenno merged commit 3dda7ad6ad into main

2026-07-23 10:15:18 +00:00

brenno referenced this pull request from a commit

2026-07-23 10:15:19 +00:00

Merge pull request 'fix(export): een mislukte export zegt in welke stap hij omviel (#714)' (#718) from fix/pdf-export-invalid-argument-714 into main

brenno referenced this pull request

2026-07-23 10:15:51 +00:00

[Bug] PDF-export mislukt met "Invalid argument(s): 1" #714

brenno referenced this pull request from a commit

2026-07-23 17:00:43 +00:00

test(export): de PDF-poort op echte exportbreedte en door het compressiepad (#714)

brenno referenced this pull request