De tekeningen in een document-PDF houden zich aan de grenzen van het platform #1615

Merged

brenno merged 1 commit from fix/pdf-tekeningen-platformgrenzen into main

2026-08-20 16:28:12 +00:00

brenno commented

2026-08-20 16:22:53 +00:00

Owner

Op de vraag of de tekeningen uit #1612 ook op web en Windows werken was het antwoord twee keer nee — en één daarvan is een regressie die ik daar zelf in heb gezet.

Windows en Linux: een regressie

Er zit geen WebView-implementatie voor die platformen in dit project. pubspec.lock kent webview_flutter_android, webview_flutter_wkwebview en webview_flutter_web; voor Windows en Linux is er niets.

Het exportpad van #1612 vroeg daar tóch om een diagramrender. Dat zet hostNeeded aan, de host bouwt een WebViewController op een platform zonder implementatie, en dat gooit. Een document met één mermaid-diagram exporteerde daar eerst gewoon.

De dienst vraagt nu eerst isAvailable en geeft anders meteen niets terug. Het diagram valt dan terug op zijn bron — zoals bedoeld — en zonder de twintig seconden wachten per diagram die het plafond anders had gekost. Grafieken worden in Dart getekend en reizen wél op elk platform mee.

Web: al langer stuk, en stil

Daar werkt de documentexport helemaal niet, en niet alleen de PDF. pickDocumentExportDestination roept FilePicker.saveFile aan zonder bytes, en de webimplementatie gooit dan een ArgumentError ("The bytes are required when saving a file on the web"). Er zat nergens een try omheen, dus kwam setState nooit en bleef de knop eeuwig op zijn tolletje staan — zonder één woord uitleg, in alle vier de formaten, al sinds de documentexport bestaat.

De dialoog zegt nu dat het niet gelukt is, met de reden erbij, en laat het document ongemoeid. Het wél laten wérken op web betekent de klaargemaakte bytes als download aan de browser geven; dat is een eigen wijziging en staat als zodanig in KNOWN_LIMITATIONS.

Een vangst die te smal was

Allebei de vangsten zijn verbreed van on Exception naar een benoemde catch. ArgumentError ís een Error, geen Exception — een vangst op Exception had hem laten lopen en de knop alsnog laten draaien. Om precies dezelfde reden is de vangst rond het plaatsen van een SVG verbreed: een ontleder die op iets onverwachts stuit werpt net zo goed een Error, en voor de uitkomst maakt dat niets uit — het diagram is er niet, dus valt het terug op zijn bron. Kaal is geen van beide; ze loggen wat ze vangen.

Wat de documentatie beweerde

Dat de webversie "de bron zou tonen". Dat was nooit waar — daar komt geen PDF. Rechtgezet in USER_GUIDE (nl + en) en KNOWN_LIMITATIONS (nl + en), mét de datum en de reden van de correctie, zodat te zien is dat de eerdere zin ongemeten was.

Toetsen

make check groen (dekking 87,2%, per-bestand-vloer 0). make check-secrets: geen bevindingen. make sast: 0 findings. DAST niet gedraaid — deze wijziging raakt het geserveerde weboppervlak niet.
De Windows-grens is echt getoetst, niet beredeneerd: in een unit-test is WebViewPlatform.instance null, precies zoals daar. De test bewijst eerst dát hij null is (anders meet hij niets), en dan dat een render meteen niets oplevert in plaats van eeuwig te wachten — mét een timeout die "BLEEF HANGEN" zou teruggeven, zodat een terugval naar het oude gedrag rood wordt in plaats van traag.
De mislukte export heeft een widget-test die precies het webgeval nabootst: een ArgumentError uit onExport, en dan de melding in beeld, de reden erbij, en geen tolletje meer.
De integratietest op macOS is opnieuw gedraaid: daar rendert alles onveranderd, dus de grens heeft niet ook het werkende platform dichtgezet.

Eén ding meet ik níet: dat het op een échte Windows-machine goed gaat. Er staat hier geen Windows, en de CI draait de statische poort. Wat ik wel weet is dat de code daar nu niet meer om een renderer vraagt die er niet is; wat de gebruiker dan ziet is de bron van zijn diagram, en dat is precies het pad dat de unit-tests wél afdekken.

Op de vraag of de tekeningen uit #1612 ook op web en Windows werken was het antwoord twee keer nee — en één daarvan is een regressie die ik daar zelf in heb gezet. ## Windows en Linux: een regressie Er zit **geen WebView-implementatie voor die platformen in dit project**. `pubspec.lock` kent `webview_flutter_android`, `webview_flutter_wkwebview` en `webview_flutter_web`; voor Windows en Linux is er niets. Het exportpad van #1612 vroeg daar tóch om een diagramrender. Dat zet `hostNeeded` aan, de host bouwt een `WebViewController` op een platform zonder implementatie, en dat gooit. **Een document met één mermaid-diagram exporteerde daar eerst gewoon.** De dienst vraagt nu eerst `isAvailable` en geeft anders meteen niets terug. Het diagram valt dan terug op zijn bron — zoals bedoeld — en zonder de twintig seconden wachten per diagram die het plafond anders had gekost. **Grafieken worden in Dart getekend en reizen wél op elk platform mee.** ## Web: al langer stuk, en stil Daar werkt de documentexport **helemaal niet**, en niet alleen de PDF. `pickDocumentExportDestination` roept `FilePicker.saveFile` aan zonder bytes, en de webimplementatie gooit dan een `ArgumentError` ("The bytes are required when saving a file on the web"). Er zat nergens een `try` omheen, dus kwam `setState` nooit en bleef de knop eeuwig op zijn tolletje staan — zonder één woord uitleg, in alle vier de formaten, al sinds de documentexport bestaat. De dialoog zegt nu dat het niet gelukt is, met de reden erbij, en laat het document ongemoeid. Het wél laten wérken op web betekent de klaargemaakte bytes als download aan de browser geven; dat is een eigen wijziging en staat als zodanig in KNOWN_LIMITATIONS. ## Een vangst die te smal was Allebei de vangsten zijn verbreed van `on Exception` naar een benoemde `catch`. `ArgumentError` ís een `Error`, geen `Exception` — een vangst op `Exception` had hem laten lopen en de knop alsnog laten draaien. Om precies dezelfde reden is de vangst rond het plaatsen van een SVG verbreed: een ontleder die op iets onverwachts stuit werpt net zo goed een `Error`, en voor de uitkomst maakt dat niets uit — het diagram is er niet, dus valt het terug op zijn bron. Kaal is geen van beide; ze loggen wat ze vangen. ## Wat de documentatie beweerde Dat de webversie "de bron zou tonen". Dat was nooit waar — daar komt geen PDF. Rechtgezet in USER_GUIDE (nl + en) en KNOWN_LIMITATIONS (nl + en), mét de datum en de reden van de correctie, zodat te zien is dat de eerdere zin ongemeten was. ## Toetsen - `make check` groen (dekking 87,2%, per-bestand-vloer 0). `make check-secrets`: geen bevindingen. `make sast`: 0 findings. DAST niet gedraaid — deze wijziging raakt het geserveerde weboppervlak niet. - **De Windows-grens is echt getoetst**, niet beredeneerd: in een unit-test is `WebViewPlatform.instance` null, precies zoals daar. De test bewijst eerst dát hij null is (anders meet hij niets), en dan dat een render meteen niets oplevert in plaats van eeuwig te wachten — mét een `timeout` die "BLEEF HANGEN" zou teruggeven, zodat een terugval naar het oude gedrag rood wordt in plaats van traag. - De mislukte export heeft een widget-test die precies het webgeval nabootst: een `ArgumentError` uit `onExport`, en dan de melding in beeld, de reden erbij, en geen tolletje meer. - De integratietest op macOS is opnieuw gedraaid: daar rendert alles onveranderd, dus de grens heeft niet ook het werkende platform dichtgezet. Eén ding meet ik níet: dat het op een échte Windows-machine goed gaat. Er staat hier geen Windows, en de CI draait de statische poort. Wat ik wel weet is dat de code daar nu niet meer om een renderer vraagt die er niet is; wat de gebruiker dan ziet is de bron van zijn diagram, en dat is precies het pad dat de unit-tests wél afdekken.

brenno added 1 commit

2026-08-20 16:22:53 +00:00

fix(document): de tekeningen houden zich aan de grenzen van het platform

scans / scans (pull_request) Successful in 2m31s

Details

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

Details

659b8843b0

Op de vraag of dit ook op web en Windows werkt was het antwoord twee keer
nee, en één daarvan was een regressie van gisteren.

**Windows en Linux.** Er zit geen WebView-implementatie voor die
platformen in dit project — `pubspec.lock` kent android, wkwebview en
web, meer niet. Het nieuwe exportpad vroeg daar tóch om een
diagramrender: dat zette `hostNeeded` aan, de host bouwde een
`WebViewController` op een platform zonder implementatie, en dat gooide.
Een document met één mermaid-diagram exporteerde daar eerst gewoon.

De dienst vraagt nu eerst of er hier überhaupt gerenderd kán worden en
geeft anders meteen niets terug. Het diagram valt dan terug op zijn bron,
zoals bedoeld — en zonder de twintig seconden wachten per diagram die het
plafond anders had gekost. Grafieken worden in Dart getekend en reizen
wél op elk platform mee.

**Web.** Daar werkt de documentexport helemaal niet, en niet alleen de
PDF: de bestandskiezer in de browser wil de bytes vooraf en gooit anders
een `ArgumentError`. Die werd nergens gevangen, dus kwam `setState` nooit
en bleef de knop eeuwig op zijn tolletje staan — zonder één woord uitleg,
in alle vier de formaten, al sinds de documentexport bestaat. De dialoog
zegt nu dat het niet gelukt is, met de reden erbij, en laat het document
ongemoeid.

Die vangst is bewust breder dan `on Exception`: een `ArgumentError` ís
een `Error`, en een vangst op `Exception` had hem laten lopen. Om
dezelfde reden is de vangst rond het plaatsen van een SVG verbreed — een
ontleder die op iets onverwachts stuit werpt net zo goed een `Error`, en
voor de uitkomst maakt dat niets uit.

De documentatie beweerde intussen dat de webversie de bron zou tonen. Dat
was nooit waar; rechtgezet in beide gidsen en beide beperkingenlijsten.

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

brenno merged commit 01851a7ec5 into main

2026-08-20 16:28:11 +00:00

brenno referenced this pull request from a commit

2026-08-20 16:28:14 +00:00

De tekeningen in een document-PDF houden zich aan de grenzen van het platform (#1615)