feat(iconen): iOS en Android bijgesneden, en één script voor alle zes de sets #769

Merged
brenno merged 3 commits from fix/mobiele-iconen-huisstijl into main 2026-07-23 18:21:28 +00:00
Owner

De iOS- en Android-iconen droegen nog de fotokat. Die zijn nu bijgesneden — en het handwerk eronder is vervangen door een script, want zes sets met de hand bijhouden is de fout die daarna nog een keer gemaakt wordt.

Wat er verandert

  • iOS: 15 formaten (20–1024), uit Contents.json.
  • Android: 5 mipmap-dichtheden (48–192).
  • Linux en Windows: opnieuw gesneden. Zie hieronder — ze waren gisteren nog uit de verkeerde bron gemaakt.
  • macOS: geen byte verschil. Dat is een uitkomst, geen keuze.
  • web: onaangeraakt, met opzet.

Twee dingen die boven water kwamen

De master was niet wat de documentatie zei. Gisteren schreef ik op dat alles uit assets/images/ocideck-logo.png komt. Dat klopte niet: de échte master is macos/…/app_icon_1024.png. Het in-app-logo is 512 pixels; de master is 1024 en draagt ruim drie keer zoveel randdetail (randafwijking 0,22 tegen 0,08 na opschalen). Voor het 1024-icoon dat Apple in de App Store toont is dat het verschil tussen scherp en zacht. Elk formaat is nu een verkleining, nooit een vergroting — en daarom heb ik Linux en Windows van gisteren meteen opnieuw gesneden; die waren meetbaar zachter (randscherpte 0,29 tegen 0,39).

Het script reproduceert de gecommitte macOS-set bit voor bit. Dat is het bewijs dat dit hetzelfde recept is als waarmee die set ooit gesneden is, en niet een nieuw recept dat er toevallig op lijkt. Zonder die uitkomst zou ik de master niet hebben durven verplaatsen.

De uitzondering die blijft

De webiconen komen wél uit het in-app-logo, met zijn ruimere marge. Ik heb dat eerst als vergissing behandeld en willen rechttrekken; nameten liet zien dat het een eigen, consistente regel is — de gecommitte set komt op 0,3 tot 1,9% na uit "logo, recht verkleind", en maskable is datzelfde op 80% in een wit vlak. Een favicon staat in een tabblad naast andere favicons, niet in een dock. Dus vastgelegd in het script in plaats van gelijkgetrokken, en de webbestanden zijn teruggezet: 1% herbemonsteringsruis in vijf binaire bestanden is geen winst.

Bewaking

test/platform_icon_branding_test.dart liep over vier doelen en loopt nu over zes. Het argument dat iOS/Android geen bouwdoel zijn valt weg zodra ze in de generator meelopen — een set die niemand bewaakt is precies hoe Linux en Windows een maand achterliepen.

Twee toetsen erbij die alleen voor iOS gelden:

toets wat hij vangt
geen alfakanaal App Store Connect weigert dat. Deze stond ook groen tegen de oude set — hij vangt niet de rebrand maar de volgende bron: sinds #735 liggen er varianten mét een echt transparante achtergrond naast.
maat per bestand De naam noemt de púntmaat, niet de pixelmaat: een @3x van 20 punt is 60 pixels. Wie dat verwart levert een set in die Xcode zwijgend accepteert.

Tegen de oude mobiele iconen wordt de tekeningtoets rood (0,68 tegen drempel 0,20) en de kleurtoets ook (9,8% tegen 1%). Eerst zo gedraaid, daarna pas groen.

Een correctie op mezelf: ik dacht onderweg dat ImageMagick bij 20 en 29 pixels een alfakanaal terugzette, en had daar een commentaarregel over geschreven. Nagemeten klopte dat niet — magick identify meldt "srgb 4.0" ook voor een PNG zónder alfa; het onderscheid zit in de letter, niet in het getal. De toets blijft (het is een echte Apple-eis), de onjuiste verklaring is eruit.

Wat ik níet heb gedaan

Bij 20 pixels blijft de lijntekening flets. Dat is de prijs van een fijn merk en het geldt op elk platform gelijk — de macOS-16 ziet er al maanden zo uit, en de nieuwe is er niet van te onderscheiden. Een apart, vetter tekentje voor de kleinste maten is een ontwerpkeuze, geen icoonregeneratie; die heb ik niet in deze PR genomen.

Poorten

  • make check — exit 0. Opnieuw gedraaid ná de rebase op c6adf9f0.
  • make check-secrets — exit 0, gitleaks en trufflehog schoon over werkboom én historie.
  • make sast — 0 bevindingen over 688 bestanden.
  • bash -n over het script; shellcheck staat niet op deze machine, dat is dus níet gedraaid.
  • Geen SBOM: geen afhankelijkheid gewijzigd. Het script voegt wel een ontwikkel-eis toe (ImageMagick), maar niets dat meereist in een build.

Bewakerstap overgeslagen: geen bestandsformaat, opslag, afhankelijkheid, uitgaand verkeer of publieke belofte geraakt.

🤖 Generated with Claude Code

De iOS- en Android-iconen droegen nog de fotokat. Die zijn nu bijgesneden — en het handwerk eronder is vervangen door een script, want zes sets met de hand bijhouden is de fout die daarna nog een keer gemaakt wordt. ## Wat er verandert - **iOS**: 15 formaten (20–1024), uit `Contents.json`. - **Android**: 5 mipmap-dichtheden (48–192). - **Linux en Windows**: opnieuw gesneden. Zie hieronder — ze waren gisteren nog uit de verkeerde bron gemaakt. - **macOS**: geen byte verschil. Dat is een uitkomst, geen keuze. - **web**: onaangeraakt, met opzet. ## Twee dingen die boven water kwamen **De master was niet wat de documentatie zei.** Gisteren schreef ik op dat alles uit `assets/images/ocideck-logo.png` komt. Dat klopte niet: de échte master is `macos/…/app_icon_1024.png`. Het in-app-logo is 512 pixels; de master is 1024 en draagt ruim drie keer zoveel randdetail (randafwijking 0,22 tegen 0,08 na opschalen). Voor het 1024-icoon dat Apple in de App Store toont is dat het verschil tussen scherp en zacht. Elk formaat is nu een verkleining, nooit een vergroting — en daarom heb ik Linux en Windows van gisteren meteen opnieuw gesneden; die waren meetbaar zachter (randscherpte 0,29 tegen 0,39). **Het script reproduceert de gecommitte macOS-set bit voor bit.** Dat is het bewijs dat dit hetzelfde recept is als waarmee die set ooit gesneden is, en niet een nieuw recept dat er toevallig op lijkt. Zonder die uitkomst zou ik de master niet hebben durven verplaatsen. ## De uitzondering die blijft De webiconen komen wél uit het in-app-logo, met zijn ruimere marge. Ik heb dat eerst als vergissing behandeld en willen rechttrekken; nameten liet zien dat het een eigen, consistente regel is — de gecommitte set komt op 0,3 tot 1,9% na uit "logo, recht verkleind", en maskable is datzelfde op 80% in een wit vlak. Een favicon staat in een tabblad naast andere favicons, niet in een dock. Dus vastgelegd in het script in plaats van gelijkgetrokken, en de webbestanden zijn teruggezet: 1% herbemonsteringsruis in vijf binaire bestanden is geen winst. ## Bewaking `test/platform_icon_branding_test.dart` liep over vier doelen en loopt nu over zes. Het argument dat iOS/Android geen bouwdoel zijn valt weg zodra ze in de generator meelopen — een set die niemand bewaakt is precies hoe Linux en Windows een maand achterliepen. Twee toetsen erbij die alleen voor iOS gelden: | toets | wat hij vangt | | --- | --- | | geen alfakanaal | App Store Connect weigert dat. **Deze stond ook groen tegen de oude set** — hij vangt niet de rebrand maar de volgende bron: sinds #735 liggen er varianten mét een echt transparante achtergrond naast. | | maat per bestand | De naam noemt de púntmaat, niet de pixelmaat: een `@3x` van 20 punt is 60 pixels. Wie dat verwart levert een set in die Xcode zwijgend accepteert. | Tegen de oude mobiele iconen wordt de tekeningtoets rood (0,68 tegen drempel 0,20) en de kleurtoets ook (9,8% tegen 1%). Eerst zo gedraaid, daarna pas groen. **Een correctie op mezelf**: ik dacht onderweg dat ImageMagick bij 20 en 29 pixels een alfakanaal terugzette, en had daar een commentaarregel over geschreven. Nagemeten klopte dat niet — `magick identify` meldt "srgb 4.0" ook voor een PNG zónder alfa; het onderscheid zit in de letter, niet in het getal. De toets blijft (het is een echte Apple-eis), de onjuiste verklaring is eruit. ## Wat ik níet heb gedaan Bij 20 pixels blijft de lijntekening flets. Dat is de prijs van een fijn merk en het geldt op elk platform gelijk — de macOS-16 ziet er al maanden zo uit, en de nieuwe is er niet van te onderscheiden. Een apart, vetter tekentje voor de kleinste maten is een ontwerpkeuze, geen icoonregeneratie; die heb ik niet in deze PR genomen. ## Poorten - `make check` — exit 0. Opnieuw gedraaid ná de rebase op `c6adf9f0`. - `make check-secrets` — exit 0, gitleaks en trufflehog schoon over werkboom én historie. - `make sast` — 0 bevindingen over 688 bestanden. - `bash -n` over het script; shellcheck staat niet op deze machine, dat is dus níet gedraaid. - Geen SBOM: geen afhankelijkheid gewijzigd. Het script voegt wel een *ontwikkel*-eis toe (ImageMagick), maar niets dat meereist in een build. Bewakerstap overgeslagen: geen bestandsformaat, opslag, afhankelijkheid, uitgaand verkeer of publieke belofte geraakt. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
De vorige ronde repareerde Linux en Windows met de hand. Zes sets met de hand
bijhouden is de fout die daarna nog een keer gemaakt wordt — de rebrand van juni
vergat er al twee — dus dat handwerk is nu scripts/regenerate_icons.sh.

Meteen daarmee gesneden: de iOS-set (15 formaten) en de Android-mipmaps (5
dichtheden), die nog de fotokat droegen. Geen ondersteunde bouwdoelen, maar wel
iconen die in de repo staan.

Twee dingen kwamen bij het schrijven boven water:

De eigenlijke master is niet assets/images/ocideck-logo.png maar de macOS-1024.
Die draagt ruim drie keer zoveel randdetail (randafwijking 0,22 tegen 0,08 na
opschalen), en dat telt precies daar waar het opvalt — het 1024-icoon in de App
Store. Elk formaat is nu een verkleining, nooit een vergroting; Linux en Windows
zijn daarom opnieuw gesneden en zijn scherper dan gisteren.

Het script reproduceert de gecommitte macOS-set bit voor bit. Dat is het bewijs
dat dit hetzelfde recept is als waarmee die ooit gesneden is, en niet een nieuw
recept dat er toevallig op lijkt.

De webiconen blijven bewust een uitzondering: die komen uit het in-app-logo met
zijn ruimere marge, want een favicon staat in een tabblad en niet in een dock.
Nagemeten — het gecommitte bestand komt op 0,3 tot 1,9% na uit dat recept — en
daarom vastgelegd in plaats van rechtgetrokken.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
De tekening- en kleurtoetsen liepen over de vier bureaubladdoelen; iOS en
Android stonden er buiten omdat ze geen bouwdoel zijn. Dat argument valt weg nu
ze meelopen in de generator: een set die niemand bewaakt is precies hoe Linux en
Windows een maand achterliepen.

Twee toetsen erbij die alleen voor iOS gelden:

- Geen alfakanaal. App Store Connect weigert dat. Deze stond ook groen tegen de
  oude set — hij vangt niet de rebrand maar de volgende bron: sinds #735 liggen
  er varianten mét een echt transparante achtergrond naast, en wie daaruit
  snijdt loopt pas bij het inleveren stuk.
- Elk bestand op de maat die Contents.json opvraagt. De naam noemt de púntmaat,
  niet de pixelmaat: een @3x van 20 punt is 60 pixels. Wie dat verwart levert
  een set in die Xcode zwijgend accepteert en die op het toestel verkeerd
  schaalt.

De tekeningtoets is tegen de oude mobiele iconen rood gedraaid (0,68 tegen een
drempel van 0,20), de kleurtoets ook (9,8% tegen 1%).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
docs(build): de icoonsectie wees naar de verkeerde master
Some checks failed
ci / gate (pull_request) Failing after 35m38s
2497078485
Sinds gisteren stond er dat alle sets uit assets/images/ocideck-logo.png komen,
met twee commando's om over te tikken. Allebei achterhaald: de master is de
macOS-1024, en overtikken is nergens meer voor nodig — er staat nu één script.

Ook opgeschreven wat het onderzoek van vandaag opleverde: waarom het web een
andere bron houdt, waarom de achtergrond ondoorzichtig wit is, en dat ios/ en
android/ geen bouwdoel zijn maar wel bijgehouden worden.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
brenno merged commit 0c93962e30 into main 2026-07-23 18:21:28 +00:00
brenno deleted branch fix/mobiele-iconen-huisstijl 2026-07-23 18:21:29 +00:00
Sign in to join this conversation.
No description provided.