Mermaid erDiagram en gantt renderen niet in de app (grijs/broncode op scherm; PDF: verkeerd duplicaat resp. blanco) #886

New issue

Closed

opened 2026-07-26 13:05:22 +00:00 by brenno · 0 comments

brenno commented

2026-07-26 13:05:22 +00:00

Owner

Ontdekt tijdens de #882-keuring (nadat de opstartrace was verholpen en 5 van de 7 mermaid-typen weer renderen). Twee diagramsoorten falen deterministisch en type-specifiek:

erDiagram en gantt: op scherm (slidestrook én presentatiemodus) een grijs kader met de ruwe broncode i.p.v. een getekend diagram.
In de PDF-export (macOS): de erDiagram-pagina toont foutief een duplicaat van de vorige (pie-)dia — stille onjuiste inhoud, erger dan leeg; de gantt-pagina is vrijwel blanco.

Werkt wél (zelfde deck, zelfde run): flowchart, sequenceDiagram, classDiagram, stateDiagram-v2, pie — met kleur en tekst-in-de-knopen.

Waarom dit los staat van de #882-race: (a) 5 typen renderen wél, ook vanaf de eerste weergave — een race zou de vroegste renders raken, niet juist twee specifieke typen; (b) er komt géén render failed/FWFEvaluateJavaScriptError/timed out in de log — de fallback is stil, dus de dienst krijgt voor ER/gantt een resultaat zonder <svg> terug (lib/services/mermaid_render_service.dart, de svg.contains('<svg')-check); (c) een losse proef-PNG (~/Documents/Mermaidkeur/mermaid-labels-proof.png, mermaid 11.16.0, gesaneerd zoals de app dat doet) toont ER én gantt wél correct — de bron is dus geldig en sanitizeMermaidSvg op zichzelf ook. Het falen zit in het WebView→(inliner)→flutter_svg-pad van de draaiende app voor juist deze twee typen: mogelijk mangelt __ocideckInlineSvgStyles (svg_style_inline.js) hun tekst-/structuur zo dat de daaropvolgende XML-parse in sanitizeMermaidSvg faalt (dan valt <svg> weg) — te bevestigen.

Apart, mogelijk tweede bug: dat de ER-pagina in de PDF de ´pie´ herhaalt (terwijl het scherm de broncode-fallback toont) wijst op een stale/hergebruik in de rasteraar (slide_rasterizer.dart) bij een mislukte render — dat zou apart onderzocht moeten worden, want het presenteert stil verkeerde inhoud.

Volgende stap: diagnostiek toevoegen die voor een mislukte render (geen <svg>) de ráw teruggegeven SVG-lengte + eerste tekens logt, om te zien of mermaid.render iets teruggeeft en waar het <svg> verdwijnt (inliner vs sanitize). Verificatie is traag (macOS-app draaien, agent beeldkeurder). Zie mermaid-macos-desktop-render-kapot voor de context van #882.

Ontdekt tijdens de #882-keuring (nadat de opstartrace was verholpen en 5 van de 7 mermaid-typen weer renderen). **Twee diagramsoorten falen deterministisch en type-specifiek:** - **erDiagram** en **gantt**: op scherm (slidestrook én presentatiemodus) een **grijs kader met de ruwe broncode** i.p.v. een getekend diagram. - **In de PDF-export** (macOS): de erDiagram-pagina toont **foutief een duplicaat van de vorige (pie-)dia** — stille onjuiste inhoud, erger dan leeg; de gantt-pagina is **vrijwel blanco**. **Werkt wél** (zelfde deck, zelfde run): flowchart, sequenceDiagram, classDiagram, stateDiagram-v2, pie — met kleur en tekst-in-de-knopen. **Waarom dit los staat van de #882-race:** (a) 5 typen renderen wél, ook vanaf de eerste weergave — een race zou de vroegste renders raken, niet juist twee specifieke typen; (b) er komt géén `render failed`/`FWFEvaluateJavaScriptError`/`timed out` in de log — de fallback is **stil**, dus de dienst krijgt voor ER/gantt een resultaat **zonder `<svg>`** terug (`lib/services/mermaid_render_service.dart`, de `svg.contains('<svg')`-check); (c) een losse proef-PNG (`~/Documents/Mermaidkeur/mermaid-labels-proof.png`, mermaid 11.16.0, gesaneerd zoals de app dat doet) toont ER én gantt **wél correct** — de bron is dus geldig en `sanitizeMermaidSvg` op zichzelf ook. Het falen zit in het **WebView→(inliner)→flutter_svg-pad van de draaiende app** voor juist deze twee typen: mogelijk mangelt `__ocideckInlineSvgStyles` (svg_style_inline.js) hun tekst-/structuur zo dat de daaropvolgende XML-parse in `sanitizeMermaidSvg` faalt (dan valt `<svg>` weg) — te bevestigen. **Apart, mogelijk tweede bug:** dat de ER-pagina in de PDF de ´pie´ herhaalt (terwijl het scherm de broncode-fallback toont) wijst op een **stale/hergebruik in de rasteraar** (`slide_rasterizer.dart`) bij een mislukte render — dat zou apart onderzocht moeten worden, want het presenteert stil verkeerde inhoud. **Volgende stap:** diagnostiek toevoegen die voor een mislukte render (geen `<svg>`) de ráw teruggegeven SVG-lengte + eerste tekens logt, om te zien of mermaid.render iets teruggeeft en waar het `<svg>` verdwijnt (inliner vs sanitize). Verificatie is traag (macOS-app draaien, agent `beeldkeurder`). Zie [[mermaid-macos-desktop-render-kapot]] voor de context van #882.

brenno referenced this issue

2026-07-26 13:09:21 +00:00

Mermaid rendert niet op macOS-desktop (WebView Promise), PDF/PPTX-export van diagram-dia's leeg #882

brenno referenced this issue

2026-07-26 13:09:48 +00:00

fix(mermaid): wacht op pagina-klaar vóór renderen op macOS-WebView (#882) #887

brenno referenced this issue

2026-07-26 14:44:20 +00:00

chore(notices): dartcv4 in THIRD_PARTY_NOTICES (repareer make check op main) #892

brenno referenced this issue from a pull request that will close it,

2026-07-26 14:45:43 +00:00

fix(mermaid): schoon ongeldige style-delen zodat erDiagram niet blanco blijft (#886) #893