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

Merged

brenno merged 1 commit from fix/pdf-export-poort-echte-resolutie-714 into main

2026-07-23 17:01:24 +00:00

brenno commented

2026-07-23 17:01:13 +00:00

Owner

De poort van #718 had twee blinde vlekken. Dit dicht ze. De oorzaak van
#714 is hiermee niet gevonden — dat issue blijft open op needs-info.

1. De gemelde beperking klopte niet. De poort stond op 640 px met de
notitie dat exportresolutie onder de testbinding "niet meer klaar wordt
(gemeten: did not complete)". Dat is onjuist. De lus liep leeg doordat er per
ronde maar 1 ms échte tijd voorbijging terwijl het capturen op echte tijd
loopt; met een ruimer budget haalt 1920 px het ruim — 41 dia's in acht
seconden.

Dat is niet alleen een feitje. Die notitie zette juist de resolutie buiten
beeld als verdachte bij #714, en een onjuiste beperking in een testkop is
erger dan geen beperking: de volgende lezer gaat er niet meer kijken. De kop
draagt nu de correctie mét de reden.

2. Het compressiepad was ongedekt. "Gecomprimeerd" is een knop in de
exportdialoog die de bytes langs een heel ander pad stuurt — PNG decoderen,
verkleinen, opnieuw als JPEG coderen — op 1280 in plaats van 1920, en die
alleen PDF kent. Precies het formaat dat in #714 omviel terwijl HTML op
hetzelfde deck lukte. Geen enkele toets raakte hem.

3. Alle toetsen bouwden lege dia's. Slide.create levert de lege
startrijen: een checklist zonder tests, een scopematrix zonder objecten, een
overzicht op nul. Dat is niet het deck uit de melding, en het is precies de
inhoud die de tabellen en de voortgangsgrafiek laat tekenen.

De twee nieuwe toetsen draaien het gemelde deck gevuld, in de twee
combinaties die de app zelf gebruikt: onbewerkt op 1920 en gecomprimeerd op
1280. De per-type-toetsen blijven op 640 — die gaan over dékking, en 24 types
op exportresolutie maken de poort onnodig traag. Totaal 27 toetsen in drie
seconden.

Rood gezien

throw ArgumentError(1) in _toJpeg — letterlijk de melding uit #714 — valt
om op de gecomprimeerde toets en op geen enkele van de andere 26. Dat laat
zien dat die tak echt onbewaakt was, en dat de nieuwe toets hem bijt.

Wat dit níét is

Geen reparatie. Ik heb #714 niet gereproduceerd. Wat er nu, groen, uit ligt:
gevulde dia's, 1920 én 1280, compressie, een verzegeld deck met TLP en
organisatie, en schaal (41 dia's). Het deck uit de melding bestaat niet meer —
het is tijdens een geautomatiseerde beeldkeuring in de app gebouwd en nooit
naar schijf geschreven, dus het is ook niet uit de sessielogs terug te halen.

Als de fout aan resolutie, compressie of gevulde tabellen hing, valt hij
voortaan vanzelf om in de poort. Hing hij aan iets anders, dan staat de
zoekruimte nu een stuk kleiner opgeschreven in #714.

Poort

make check groen (exit 0), check-secrets en sast schoon. Gerebased op
main en daarna opnieuw getoetst. Alleen een testbestand gewijzigd; geen
productiecode, dus geen bewakerstoets nodig.

Refs #714.

De poort van #718 had twee blinde vlekken. Dit dicht ze. **De oorzaak van #714 is hiermee niet gevonden** — dat issue blijft open op needs-info. **1. De gemelde beperking klopte niet.** De poort stond op 640 px met de notitie dat exportresolutie onder de testbinding "niet meer klaar wordt (gemeten: did not complete)". Dat is onjuist. De lus liep leeg doordat er per ronde maar 1 ms *échte* tijd voorbijging terwijl het capturen op echte tijd loopt; met een ruimer budget haalt 1920 px het ruim — 41 dia's in acht seconden. Dat is niet alleen een feitje. Die notitie zette juist de resolutie buiten beeld als verdachte bij #714, en een onjuiste beperking in een testkop is erger dan geen beperking: de volgende lezer gaat er niet meer kijken. De kop draagt nu de correctie mét de reden. **2. Het compressiepad was ongedekt.** "Gecomprimeerd" is een knop in de exportdialoog die de bytes langs een heel ander pad stuurt — PNG decoderen, verkleinen, opnieuw als JPEG coderen — op 1280 in plaats van 1920, en die **alleen PDF kent**. Precies het formaat dat in #714 omviel terwijl HTML op hetzelfde deck lukte. Geen enkele toets raakte hem. **3. Alle toetsen bouwden lege dia's.** `Slide.create` levert de lege startrijen: een checklist zonder tests, een scopematrix zonder objecten, een overzicht op nul. Dat is niet het deck uit de melding, en het is precies de inhoud die de tabellen en de voortgangsgrafiek laat tekenen. De twee nieuwe toetsen draaien het gemelde deck gevuld, in de twee combinaties die de app zelf gebruikt: onbewerkt op 1920 en gecomprimeerd op 1280. De per-type-toetsen blijven op 640 — die gaan over dékking, en 24 types op exportresolutie maken de poort onnodig traag. Totaal 27 toetsen in drie seconden. ## Rood gezien `throw ArgumentError(1)` in `_toJpeg` — letterlijk de melding uit #714 — valt om op de gecomprimeerde toets en op geen enkele van de andere 26. Dat laat zien dat die tak echt onbewaakt was, en dat de nieuwe toets hem bijt. ## Wat dit níét is Geen reparatie. Ik heb #714 niet gereproduceerd. Wat er nu, groen, uit ligt: gevulde dia's, 1920 én 1280, compressie, een verzegeld deck met TLP en organisatie, en schaal (41 dia's). Het deck uit de melding bestaat niet meer — het is tijdens een geautomatiseerde beeldkeuring in de app gebouwd en nooit naar schijf geschreven, dus het is ook niet uit de sessielogs terug te halen. Als de fout aan resolutie, compressie of gevulde tabellen hing, valt hij voortaan vanzelf om in de poort. Hing hij aan iets anders, dan staat de zoekruimte nu een stuk kleiner opgeschreven in #714. ## Poort `make check` groen (exit 0), `check-secrets` en `sast` schoon. Gerebased op main en daarna opnieuw getoetst. Alleen een testbestand gewijzigd; geen productiecode, dus geen bewakerstoets nodig. Refs #714.

brenno added 1 commit

2026-07-23 17:01:13 +00:00

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

Twee blinde vlekken in de poort van #718, gevonden bij het opnieuw
zoeken naar de oorzaak van #714.

**De gemelde beperking klopt niet.** De poort stond op 640 px met de
notitie dat exportresolutie onder de testbinding 'niet meer klaar
wordt (gemeten: did not complete)'. De lus liep leeg omdat er per ronde
maar 1 ms échte tijd voorbijging terwijl het capturen op echte tijd
loopt; met een ruimer budget haalt 1920 px het ruim — 41 dia's in acht
seconden. Die onterechte notitie zette juist de resolutie buiten beeld
als verdachte, en dat is erger dan geen notitie.

**Het compressiepad was ongedekt.** 'Gecomprimeerd' is een knop in de
exportdialoog die de bytes langs een heel ander pad stuurt (PNG →
decode → resize → JPEG) op 1280 in plaats van 1920, en die alleen PDF
kent — het enige formaat dat in #714 omviel terwijl HTML op hetzelfde
deck lukte. Geen enkele toets raakte hem.

Verder bouwden alle toetsen hun dia's met Slide.create, dus met de lege
startrijen: een checklist zonder tests, een scopematrix zonder
objecten, een overzicht op nul. De twee nieuwe toetsen vullen ze, en
zetten de voortgangsgrafiek aan.

De per-type-toetsen blijven op 640 — die gaan over dekking, en 24 types
op exportresolutie maken de poort onnodig traag. Totaal 27 toetsen in
drie seconden.

Rood gezien: 'throw ArgumentError(1)' in _toJpeg — letterlijk de
gemelde melding — valt om op de gecomprimeerde toets en op geen enkele
andere.

brenno merged commit 66cbb47327 into main

2026-07-23 17:01:24 +00:00

brenno referenced this pull request from a commit

2026-07-23 17:01:25 +00:00

Merge pull request 'test(export): de PDF-poort op echte exportbreedte en door het compressiepad (#714)' (#766) from fix/pdf-export-poort-echte-resolutie-714 into main

brenno referenced this pull request

2026-07-23 17:01:52 +00:00

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