LibreKAT/Ocideck

Watch

Fork 1

Markdown- en LaTeX-export buiten de projectmap breekt relatieve afbeeldingen #1673

New issue

Closed

opened 2026-08-21 12:02:08 +00:00 by brenno · 1 comment

brenno commented

2026-08-21 12:02:08 +00:00

Owner

Probleem

De .md- en .tex-export behouden relatieve afbeeldingspaden uit het project, maar de gebruiker kan het uitvoerbestand in iedere map opslaan. Er worden geen assets gekopieerd en paden worden niet herbaseerd. Het exportbestand toont/compileert daardoor zonder afbeeldingen zodra de doelmap een andere relatieve basis heeft.

Reproductie

Open een projectdocument met een relatieve afbeelding, bijvoorbeeld images/a.png.
Exporteer als Markdown of LaTeX naar een map buiten het project.
Open de Markdown daar of compileer de TeX vanuit die map.

Verwacht

Een zelfstandig exportbestand houdt werkende beelden, bijvoorbeeld door assets mee te nemen/rebasen of de beperking vóór export expliciet af te dwingen.

Technische aanwijzing

writeDocumentExport schrijft voor md projectedDocumentBody en voor latex markdownToLatex met de originele bronnen. Alleen HTML/PDF krijgen embedImage.

Gevonden bij audit van commit d439638c6b.

## Probleem De .md- en .tex-export behouden relatieve afbeeldingspaden uit het project, maar de gebruiker kan het uitvoerbestand in iedere map opslaan. Er worden geen assets gekopieerd en paden worden niet herbaseerd. Het exportbestand toont/compileert daardoor zonder afbeeldingen zodra de doelmap een andere relatieve basis heeft. ## Reproductie 1. Open een projectdocument met een relatieve afbeelding, bijvoorbeeld images/a.png. 2. Exporteer als Markdown of LaTeX naar een map buiten het project. 3. Open de Markdown daar of compileer de TeX vanuit die map. ## Verwacht Een zelfstandig exportbestand houdt werkende beelden, bijvoorbeeld door assets mee te nemen/rebasen of de beperking vóór export expliciet af te dwingen. ## Technische aanwijzing writeDocumentExport schrijft voor md projectedDocumentBody en voor latex markdownToLatex met de originele bronnen. Alleen HTML/PDF krijgen embedImage. Gevonden bij audit van commit d439638c6bd1b519d68d87680cb022b7d5eddc85.

brenno added the

bug

triage

labels

2026-08-21 12:02:08 +00:00

brenno added

accepted

and removed

triage

labels

2026-08-21 22:52:30 +00:00

brenno commented

2026-08-21 22:52:31 +00:00

Author

Owner

Triage: accepted — maar er ligt eerst een productkeuze

Bevestigd tegen main (e93ef205c). writeDocumentExport (lib/services/document_export_service.dart) schrijft voor md de geprojecteerde body en voor latex markdownToLatex(projectedDocumentBody(bundle), …), beide met de afbeeldingspaden zoals ze in de bron staan. Alleen de HTML- en PDF-tak krijgen embedImage. De uitvoermap is vrij te kiezen, dus zodra die niet dezelfde relatieve basis heeft, wijst elk relatief pad naar niets.

De keuze die eerst gemaakt moet worden

Er zijn drie eerlijke antwoorden en ze geven de gebruiker echt iets anders:

(a) Paden herbaseren op de exportmap (p.relative(abs, from: p.dirname(outputPath))). Goedkoop, blijft één bestand, werkt zolang de export op dezelfde machine blijft. Levert ../../project/images/a.png op en breekt alsnog zodra iemand het bestand doorstuurt.
(b) Beelden meenemen naar <naam>-assets/ naast de export, met herschreven paden. Dit is wat "één ding dat je kunt overhandigen" betekent voor formaten die niets kunnen insluiten. Kost een map die de gebruiker niet vroeg, plus een regel voor naambotsingen en voor beelden buiten de projectmap (die worden vandaag geweigerd, en dat moet zo blijven).
(c) Niets doen en de beperking uitspreken: in de exportdialoog én in KNOWN_LIMITATIONS.md.

Aanbeveling: (b), met de kopie begrensd tot dezelfde projectgrens die _embedDocumentExportImage (lib/widgets/document_editor_screen.dart) al afdwingt, en een vinkje in de exportdialoog dat standaard aan staat. Zet de gebruiker het uit, dan (a) als terugval. Een export die je niet kunt doorgeven is geen export, en insluiten kan hier nu eenmaal niet — Markdown en LaTeX hébben geen data-URI-weg die de doelprogramma's begrijpen.

Regressietest (verplicht)

test/document_export_write_test.dart: document met images/a.png, export naar een map buiten het project → het beeld staat naast de uitvoer en het pad in de uitvoer wijst ernaar; met de kopie uit → herbaseerd pad dat vanuit de doelmap oplost; beeld buiten de projectmap → geweigerd, met melding, niet gekopieerd.

Kosten

Dialoog + service + tests, plus twee nieuwe l10n.d('…') ⇒ 31 vertalingen elk. Halve dag tot een dag.

Prioriteit

Middel. Geen dataverlies, wel een export die niet doet wat hij belooft.

## Triage: accepted — maar er ligt eerst een productkeuze **Bevestigd tegen `main` (e93ef205c).** `writeDocumentExport` (`lib/services/document_export_service.dart`) schrijft voor `md` de geprojecteerde body en voor `latex` `markdownToLatex(projectedDocumentBody(bundle), …)`, beide met de afbeeldingspaden zoals ze in de bron staan. Alleen de HTML- en PDF-tak krijgen `embedImage`. De uitvoermap is vrij te kiezen, dus zodra die niet dezelfde relatieve basis heeft, wijst elk relatief pad naar niets. ## De keuze die eerst gemaakt moet worden Er zijn drie eerlijke antwoorden en ze geven de gebruiker echt iets anders: - **(a) Paden herbaseren** op de exportmap (`p.relative(abs, from: p.dirname(outputPath))`). Goedkoop, blijft één bestand, werkt zolang de export op dezelfde machine blijft. Levert `../../project/images/a.png` op en breekt alsnog zodra iemand het bestand doorstuurt. - **(b) Beelden meenemen** naar `<naam>-assets/` naast de export, met herschreven paden. Dit is wat "één ding dat je kunt overhandigen" betekent voor formaten die niets kunnen insluiten. Kost een map die de gebruiker niet vroeg, plus een regel voor naambotsingen en voor beelden buiten de projectmap (die worden vandaag geweigerd, en dat moet zo blijven). - **(c) Niets doen** en de beperking uitspreken: in de exportdialoog én in `KNOWN_LIMITATIONS.md`. **Aanbeveling: (b)**, met de kopie begrensd tot dezelfde projectgrens die `_embedDocumentExportImage` (`lib/widgets/document_editor_screen.dart`) al afdwingt, en een vinkje in de exportdialoog dat standaard aan staat. Zet de gebruiker het uit, dan (a) als terugval. Een export die je niet kunt doorgeven is geen export, en insluiten kan hier nu eenmaal niet — Markdown en LaTeX hébben geen data-URI-weg die de doelprogramma's begrijpen. ## Regressietest (verplicht) `test/document_export_write_test.dart`: document met `images/a.png`, export naar een map buiten het project → het beeld staat naast de uitvoer en het pad in de uitvoer wijst ernaar; met de kopie uit → herbaseerd pad dat vanuit de doelmap oplost; beeld buiten de projectmap → geweigerd, met melding, niet gekopieerd. ## Kosten Dialoog + service + tests, plus twee nieuwe `l10n.d('…')` ⇒ 31 vertalingen elk. Halve dag tot een dag. ## Prioriteit Middel. Geen dataverlies, wel een export die niet doet wat hij belooft.

brenno added the

in-progress

label

2026-08-21 23:36:46 +00:00

brenno referenced this issue from a commit

2026-08-22 00:18:57 +00:00

fix: tweede batch accepted issues (#1699, #1683, #1673, #1652, #1653, #1655, #1654)

brenno referenced this issue from a commit

2026-08-22 00:18:57 +00:00

test: tests voor CRLF-bewaring, lineaire diff, chart-fence, image-rebasing

brenno referenced this issue

2026-08-22 00:19:15 +00:00