search

google / fonts

Font files available from Google Fonts, and a public issue tracker for all things Google Fonts
https://fonts.google.com
18.12k stars 2.61k forks source link

iOS 14 and some fonts #2688

Open c00lib1n opened 4 years ago

c00lib1n commented 4 years ago

Cyrrilic symbols in some fonts drawed by latin symbols after iOS14 update. Only at iOS14, only certain fonts, only in direct html\css embedding (NOT with codepen or GoogleFonts fitting)

For example: https://fonts.google.com/specimen/Montserrat https://fonts.google.com/specimen/Arsenal https://fonts.google.com/specimen/Merriweather https://fonts.google.com/specimen/Raleway

Test words: "Алая вспышка осветила силуэт зазубренного крыла." 'k' symbol must be 'к' 'ш' 'л' 'в' and another - taken from latin.

Left on picture - screenshot from iOS14 device, right - same page on DevTools

93610016-2c038580-f9d5-11ea-8588-55b69157ecc2

Also: https://github.com/JulietaUla/Montserrat/issues/109

thlinard commented 4 years ago

The example certainly doesn't show Latin characters, but the Bulgarian variant of Cyrillic characters. The behavior is reproducible with an test file using lang="bg". If Safari (?) on iOS 14 does this by default, it's definitely a bug.

c00lib1n commented 4 years ago

Yes, it`s Safari iOS 14 and default embedding.

My test example: css2?family consist some another fonts - i try find others incorrect rendering fonts.

<!DOCTYPE html>
<html lang="ru">
<head>
    <meta charset="windows-1251"/>
    <title>head</title>
    <link href="https://fonts.googleapis.com/css2?family=Alegreya+Sans&family=Arsenal&family=Exo+2&family=Merriweather&family=Montserrat&family=Noto+Sans&family=Open+Sans&family=Oswald&family=PT+Sans&family=Play&family=Raleway&family=Roboto&family=Roboto+Condensed&family=Rubik&family=Source+Sans+Pro&family=Spectral+SC:wght@200&display=swap" rel="stylesheet">
</head>
<body style="padding: 20px">
    <div style="font-size: 32px; padding-bottom: 30px">
      <b>Font By Default</b> <br>
      Алая вспышка осветила силуэт зазубренного крыла.
    </div>
    <div style="font-family: sans-serif; font-size: 32px; padding-bottom: 30px">
      <b>sans-serif By Default</b> <br>
      Алая вспышка осветила силуэт зазубренного крыла.
    </div>
    <div style="font-family: 'Montserrat', sans-serif; font-size: 32px; padding-bottom: 30px">
      <b>Montserrat</b><br>
      Алая вспышка осветила силуэт зазубренного крыла.
    </div>
    <div style="font-family: 'Raleway', sans-serif; font-size: 32px; padding-bottom: 30px">
      <b>Raleway</b><br>
      Алая вспышка осветила силуэт зазубренного крыла.
    </div>
    <div style="font-family: 'Merriweather', sans-serif; font-size: 32px; padding-bottom: 30px">
      <b>Merriweather</b> <br>
      Алая вспышка осветила силуэт зазубренного крыла.
    </div>
    <div style="font-family: 'Arsenal', sans-serif; font-size: 32px; padding-bottom: 30px">
      <b>Arsenal</b> <br>
      Алая вспышка осветила силуэт зазубренного крыла.
    </div>
    </body>
</html>
thlinard commented 4 years ago

lang="ru" shoud not display these glyphs. Definitely a bug in Safari on iOS 14 (not reproducible on Safari 14 for macOS 10.15.6). Contact Apple.

c00lib1n commented 4 years ago

lang="ru" or lang="bg" don`t change anything in render. It is bug reproducing only at mobile iOS 14 :( , desktop browser work correctly.

If i dowload this font (woff2 format) and direct inmplement on page (without googlefont API) - all worked out in iOS 14 and looks good.

I think, GoogleFont return specific fonts set depending at devices, and this set somehow incorrect with Montserrat or Merriweather. But PT Sans, for example, work correctly

It is bug in iOS14 (invalid request or device type?) and bug in GoogleFont (on desktop you return all font, to mob iOS14 - not all :) ?) and bug in font developers (maybe, set dont consist some certain files of font?)

thlinard commented 4 years ago

Well, you could be right. Safari on iOS 14 is new, and perhaps Google servers incorrectly detect it and serve the wrong files (but the source font files are fine: OK for Russian, and OK for Bulgarian when they need to be).

@davelab6: perhaps a bug on Google side?

Grawl commented 3 years ago

URLs of files are not different on iOS and in Chrome on macOS

bonzoSPb commented 3 years ago

Any solution?

c00lib1n commented 3 years ago

I`m uploaded fonts to local path and apply equal sets to any devices. Direct connection still working incorrect

thlinard commented 3 years ago

I`m uploaded fonts to local path and apply equal sets to any devices. Direct connection still working incorrect

Definitely a bug on Google's side, then.

bonzoSPb commented 3 years ago

@davelab6 can you fix this?

gigantz commented 3 years ago

To fix this bug, add this into your global style file

* {
  -webkit-locale: auto;
  white-space: normal;
}

ps. tested only for Montserrat font

Grawl commented 3 years ago

Good workaround!

baikov commented 3 years ago

To fix this bug, add this into your global style file

* {
  -webkit-locale: auto;
  white-space: normal;
}

ps. tested only for Montserrat font

I only used the first rule and it works in my case. 

* {
  -webkit-locale: auto;
}

The second sometimes breaks the layout. Tested for Montserrat.

gigantz commented 3 years ago

with only -webkit-locale: auto I still had problems with some texts with white-space: pre-wrap style. This value white-space: normal fixed for it for me.

0leg53 commented 3 years ago

Thanks for your investigation! After today iOS update to 14.2, the issue is relevant again. I have * { -webkit-locale: auto; white-space: normal;} string in css, at iOS 14 and 14.1 Montserratfont works fine with cyrillic, but now at 14.2 Mobile Safari pushing this css: image

Any ideas on how to fix it?

sergeyboldetsky commented 3 years ago

After updating to iOS 14.2 * { -webkit-locale: auto; white-space: normal;} does not respond, and the font has returned to a curved format like this: https://github.com/google/fonts/issues/2688#issue-705345614

Any ideas on how to fix it?

Slavsquat commented 3 years ago

Yeah, there doesn't seem to be a workaround this time. I'm surprised not that many people have actually raised this issue as of yet. Virtually any website using one of the affected fonts in Cyrillic is hugely affected because the bugged font is quite unpleasant to look at.

thlinard commented 3 years ago

Yeah, there doesn't seem to be a workaround this time. I'm surprised not that many people have actually raised this issue as of yet. Virtually any website using one of the affected fonts in Cyrillic is hugely affected because the bugged font is quite unpleasant to look at.

Well, I guess the opinion of Bulgarian users differs...

@davelab6 @m4rc1e: I tested with self-hosted fonts. The bug is definitely on Google's side (at least, the slimmed down version served by Google servers doesn't please Safari). Cinzel issue (https://github.com/NDISCOVER/Cinzel/issues/4) shows that the problem can also affect the appearance of Latin characters (with a Turkish variant for the i).

According to my tests, it seems that Safari for iOS (not Safari for macOS, at least not on macOS 10.15.7) has become locl-aware, like Firefox and Chrome.

Edit: a locl feature test page.

kpushkov commented 3 years ago

If you are looking for a temporary solution, using the ttf format helped me.

@font-face {
    font-family: 'Montserrat';
    font-style: italic;
    font-weight: 700;
    font-display: swap;
    src: local('Montserrat Bold Italic'), local('Montserrat-BoldItalic'), url(https://fonts.gstatic.com/s/montserrat/v15/JTUPjIg1_i6t8kCHKm459WxZcgvD-w.ttf) format('truetype');
}
thlinard commented 3 years ago

If you are looking for a temporary solution, using the ttf format helped me.

@font-face {
    font-family: 'Montserrat';
    font-style: italic;
    font-weight: 700;
    font-display: swap;
    src: local('Montserrat Bold Italic'), local('Montserrat-BoldItalic'), url(https://fonts.gstatic.com/s/montserrat/v15/JTUPjIg1_i6t8kCHKm459WxZcgvD-w.ttf) format('truetype');
}

No need of ttf. You can use the WOFF2 from the primary repositories:

Slavsquat commented 3 years ago

Google Fonts website gives me both variations (normal and broken) of Montserrat font depending on if there were originally Latin or Cyrillic symbols in the "Type something" field. 🤔

UPD: After some further testing, Google Fonts' behaviour seems to be impacted by presence or absence of numerics in the "Type something" field. Add or remove a number and refresh the page to see the effect.

image

sermelipharo commented 3 years ago

Got into same issue on Safari Version 14.0.1 (16610.2.11.51.8) with Big Sur 11.0.1 (20B29) IMAGE 2020-11-16 10:19:34 IMAGE 2020-11-16 10:19:46

c00lib1n commented 3 years ago

Confirm previous notice - desktop Safari inherit this problem behavior Also, after Big Sur update my local fonts solution lost bulletproofing - rouble symbol was replaced standard serif fonts

Screenshot 2020-11-16 at 21 20 54
Crow26ru commented 3 years ago

I think this problem is due to the wrong unicode-range for Cyrillic. I checked this bug with Cyrillic unicode-range from Google use Cyrillic subset for Montserrat font on iPhone 7. To fix this bug, download Montserrat font without subsets.

UPD: Need detach and remove glyphs in font from 0x10000 address.

thlinard commented 3 years ago

Got into same issue on Safari Version 14.0.1 (16610.2.11.51.8) with Big Sur 11.0.1 (20B29)

Hi @sermelipharo ,

Could you post a screenshot of the following page with Safari on macOS 11: http://www.georgduffner.at/ebgaramond/tests/locltest.html

Thanks!

sermelipharo commented 3 years ago

looks fine to me

Screenshot 2020-11-18 at 13 10 52
thlinard commented 3 years ago

looks fine to me

Indeed!

Here is the same test with Safari 14.0.1 on macOS 10.15.7:

Safari 14 0 1 on macOS 10 15 7

So, as I thought, Safari 14, on iOS and macOS 11 (but not on macOS 10.15) has become locl-aware (which Firefox and Chrome were for a long time already — a locl-aware browser can display different glyphs depending on the language declared in the HTML code). But something doesn't satisfy Safari in the special version of the fonts served by Google's servers, and it displays alternative glyphs regardless of the declared language (Bulgarian variant for a Russian page, Turkish variant for an English page, etc.).

sermelipharo commented 3 years ago

yeah, it feels exactly like you've described

parfilov commented 3 years ago

@thlinard do you mean that it's Apple's issue and we should jiggle them?

Grawl commented 3 years ago

I can see this issue for Safari 14.0.1 (16610.2.11.51.8) on macOS Big Sur 11.0.1 (20B29)

-webkit-locale: auto; workaround is not working here.

Even more, removing lang='ru' from <html> not works.

No issue for Chrome or Firefox.

parfilov commented 3 years ago

Ok. I tried to connect Montserrat locally:

parfilov commented 3 years ago

I can see this issue for Safari 14.0.1 (16610.2.11.51.8) on macOS Big Sur 11.0.1 (20B29)

-webkit-locale: auto; workaround is not working here.

Even more, removing lang='ru' from <html> not works.

No issue for Chrome or Firefox.

Same issue

thlinard commented 3 years ago

@thlinard do you mean that it's Apple's issue and we should jiggle them?

Hi @parfilov

Well, my best guess is that it's a mix.

WoW-rotfl commented 3 years ago

I've replaced g fonts by https://www.cdnfonts.com/montserrat.font - temporary solution until it's fixed. Not so good compressed but acceptable

shbov commented 3 years ago

I've replaced g fonts by https://www.cdnfonts.com/montserrat.font - temporary solution until it's fixed. Not so good compressed but acceptable

It worked for me.

upd: After a while the bug appeared again

karanevsky commented 3 years ago
image

Not a Googles font. Same problem with Cyrillic. https://type.today/ru/signal_mono

Grawl commented 3 years ago

proof to confirm:

image

Opera on the left, Safari TP on the right. macOS 11 Big Sur.

iksent commented 3 years ago

Fonts from https://google-webfonts-helper.herokuapp.com/ with manual import works OK.

thlinard commented 3 years ago

https://google-webfonts-helper

It would be to flee from Charybdis and fall into Scylla. google-webfonts-helper is obsolete when it comes to Variable Fonts (issue #2602 for example, or https://github.com/NDISCOVER/Exo-2.0/issues/11).

yuliayuyu commented 3 years ago

I've connected Montserrat from Adobe Fonts. In the settings of the web project in the section "Font Display" you need to install SWAP. The font is now displayed correctly.

Снимок экрана 2020-12-02 в 15 42 20

The solution is suitable for Tilda.cc

sklazer commented 3 years ago

Same issue there.

Only helped including <link href="http://fonts.cdnfonts.com/css/montserrat" rel="stylesheet"> at the <head> block. Other solutions wont work for me

(WordPress)

setlab commented 3 years ago

Same problem with Montserrat Alternates

This works for both:

<link href="http://fonts.cdnfonts.com/css/montserrat" rel="stylesheet">
<link href="http://fonts.cdnfonts.com/css/montserrat-alternates" rel="stylesheet">
delibash commented 3 years ago

Confirming same for https://fonts.google.com/specimen/Lora Italic.

delibash commented 3 years ago

Yeah, there doesn't seem to be a workaround this time. I'm surprised not that many people have actually raised this issue as of yet. Virtually any website using one of the affected fonts in Cyrillic is hugely affected because the bugged font is quite unpleasant to look at.

Well, I guess the opinion of Bulgarian users differs...

@davelab6 @m4rc1e: I tested with self-hosted fonts. The bug is definitely on Google's side (at least, the slimmed down version served by Google servers doesn't please Safari). Cinzel issue (NDISCOVER/Cinzel#4) shows that the problem can also affect the appearance of Latin characters (with a Turkish variant for the i).

According to my tests, it seems that Safari for iOS (not Safari for macOS, at least not on macOS 10.15.7) has become locl-aware, like Firefox and Chrome.

Edit: a locl feature test page.

How does the opinion of Bulgarian users resolve this issue for Russian users? Cause that's where the problem lies.

thlinard commented 3 years ago

How does the opinion of Bulgarian users resolve this issue for Russian users? Cause that's where the problem lies.

I was pointing out that Cyrillic is not only used in Russia, and what sounds horrible to a Russian reader may seem natural to a Bulgarian.

But as for the problem, we've made some progress in explaining it: see https://github.com/google/fonts/issues/2688#issuecomment-729585042 and https://github.com/google/fonts/issues/2688#issuecomment-732762754

theRuslan commented 3 years ago

Same problem with Manrope font.

iOS: photo_2020-12-15_19-01-19

Android: photo_2020-12-15_19-01-31

delibash commented 3 years ago

I was pointing out that Cyrillic is not only used in Russia, and what sounds horrible to a Russian reader may seem natural to a Bulgarian.

But as for the problem, we've made some progress in explaining it: see #2688 (comment) and #2688 (comment)

Thanks for the reference. But I fail to see your point. Since the discussion is specifically about Russian not rendering correctly.

thlinard commented 3 years ago

Thanks for the reference. But I fail to see your point. Since the discussion is specifically about Russian not rendering correctly.

No, the problem should not be reduced to that. https://github.com/NDISCOVER/Cinzel/issues/4 is the exact same problem and it affects English pages rendered with Turkish characters.

m4rc1e commented 3 years ago

Thanks for all the info folks. I will dig into this issue to see what's happening.

Just a pointer but we absolutely love minimal test cases :-). I'll make one up now.

thlinard commented 3 years ago

All the families which have this issue have been made using the Glyphsapp font editor.

I'm not sure it's a good lead either. Self-hosted WOFF and WOFF2 files don't seem to have this problem, which seems to only appear for files served by the API.

I had recommended these sources: