Logo van het stijlprofiel is onzichtbaar op een donkere dia

brenno commented

2026-09-03 04:46:04 +00:00

Owner

Een dia met een donkere achtergrond toont het logo van het stijlprofiel vrijwel
niet. De drie gebundelde merken zijn lijnwerk in donkere inkt, en het ingebouwde
LibreKAT- en Vigilis-profiel wijzen naar precies die lichte variant
(logoPath: 'asset:assets/images/librekat-logo.png', settings.dart). Zet een
gebruiker slideBackgroundColor op donker — of maakt hij een eigen donker
profiel — dan staat er donkere inkt op een donkere dia.

Gezien tijdens de beeldkeuring van het cockpit-herontwerp (#1929), op een
profiel met achtergrond #0F172A: het logo linksonder is een vage vlek, zowel in
de app-render als in de HTML-export.

Waar het misgaat

De keuze welk logobestand een dia krijgt bestaat niet. ThemeProfile.logoPath
is één pad, en dat pad wordt overal onveranderd doorgegeven:

_LogoOverlay (lib/widgets/slides/previews/overlays.dart) tekent het in de
preview, de presenter, het beamerbeeld en dus ook in de PDF/PPTX-raster;
_presentationLogoCss (lib/services/marp_html/marp_html_service_images.dart)
bakt hetzelfde bestand als data:-URI in de HTML-export;
de documentmodus gebruikt effectiveDocumentLogoPath (settings.dart), met
dezelfde terugval.

Wat er al ligt

lib/theme/brand_logo.dart heeft dit probleem al opgelost — maar alleen voor de
app-chrome. Daar staat per merk een lichte én een donkere variant
(librekat-logo-dark.png, vigilis-logo-dark.png, ocideck-logo-dark.png:
transparante achtergrond, inkt opgetild naar de donkere waarde), en assetKey
kiest op AppTheme.isDark. De dia gebruikt die enum niet.

De cockpit doet het sinds #1929 wél goed voor zijn eigen instrument:
AppTheme.cockpitPaletteFor(surface) kiest het palet op de luminantie van de
dia-achtergrond, niet op de app-modus. Dat is de juiste as — een dia kan licht
zijn terwijl de app donker staat, en omgekeerd.

Denkrichting (niet uitgewerkt)

De dia-render zou, wanneer logoPath naar een gebundeld merk-asset wijst, de
donkere variant kunnen kiezen op de luminantie van slideBackgroundColor, met
dezelfde grens als de cockpit (> 0,5 = licht). Voor een eigen logo van de
gebruiker is er geen tweede bestand; daar is de vraag of het profiel een
tweede pad moet kunnen dragen, of dat een waarschuwing in de instellingen
volstaat. Beide keuzes raken het stijlprofiel en dus het bestandsformaat —
dat verdient een ontwerpronde vóór de bouw, niet een snelle patch.

Raakvlakken

overlays.dart, marp_html_service_images.dart, brand_logo.dart,
models/settings.dart (stijlprofiel), en de export-pariteit: wat de app toont
moet de HTML-export ook tonen.

Een dia met een donkere achtergrond toont het logo van het stijlprofiel vrijwel niet. De drie gebundelde merken zijn lijnwerk in donkere inkt, en het ingebouwde LibreKAT- en Vigilis-profiel wijzen naar precies die lichte variant (`logoPath: 'asset:assets/images/librekat-logo.png'`, settings.dart). Zet een gebruiker `slideBackgroundColor` op donker — of maakt hij een eigen donker profiel — dan staat er donkere inkt op een donkere dia. Gezien tijdens de beeldkeuring van het cockpit-herontwerp (#1929), op een profiel met achtergrond #0F172A: het logo linksonder is een vage vlek, zowel in de app-render als in de HTML-export. ## Waar het misgaat De keuze *welk* logobestand een dia krijgt bestaat niet. `ThemeProfile.logoPath` is één pad, en dat pad wordt overal onveranderd doorgegeven: - `_LogoOverlay` (`lib/widgets/slides/previews/overlays.dart`) tekent het in de preview, de presenter, het beamerbeeld en dus ook in de PDF/PPTX-raster; - `_presentationLogoCss` (`lib/services/marp_html/marp_html_service_images.dart`) bakt hetzelfde bestand als `data:`-URI in de HTML-export; - de documentmodus gebruikt `effectiveDocumentLogoPath` (settings.dart), met dezelfde terugval. ## Wat er al ligt `lib/theme/brand_logo.dart` heeft dit probleem al opgelost — maar alleen voor de **app-chrome**. Daar staat per merk een lichte én een donkere variant (`librekat-logo-dark.png`, `vigilis-logo-dark.png`, `ocideck-logo-dark.png`: transparante achtergrond, inkt opgetild naar de donkere waarde), en `assetKey` kiest op `AppTheme.isDark`. De dia gebruikt die enum niet. De cockpit doet het sinds #1929 wél goed voor zijn eigen instrument: `AppTheme.cockpitPaletteFor(surface)` kiest het palet op de **luminantie van de dia-achtergrond**, niet op de app-modus. Dat is de juiste as — een dia kan licht zijn terwijl de app donker staat, en omgekeerd. ## Denkrichting (niet uitgewerkt) De dia-render zou, wanneer `logoPath` naar een gebundeld merk-asset wijst, de donkere variant kunnen kiezen op de luminantie van `slideBackgroundColor`, met dezelfde grens als de cockpit (> 0,5 = licht). Voor een eigen logo van de gebruiker is er geen tweede bestand; daar is de vraag of het profiel een tweede pad moet kunnen dragen, of dat een waarschuwing in de instellingen volstaat. Beide keuzes raken het stijlprofiel en dus het bestandsformaat — dat verdient een ontwerpronde vóór de bouw, niet een snelle patch. ## Raakvlakken `overlays.dart`, `marp_html_service_images.dart`, `brand_logo.dart`, `models/settings.dart` (stijlprofiel), en de export-pariteit: wat de app toont moet de HTML-export ook tonen.

brenno added the

bug

in-progress

labels

2026-09-03 04:46:04 +00:00

brenno referenced this issue from a commit

2026-09-03 06:30:08 +00:00

feat(logo): donkere logo-variant op donkere dia-achtergronden (#1931)

brenno referenced this issue

2026-09-03 06:30:21 +00:00

Donkere logo-variant + L-vormige hoek-reserve (#1931, #1932) #1937

brenno referenced this issue from a commit