Google web font renders differently on mobile Safari vs. desktop Chrome?

Asked 3/12, 2019 at 21:25 Answered 9/7, 2020 at 7:3

Solved html css fonts font-face google-webfonts

A Google web font (Signika) renders differently on desktop versus mobile. As illustrated by these screenshots, the kerning (space between letters) is larger on mobile than desktop, and the stroke is thinner. The letters on desktop also seem crisper, though this is more subjective.

Desktop (Chrome):

Mobile (Safari, iOS 12):

Codepen:

https://codepen.io/Crashalot/pen/3ff682e5aa123e1ac293ab19b06f1285

#pageBox h1 {
  margin: 30px auto;
  text-align: center;
}

h1 {
  font-size: 2em;
  font-weight: bold;
  line-height: 1.2em;
}

h1,
h2,
h3,
h4 {
  font-family: "Signika", Verdana, Tahoma, Arial, Sans-Serif;
  color: #7C7A7D;
}

<head>
  <link href="https://fonts.googleapis.com/css?family=Lato|Roboto|Signika|Source+Sans+Pro:400,700" rel="stylesheet">
</head>

<body>
  <div id="pageBox">

    <div class="header">
      <h1> Icon Editor </h1>
    </div>

  </div>
</body>

Signika portion of self-hosted font stylesheet:

@font-face {
  font-family: 'Signika';
  font-style: normal;
  font-weight: 400;
  src: url(https://fonts.gstatic.com/s/signika/v10/vEFR2_JTCgwQ5ejvG18mBlprZ0gk0w.woff2) format('woff2');
  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
/* latin */
@font-face {
  font-family: 'Signika';
  font-style: normal;
  font-weight: 400;
  src: url(https://fonts.gstatic.com/s/signika/v10/vEFR2_JTCgwQ5ejvG1EmBlprZ0g.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

Tertia answered 3/12, 2019 at 21:25 Comment(16)

Check out the values for font-smooth/-webkit-font-smoothing here – Asymptotic 3/12, 2019 at 21:39

@Asymptotic thanks for the suggestion, but the page says this property is non-standard and should be used. any other ideas? – Tertia 3/12, 2019 at 23:48

unfortunately no. This is the only way to do it, standard or not. The other option is to not "fix" it, and let each browser render fonts the way they've decided. – Asymptotic 3/12, 2019 at 23:58

If you need an identical look, use a webfont, and importantly: don't trust google webfonts. Their CSS includes local() loading first, which you should never allow. So get the CSS file their css link gives you, take that out, then host that CSS yourself, instead, so you know you're never letting the OS pick the font for you. – Basildon 7/5, 2020 at 1:58

When rendering a webfont a browser sets a series of default values on attributes (e.g. letter-spacing) that have to do with how the webfont is displayed, if these can be overridden by CSS then you can get similar look on different browsers. – Gleesome 10/5, 2020 at 11:2

@Mike'Pomax'Kamermans we only need to host the CSS file or the CSS file + the font file as another answer suggested? – Tertia 11/5, 2020 at 6:5

plus making sure you use rules that do not rely on "letting the system still pick", so now local(...) as one of the URLs. And because it's 2020, no dead formats either. So no eot or svg, and no system formats like ttf or otf. Just load the woff2 source with woff fallback. – Basildon 11/5, 2020 at 14:47

@Mike'Pomax'Kamermans ok thanks! where we can find the support for woff2 and woff? just want to know which browsers we lose by only supporting those two formats. thanks again for your help! – Tertia 13/5, 2020 at 2:55

caniuse.com is your friend in all matters of browser support information – Basildon 13/5, 2020 at 15:8

@Mike'Pomax'Kamermans ah didn't realize it even covered font formats! very cool. thanks for sharing. – Tertia 13/5, 2020 at 20:8

@Mike'Pomax'Kamermans could you post your suggestion as an answer please? we wound up doing this. thanks! – Tertia 16/5, 2020 at 6:44

@Mike'Pomax'Kamermans never mind, we tried your solution, and it didn't help unfortunately. still shows a different font on mobile safari. :( any other suggestions? – Tertia 16/5, 2020 at 6:47

@Mike'Pomax'Kamermans just to be clear, we self-hosted the font stylesheet. the signika font is the one failing to render. the question is also updated with the signika portion of the stylesheet, after ripping out local per your advice. – Tertia 16/5, 2020 at 6:53

That sure looks like the same font to me (those 'c' and 'i' are pretty distinct from any of the other fonts in your stack), just with different letter-spacing (and it looks like different aliasing) applied: are you sure your CSS is the only CSS that's kicking in, or do you have additional CSS/UI libraries that get to mess with the lettering? – Basildon 16/5, 2020 at 15:50

@Mike'Pomax'Kamermans good question. don't believe so, but how to verify this?perhaps the right approach is to use the answer from Tedskovsky below? – Tertia 16/5, 2020 at 21:46

I'd probably start with just remote debugging the phone? Why guess when you can just check. blog.idrsolutions.com/2015/02/… – Basildon 17/5, 2020 at 15:21

It turns out Safari alters the font if you use a font-weight not supported by a font (e.g., the font file only offers weights of 400 and 600, but you choose 700). Specifying a supported weight or using normal removed this issue.

Extremely frustrating, but hopefully our misery helps someone.

Tertia answered 9/7, 2020 at 7:3 Comment(0)

@crashalot the reason why the font looks different on Safari as to Chrome is that the webkits are ever so slightly different. The only way to avoid this problem really is to download the font files and then link them:

body {
...
font-family: Signika;
...
}

@font-face {
font-family: Signika;
src: url(signika.ttf);
}

Turnery answered 5/5, 2020 at 8:10 Comment(5)

hi thanks for your answer. isn' it possible to link directly to the google font files instead of self-hosting them? – Tertia 16/5, 2020 at 6:48

Hi @Tertia you can download Signika via Google Fonts – Turnery 16/5, 2020 at 23:30

sorry for the confusion. rephrased: what's the difference between self-hosting the font and linking to the one from google fonts? – Tertia 17/5, 2020 at 2:18

It will cause the font to have the exact properties of such font across all platforms. – Turnery 17/5, 2020 at 5:21

it turns out safari alters the font if you attempt to use a font-weight not supported by a font. using a supported font weight or using normal as the font-weight removed this issue. – Tertia 9/7, 2020 at 7:1

I wasn't sure from your question whether you were more interested in the why or the how to fix aspects. Assuming how to fix:

Since you used the word kerning, you are probably already aware of this, but I was able to match up the appearances by adjusting the following:

body { 
     letter-spacing: -0.1px; 
     transform: scale(1.05, 0.95);
}

If that doesn't look quite right to you, those values are of course adjustable.

font-kerning: none; is a little more severe, but does help normalize between engines a little bit.

For reference,

So, you could if you wish, detect mobile and/or safari via numerous other checks (which have already been answered in other questions, so I will omit here), and then apply the CSS above.

If, in fact you were asking about why there is a difference, that comes down to the rendering engine - but I will assume for now you are asking about normalizing appearances.

Smectic answered 7/5, 2020 at 1:55 Comment(1)

Finally found the right cause and solution! See the answer below, but tldr, you need to either use a supported weight or normal for the font weight. – Tertia 9/7, 2020 at 7:4

Recommended topics

Hot tags