Lettertype kleur verschil Windows / Apple

[Robbie T]

Ik ben bezig met de ontwikkeling van een website in WordPress. Hiervoor gebruik ik Astra Pro en Elementor Pro.

Het blijkt dat er verschil zit in de kleur van het lettertype.
Dit zou moeten zijn #CCCCCC en dat word binnen Windows 10 ook keurig zo getoond, op een Apple lijkt het een tint lichter te zijn.
Ik heb dit geprobeerd op te lossen met een stukje css;

code:

-webkit-text-fill-color

maar dat lijkt niet de oplossing te zijn.

Heeft iemand enig idee hoe dit kan en belangrijker hoe ik het kan oplossen?
Het gekke is dat de huidige website wel hetzelfde wordt getoond op Windows en Apple, daarbij word ook gebruik gemaakt van font Lato met kleur #CCCCCC.

edit:

Wegens bedrijfsnaam welke voort kom in afbeelding, afbeelding weg gehaald.

[ Voor 17% gewijzigd door Robbie T op 12-07-2021 10:03 ]

[RobIII]

Ik denk dat beiden een ander kleurprofiel gebruiken... En dat betekent ook dat je 't nooit écht kunt oplossen; je hebt geen controle over welk kleurprofiel een willekeurige bezoeker gebruikt. En dat is dus iets waar je je bij neer zult moeten leggen.

MacOs
Windows

Robbie T schreef op vrijdag 9 juli 2021 @ 22:23:
Het gekke is dat de huidige website wel hetzelfde wordt getoond op Windows en Apple, daarbij word ook gebruik gemaakt van font Lato met kleur #CCCCCC.

Is het niet optisch dan? Want ik zie in je screenshot ook twee verschillende groottes...

Edit:



Meten == weten. Het is gewoon optisch want het is exact dezelfde kleur als ik de color-picker los laat op de rood omcirkelde pixels. En dan zijn evt. (al dan niet optische) kleurverschillen te verklaren met meer/minder (anti-)aliasing en/of subpixel rendering en dat soort ongein.

[ Voor 168% gewijzigd door RobIII op 09-07-2021 22:43 ]

[Robbie T]

Technisch gezien zou het dus gelijk moeten zijn. Maar wat ik dan nog steeds niet begrijp is hoe het kan dat de huidige website wel exact gelijk toont en de nieuwe website niet.

[RobIII]

Again: meten == weten. Zoek de verschillen in de verscheidene mogelijke oorzaken die ik heb aangegeven. En appels met apples vergelijken en niet met peren zoals in je screenshot. En, nee, dat was geen Apple grapje

[ Voor 35% gewijzigd door RobIII op 09-07-2021 23:00 ]

[TomsDiner]

Jou screenshot bevat bij de meeste letters als helderste kleur c4c4c4. Vaak maar enkele pixels, want zoals @RobIII al aangeeft zit er anti-alias overheen, en hoeven beiden OS-sen niet identieke renderwijzes voor letters te hanteren. Maar aan de rechterkant zijn de letters iets dikker, waardoor de kleur beter uitkomt. Ook is de letterbreedte rechts bijna 8% groter.... En kijk eens goed, zelfs de lijnhoogte rechts is veel hoger!

Gokje. Zit ik soms (rechts) naar een retina scherm te kijken, waardoor er veel meer pixels per letter gebruikt zullen worden? Dan is het namelijk wel logisch dat er iets meer pixels niet aan de rand liggen, en dus de zuivere kleur zullen bevatten.

Overigens is jou afbeelding een PNG, en die zal dus ook weer compressieverlies in de afbeelding hebben. Misschien komt het daardoor dat ik geen #cccccc maar #c4c4c4 zie.

[RobIII]

TomsDiner schreef op vrijdag 9 juli 2021 @ 23:06:

Overigens is jou afbeelding een PNG, en die zal dus ook weer compressieverlies in de afbeelding hebben.

PNG is (doorgaans) lossless Bij een JPG had je gelijk gehad

[DonJunior]

aan de andere kant.. hoeveel bezoekers zitten tegelijkertijd op twee schermen naast elkaar op een Apple én Windows machine je website te vergelijken..
Wat ik doel te zeggen, waarschijnlijk gaat niemand dit merken behalve jij als ontwikkelaar nu.
Plus daarnaast heeft de ene persoon wel 'nachtmodus' (blauw licht reductie) aan staan en de ander niet, maar die heeft nu juist het contrast en het kleurprofiel op de monitor aangepast..
Conclusie: Alle bezoekers zien toch iets anders dan dat jij nu ziet en waar jij nu je tijd in steekt.
Mijn advies: Niet te druk over maken en lekker doorbouwen.

[Robbie T]

DonJunior schreef op vrijdag 9 juli 2021 @ 23:10:
aan de andere kant.. hoeveel bezoekers zitten tegelijkertijd op twee schermen naast elkaar op een Apple én Windows machine je website te vergelijken..
Wat ik doel te zeggen, waarschijnlijk gaat niemand dit merken behalve jij als ontwikkelaar nu.
Plus daarnaast heeft de ene persoon wel 'nachtmodus' (blauw licht reductie) aan staan en de ander niet, maar die heeft nu juist het contrast en het kleurprofiel op de monitor aangepast..
Conclusie: Alle bezoekers zien toch iets anders dan dat jij nu ziet en waar jij nu je tijd in steekt.
Mijn advies: Niet te druk over maken en lekker doorbouwen.

Ik maak me er niet druk om, maar de klant wel. Dat is het probleem. Het is een wat discussie puntje zullen we maar zeggen.
Ik zal nog eens c4c4c4 proberen.

[TomsDiner]

RobIII schreef op vrijdag 9 juli 2021 @ 23:08:
[...]

PNG is (doorgaans) lossless Bij een JPG had je gelijk gehad

Waarom moet ik dan altijd een compressie level instellen?

[ Voor 132% gewijzigd door TomsDiner op 09-07-2021 23:53 ]

[Hahn]

TomsDiner schreef op vrijdag 9 juli 2021 @ 23:38:
[...]

Waarom moet ik dan altijd een compressie level instellen?

https://www.howtogeek.com...-a-compression-parameter/

TL;DR: compressie betekent niet altijd dat er data verloren gaat. In het geval van PNG zorgt meer compressie voor kleinere bestanden, die zwaarder zijn om te gebruiken, maar wel lossless kunnen zijn.

[TomsDiner]

We gaan te ver off topic. Maar serieus. Je wil melden -zoals op die site staat- dat ik niet altijd gelijk hoef te hebben? Is het goed dat ik dit verder laat zitten? Ik gaf het aan als mogelijke reden van het verschil tussen #ccccccc en #c4c4c4, en bij PNG compressie wordt meestal het aantal kleuren verlaagd, omdat PNG net als GIF heel goed comprimeerd op grote egale vlakken.... Dus het lijkt mij een aannemelijke verklaring die niet door jou verhaal wordt tegen gesproken....

[Hahn]

TomsDiner schreef op vrijdag 9 juli 2021 @ 23:53:
We gaan te ver off topic. Maar serieus. Je wil melden -zoals op die site staat- dat ik niet altijd gelijk hoef te hebben? Is het goed dat ik dit verder laat zitten? Ik gaf het aan als mogelijke reden van het verschil tussen #ccccccc en #c4c4c4, en bij PNG compressie wordt meestal het aantal kleuren verlaagd, omdat PNG net als GIF heel goed comprimeerd op grote egale vlakken.... Dus het lijkt mij een aannemelijke verklaring die niet door jou verhaal wordt tegen gesproken....

Ik snap niet waar ik deze toon aan verdiend heb. Jij stelt de vraag waarom je compressie moet instellen, waarmee je leek te insinueren dat PNG wel altijd lossy zou zijn, ik geef antwoord op die vraag, that's all.

[Onbekend]

Het lijkt wel of rechts het lettertype zelf groter wordt weergegeven. Het zoom-niveau staat gewoon op 100%?
En op een lege html-pagina met dit lettertype heb je nog steeds het zelfde probleem?

[DonJunior]

Robbie T schreef op vrijdag 9 juli 2021 @ 23:28:
[...]


Ik maak me er niet druk om, maar de klant wel. Dat is het probleem. Het is een wat discussie puntje zullen we maar zeggen.
Ik zal nog eens c4c4c4 proberen.

Oh da's zuur..
Overigens bedoelde ik het niet aanvallend.. (weet niet of het zo over kwam)
Sterkte ermee (de klant dus.. de kleuren kom je vast wel aan uit)

[Ramon]

@Robbie T kan je eens een jsfiddle of codepen maken met het relevante deel van de betreffende code? Dan kunnen we meekijken/experimenteren.

[Tom]

Robbie T schreef op vrijdag 9 juli 2021 @ 23:28:
[...]


Ik maak me er niet druk om, maar de klant wel. Dat is het probleem. Het is een wat discussie puntje zullen we maar zeggen.
Ik zal nog eens c4c4c4 proberen.

De kleur is hetzelfde. Het is gewoon een andere manier van fonts (of eigenlijk anti-aliasing) renderen. Bij lage font-weight valt dat sneller op. Je kunt de rendering met de css property font-smoothing beïnvloeden maar ik zou liever alles op de defaults houden, dat werkt voor 99,9% van de websites. Leg je klant uit dat dit soort kleine renderverschillen bestaan en normaal zijn, anders bestaat de kans dat ze met een vergrootglas alles gaan bekijken.

[Robbie T]

Tom schreef op zaterdag 10 juli 2021 @ 09:45:
[...]

De kleur is hetzelfde. Het is gewoon een andere manier van fonts (of eigenlijk anti-aliasing) renderen. Bij lage font-weight valt dat sneller op. Je kunt de rendering met de css property font-smoothing beïnvloeden maar ik zou liever alles op de defaults houden, dat werkt voor 99,9% van de websites. Leg je klant uit dat dit soort kleine renderverschillen bestaan en normaal zijn, anders bestaat de kans dat ze met een vergrootglas alles gaan bekijken.

Er word al gekeken met een vergroot glas

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Ik zal eens kijken naar de font smoothing. Lastige is dat ik zelf geen apple apparaat heb en dus na elke wijziging moet vragen hoe het nu is.

[CH4OS]

Als de huige website het wel goed doet, wat maakt dat de nieuwe website het niet goed doet?

Verspil hier overigens niet teveel tijd aan, dat kost jou anders teveel tijd, de klant krijgt een hoge rekening en zal vinden dat het jouw probleem is dat het zo lang duurde. En jij bent hoe dan ook uiteindelijk de gebeten hond. Als de klant dusdanig aan het mierenneuken is op pixel niveau, moet je ze eigenlijk niet als klant willen hebben.

[ Voor 77% gewijzigd door CH4OS op 10-07-2021 10:27 ]

[RobIII]

Als de huidige website het wel 'goed' doet zit er dus een verschil in de CSS. Neem de (font gerelateerde) CSS over van de huidige website et voila. Of maak een uitgeklede testcase en met twee divjes met de CSS erop van beide sites en ga dan veranderen/weghalen/overnemen totdat je het verschil ziet; dan kun je als het goed is ook verklaren na afloop waar 't verschil in zat/zit.

TomsDiner schreef op vrijdag 9 juli 2021 @ 23:53:
en bij PNG compressie wordt meestal het aantal kleuren verlaagd

offtopic:
Dan doe je aan preprocessing; PNG zélf is niet lossy. Er zijn diverse tool die allerlei technieken (posterizing, indexed colors, averaging van pixels) toepassen om een PNG lossy te maken (een bekende is tinypng of pngmini) maar die haal je dan bewust over een PNG heen. Als je je afvraagt wat in jouw geval de compressielevel setting doet: sla eens een afbeelding op met compressielevel 0 en 100 en vergelijk ze dan pixel voor pixel - tenzij er ingebouwde 'lossy compressie' in je image editor aanwezig is (niet vaak) zou je aan de output 0 verschil moeten merken. Het verschil zit 'm in hoeveel CPU en geheugen je nodig hebt om een afbeelding te encoden/decoden in ruil voor een kleinere filesize, niet in de afbeelding zelf. Je kunt 't vergelijken met een compressielevel setting voor een RAR of ZIP o.i.d. (ook lossless). Maar mocht je een verschil ontdekken dan ben ik uiteraard benieuwd naar welke applicatie je gebruikt.

Maar, granted, het zou het verschil kunnen verklaren - het is IMHO alleen niet heel aannemelijk. Ik neem aan dat TS een screenshot heeft genomen en die geupload heeft en niet eerst nog door iets heen gehaald heeft. En al deed Tweakers aan lossy compressie bij upload; dan was 't verschil daar pas opgetreden en had TS dus geen verschil gezien. Daarbij zou links/rechts dezelfde behandeling krijgen.

Either way heeft niemand 't kwaad bedoeld

TomsDiner schreef op vrijdag 9 juli 2021 @ 23:53:
en bij PNG compressie wordt meestal het aantal kleuren verlaagd, omdat PNG net als GIF heel goed comprimeerd op grote egale vlakken

offtopic:
Die twee staan los van elkaar: als je de kleuren verlaagt haal je compressie uit 't feit dat je voor elke pixel geen RGBA (4 bytes) hoeft op te slaan maar enkel een 'pointer' naar de index van de kleur (hence Indexed color). De compressie uit grote egale vlakken haal je uit 't feit dat je kunt opslaan "hier staan 300 rode pixels" i.p.v. "rood, rood, rood, rood, rood, ..., rood" 300 keer. Dus het verband dat je hier legt, hoewel allebei relevant voor compressie, is er niet. Again; niet aanvallend bedoeld, gewoon uitleg voor diegenen die de materie interessant vinden.

Wat overigens ook niet helpt in de screenshot is de schaduw tussen beide afbeeldingen. Maar wellicht komt de screenshot van de klant @Robbie T ?

[ Voor 34% gewijzigd door RobIII op 10-07-2021 12:07 ]

[DJMaze]

Robbie T schreef op vrijdag 9 juli 2021 @ 23:28:
Ik maak me er niet druk om, maar de klant wel. Dat is het probleem.

Nee dat is niet jouw probleem.
Ik zou zo'n klant een keuze geven:

A. Hij gaat het accepteren
B. Hij gaat het naar een ander omdat zo'n klant jou veel meer gaat kosten dan je er aan gaat verdienen.

Schuif hem maar eens een monitor van €100 en een gecalibreerde van €1000 (liefst ook nog groot DPI verschil) voor zijn snuffert die aangesloten zijn op zelfde PC.
En speel het spelletje "ik zie, ik zie, wat jij niet ziet..."

Doe het zelfde met verschillende OS omdat niet elk OS het zelfde font heeft en je dan ook verschillen krijgt.
Font "Lato" heb ik namelijk niet, en zal nooit laden hier.

[ Voor 14% gewijzigd door DJMaze op 11-07-2021 11:24 ]

[Tom]

DJMaze schreef op zondag 11 juli 2021 @ 11:20:
[...]

Doe het zelfde met verschillende OS omdat niet elk OS het zelfde font heeft en je dan ook verschillen krijgt.
Font "Lato" heb ik namelijk niet, en zal nooit laden hier.

Daar zijn web-fonts voor uitgevonden

Voor de rest hoef je zoiets niet hoog te laten op lopen. Mijn ervaring is dat je het beste kunt uitleggen wat wel en niet mogelijk is. Daarmee leg je de bal terug bij hen en geef je ze wat alternatieven die wel haalbaar zijn. Stuur een voorbeeldje waarbij je een iets donkerdere kleur kiest of juist een iets dikkere variant van het font.

En als het op hun huidige site wel goed gaat, dan zou je de css even moeten uitpluizen. Via developer tools kun je op de computed tab bij een element zien welke zaken anders zijn t.o.v. de standaard rendering van je browser.

[Robbie T]

Dankzij "De Tip van Tom" (Wellicht leuk voor een wekelijkse rubriek ;-) met betrekking tot de font smoothing is het probleem opgelost!

Het volgende toegevoegd aan de CSS:
-webkit-font-smoothing: subpixel-antialiased;

en daarmee het probleem opgelost.
Bedankt!

[DJMaze]

Tom schreef op zondag 11 juli 2021 @ 11:40:
Daar zijn web-fonts voor uitgevonden

Dat is het hem nou juist. Die laden hier expres niet
uBlock Origin, Firewall, Firefox Focus, etc. etc.

Robbie T schreef op maandag 12 juli 2021 @ 10:05:
Het volgende toegevoegd aan de CSS:
-webkit-font-smoothing: subpixel-antialiased;

en daarmee het probleem opgelost.

Kijk dan ook even in Firefox...

[ Voor 34% gewijzigd door DJMaze op 12-07-2021 10:57 ]

[Robbie T]

DJMaze schreef op maandag 12 juli 2021 @ 10:54:
[...]

Dat is het hem nou juist. Die laden hier expres niet
uBlock Origin, Firewall, Firefox Focus, etc. etc.


[...]

Kijk dan ook even in Firefox...

Daar gaat alles goed gelukkig.

[Creepy]

DJMaze schreef op maandag 12 juli 2021 @ 10:54:
[...]

Dat is het hem nou juist. Die laden hier expres niet
uBlock Origin, Firewall, Firefox Focus, etc. etc.

Dan ben je een uitzondering, maar je lijkt hier wel te verwachten dat iedereen daar rekening mee houdt? Zo ja, niet zeuren aangezien je weet dat het overal anders kan zijn. Zo nee, waarom noem je dit dan?