fix(callouts): markeringen terug in de rasterexport, en zichtbaar op donker (#1847) #1857
No reviewers
Labels
No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
LibreKAT/Ocideck!1857
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/1847-callouts-uit-de-export"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
De beeldkeuring van #1847 gelopen — pin/gebied/pijl × licht/donker/druk/grijswaarden, onthullen, zoom, volle diabreedte én slidestrook. Twee bevindingen zijn hier gerepareerd; vier andere zijn issues geworden (#1853, #1854, #1855, #1856).
1. De markeringen ontbraken in élke rasterexport
De zwaarste. PDF, PPTX en ODP kregen de dia zonder spelden, gebieden of pijlen — zichtbaar in de app, weg in het bestand, en niets dat erover klaagde.
CalloutOverlaytekent niets zolang de intrinsieke beeldmaat onbekend is, en die maat kwam altijd via eensetState. De rasterizer laadt de dia-afbeeldingen voor en vangt dan één frame zodra de boom niet meer hoeft te verven — dat frame was er al vóór de tweede ronde. Staat het beeld in de cache (precies wat het voorladen doet), dan levertresolveIntrinsicSizede maat nu synchroon af.Nagemeten op het echte product, want de fout was niet uit de code af te lezen: dezelfde dia, dezelfde export, vóór de reparatie geen enkele markering en erna alle drie op hun plek.
Wat een test hier wél en niet houdt. De tíming is onder de testbinding niet na te bootsen: daar komt het extra frame vanzelf op tijd, en een rasterizer-toets bleef groen mét én zónder de fout — dat is met een mutatie nagegaan, niet aangenomen. Wat wél vastligt is de eigenschap waar de export op steunt: een gecachet beeld antwoordt synchroon.
callout_export_frame_test.dartvalt om zodra dat weer een frame kost. Daarnaast houdtcallout_raster_export_frame_test.dartde bodem vast — markeringen bereiken de gerasterde pixels überhaupt — door de echte rasterizer te draaien en de pixels te tellen.2. De markering was op een donkere afbeelding niet te zien
§6 belooft een niet-optionele two-tone rand, juist omdat de pixels eronder willekeurig zijn. De invulling was: rand altijd donker, vulling het thema-accent. Met het uitgerolde profiel zijn dat twee dónkere tonen. Gemeten tegen zwart:
#003399oprgb(25,25,25)#111111oprgb(25,25,25)In grijswaarden bleef er een zwevende letter over zonder markering eromheen — precies wat punt 3 van de acceptatielijst verbiedt.
Er zit nu een witte ring tussen de vulling en de donkere rand: één lichte en één donkere toon, dus contrast tegen élke ondergrond, en niet meer leunend op kleur. De HTML-export deed dit al zo (
border:2px solid #fffplus accentring); dit brengt Flutter in lijn in plaats van andersom.Daarbij een ondergrens op de straal. Op slidestrook-breedte (~121 pt slot) kwam de markering op 2,7 pt uit en verdween ze in het beeld: de strook toonde dan een dia waarvan niet te zien was dát er verwijzingen op staan. De letter is daar toch niet te lezen — een navigatiestrook is geen leesoppervlak — maar de markering moet een markering blijven.
De rest van de keuring
Wat issues zijn geworden
Test plan
make checkgroenmake check-secretsgroen (gitleaks: no leaks; trufflehog: 0 geverifieerd)make sastgroen (semgrep, 0 bevindingen)callout_export_frame_test.dart(de synchrone eigenschap, met mutatieproef) encallout_raster_export_frame_test.dart(echte rasterizer, pixels geteld)Bewaker
Geen bestandsformaat, geen opslag, geen afhankelijkheid, geen uitgaand verkeer. Wel een publieke belofte: de exportdialoog zegt "De export gebruikt exact de weergave uit de editor". Die belofte was onwaar en is nu waar voor de rasterexports; voor de HTML-export staat wat er nog scheef is in #1855 in plaats van dat het stil blijft.
🤖 Generated with Claude Code