Documentmodus: een afbeelding staat wel in de uitvoer, maar nergens op het scherm #1605

New issue

Closed

opened 2026-08-20 07:55:53 +00:00 by brenno · 0 comments

brenno commented

2026-08-20 07:55:53 +00:00

Owner

Wat er gebeurt

Een document schrijf je met de gewone Markdown-afbeelding, ![omschrijving](pad). De uitvoer tekent hem: de HTML-export schrijft de verwijzing om naar een ingesloten afbeelding (marp_html_service_images.dart:320) en de documentstijl draagt er zelfs een regel voor (.document img{max-width:100%}), dus in de HTML en de PDF die je daaruit drukt staat je afbeelding.

Op het scherm staat hij nergens:

De documentlezer tekent hem niet. DocumentMarkdownView kent geen afbeeldingsblok; ![Een alt](foo.png) komt eruit als de losse tekst !Een alt met een link eronder. Nagemeten: nul Image-widgets, en de tekstlaag levert letterlijk ['Tekst.', '!Een alt-tekst'].
Pagina's evenmin — PagedDocumentView rendert via dezelfde DocumentMarkdownView.
Het schrijfvlak toont een merkteken. Sinds #1604 staat er in de visuele stand een chipje met de alt-tekst op de plek in de zin. Dat is bewust een tussenstand: het bestond niet en Quill viel erover om (UnimplementedError: Embeddable type "image" is not supported). Het merkteken zegt dát er een afbeelding staat, niet welke.

Waarom dat erg is

De documentmodus belooft dat je ziet wat je krijgt — dat is de hele reden dat er een visuele stand en een Pagina's-weergave zijn. Voor afbeeldingen klopt dat nu niet: je schrijft blind, je ziet pas bij het exporteren of het plaatje er goed uit komt, en de paginering in Pagina's rekent met een regel tekst waar in de uitvoer een afbeelding van een paar centimeter staat. Dat laatste maakt de pagina-einden op het scherm aantoonbaar onjuist zodra er een afbeelding in het document zit.

Bovendien staat de aanwijzing er wél in de gebruikersgids (§ Afbeeldingen in een document), als beperking. Een beperking die je moet uitleggen is meestal een gat.

Wat er zou moeten gebeuren

De documentlezer tekent de afbeelding, en het schrijfvlak toont hetzelfde — één renderwereld, net als bij tabellen en de tijdlijn.

Het echte werk zit niet in het tekenen maar in het oplossen van het pad. Een documentpad kan mem: zijn (geïmporteerd of uit een remote deck), asset: (gebundeld) of relatief aan de map van het document. Dat uitzoeken hoort bij ImageService, en die heeft de map van het bestand nodig — precies wat DocumentMarkdownView en WysiwygNotesField vandaag niet krijgen. Zonder die context zou de lezer een pad raden, en dat is erger dan niets tekenen.

Voorstel voor de vorm:

Een documentcontext (map van het bestand + de ImageService) die de lezer en het schrijfvlak allebei bereiken, zoals DocumentStyleScope dat voor het stijlprofiel doet.
Een afbeeldingsblok in document_markdown_blocks.dart dat begrensd decodeert (image_limits.dart bestaat al) — een document met twintig foto's mag het geheugen niet opeten.
ImageEmbedBuilder tekent dezelfde afbeelding in plaats van het merkteken, en valt op het merkteken terug als het pad niet oplost. Een ontbrekend bestand hoort zichtbaar te zijn, niet leeg.
De hoogte die de paginering rekent, komt uit de werkelijke afmeting — zie de eerdere les dat een schatting die renderafmetingen voorspelt stil wegrot.
Op web resolveert alleen mem: (via WebAssetStore); die grens hoort in de gids te staan in plaats van als raadsel.

Raakvlak

lib/widgets/reader/document_markdown_view.dart, lib/widgets/reader/parts/document_markdown_blocks.dart, lib/widgets/reader/paged_document_view.dart, lib/widgets/markdown_editor/image_embed_builder.dart, lib/services/image_service.dart, lib/utils/image_limits.dart. De opslagkant van het pad (x-embed-image draagt de markdown byte-getrouw) is met #1604 al geregeld; dit issue gaat alleen over het tónen.

Herkomst

Gevonden bij #1604, waar een afbeelding in een document het schrijfvlak liet omvallen. Die crash en het stille verlies van de alt-tekst zijn daar opgelost; dit is het gat dat eronder zichtbaar werd.

## Wat er gebeurt Een document schrijf je met de gewone Markdown-afbeelding, `![omschrijving](pad)`. De **uitvoer** tekent hem: de HTML-export schrijft de verwijzing om naar een ingesloten afbeelding (`marp_html_service_images.dart:320`) en de documentstijl draagt er zelfs een regel voor (`.document img{max-width:100%}`), dus in de HTML en de PDF die je daaruit drukt staat je afbeelding. Op het **scherm** staat hij nergens: - **De documentlezer tekent hem niet.** `DocumentMarkdownView` kent geen afbeeldingsblok; `![Een alt](foo.png)` komt eruit als de losse tekst `!Een alt` met een link eronder. Nagemeten: nul `Image`-widgets, en de tekstlaag levert letterlijk `['Tekst.', '!Een alt-tekst']`. - **Pagina's evenmin** — `PagedDocumentView` rendert via dezelfde `DocumentMarkdownView`. - **Het schrijfvlak toont een merkteken.** Sinds #1604 staat er in de visuele stand een chipje met de alt-tekst op de plek in de zin. Dat is bewust een tussenstand: het bestond niet en Quill viel erover om (`UnimplementedError: Embeddable type "image" is not supported`). Het merkteken zegt *dát* er een afbeelding staat, niet welke. ## Waarom dat erg is De documentmodus belooft dat je ziet wat je krijgt — dat is de hele reden dat er een visuele stand en een Pagina's-weergave zijn. Voor afbeeldingen klopt dat nu niet: je schrijft blind, je ziet pas bij het exporteren of het plaatje er goed uit komt, en de paginering in Pagina's rekent met een regel tekst waar in de uitvoer een afbeelding van een paar centimeter staat. Dat laatste maakt de pagina-einden op het scherm aantoonbaar onjuist zodra er een afbeelding in het document zit. Bovendien staat de aanwijzing er wél in de gebruikersgids (§ *Afbeeldingen in een document*), als beperking. Een beperking die je moet uitleggen is meestal een gat. ## Wat er zou moeten gebeuren De documentlezer tekent de afbeelding, en het schrijfvlak toont hetzelfde — één renderwereld, net als bij tabellen en de tijdlijn. Het echte werk zit niet in het tekenen maar in het **oplossen van het pad**. Een documentpad kan `mem:` zijn (geïmporteerd of uit een remote deck), `asset:` (gebundeld) of relatief aan de map van het document. Dat uitzoeken hoort bij `ImageService`, en die heeft de map van het bestand nodig — precies wat `DocumentMarkdownView` en `WysiwygNotesField` vandaag niet krijgen. Zonder die context zou de lezer een pad raden, en dat is erger dan niets tekenen. Voorstel voor de vorm: 1. Een documentcontext (map van het bestand + de `ImageService`) die de lezer en het schrijfvlak allebei bereiken, zoals `DocumentStyleScope` dat voor het stijlprofiel doet. 2. Een afbeeldingsblok in `document_markdown_blocks.dart` dat begrensd decodeert (`image_limits.dart` bestaat al) — een document met twintig foto's mag het geheugen niet opeten. 3. `ImageEmbedBuilder` tekent dezelfde afbeelding in plaats van het merkteken, en valt op het merkteken terug als het pad niet oplost. Een ontbrekend bestand hoort zichtbaar te zijn, niet leeg. 4. De hoogte die de paginering rekent, komt uit de werkelijke afmeting — zie de eerdere les dat een schatting die renderafmetingen voorspelt stil wegrot. 5. Op web resolveert alleen `mem:` (via `WebAssetStore`); die grens hoort in de gids te staan in plaats van als raadsel. ## Raakvlak `lib/widgets/reader/document_markdown_view.dart`, `lib/widgets/reader/parts/document_markdown_blocks.dart`, `lib/widgets/reader/paged_document_view.dart`, `lib/widgets/markdown_editor/image_embed_builder.dart`, `lib/services/image_service.dart`, `lib/utils/image_limits.dart`. De opslagkant van het pad (`x-embed-image` draagt de markdown byte-getrouw) is met #1604 al geregeld; dit issue gaat alleen over het tónen. ## Herkomst Gevonden bij #1604, waar een afbeelding in een document het schrijfvlak liet omvallen. Die crash en het stille verlies van de alt-tekst zijn daar opgelost; dit is het gat dat eronder zichtbaar werd.

brenno added the

enhancement

label

2026-08-20 07:55:53 +00:00

brenno added the

in-progress

label

2026-08-20 16:05:36 +00:00

brenno referenced this issue from a commit

2026-08-20 17:22:59 +00:00

feat(document): afbeeldingen renderen op het scherm, niet alleen in export (#1605)

brenno referenced this issue