Has the Google font naming convention officially changed recently?

Authoring
1

Has anyone else noticed that Google seems to have changed how multi-word font names must be specified to their Font API?

Where can I report this problem? Is Twitter the only way?

Previously, when a multi-word font family name was to be specified, the words in the name had to be separated by a “+” (plus).
For example,
https://fonts.googleapis.com/css?family=Droid+Sans
and
font-family: ‘Droid+Sans’;

Now, though, the words in the name have to be separated by a " " (space).
For example,
‘https://fonts.googleapis.com/css?family=Droid Sans’
and
font-family: ‘Droid Sans’;

Background:

Recently I found that my IF Stories (written in Twine/Twee/SugarCube, for what that’s worth) could no longer switch between Serif and Sans Serif fonts which were being loaded from Google. While trying to debug this problem today, I discovered that single-word fonts were loading correctly but multi-word fonts were not. When I replaced the pluses by spaces, they started working again.

I can find no mention of this change on Google’s font site. In fact, Google’s Web page

still says
Note: Replace any spaces in the font family name with plus signs (+).

1 Like
2

Are you using the @import that Google provide you to use for the CSS. For example below?

image
image323×737 30.9 KB

1 Like
3

Yes, that’s what I use.

1 Like
4

I would make a wild guess that it’s not a Google change, but a browser change. I don’t think it should ever have had a + in the CSS: font-family: Droid+Sans has always been wrong AFAIK? And I suspect that browsers maybe used to support this but have recently stopped?

But I think it should be a + in the URL. In the underlying protocol, URLs can’t contain spaces, so they always (under the hood) get translated to + or %20. I don’t remember off the top of my head which places you’re allowed to use a space, so it’s probably safer to use a + in the @import URL the way Google gives it to you…

2 Likes
5

That’s what I was doing – including the +. It no longer works for me. I’m getting the same symptoms with Firefox 106.0.5, Edge 107.0.1418.35 and Comodo Dragon 104.0.5112.81 (a chromium based browser).

ETA: It also fails in Chrome 107.0.5304.88 and SeaMonkey 2.53.14

1 Like
6

For those who might want to play with it, here’s a Zip containing the Twee/SugarCube source code for the test program and the HTML generated from it by tweego.

I’ve updated the “story” so it explicitly shows the results for font names with and without a plus, i.e. so the “reader” doesn’t have to edit the source code to see the failure.

test_fonts_v2.zip (156.5 KB)

1 Like
7

Hrm. Your test “story” works as I’d expect for me. I tried a bunch of combinations, and looked up the specs, and:

  • The @import url() can be either spaces or + symbols.
  • The font-family CSS rule must have spaces.

I tried it in Firefox/Edge/Chrome, same versions as you have, on Windows 10.

Sorry, but are you sure font-family: IBM+Plex+Sans used to work? I thought Google had always defined the names only with spaces. If you look at the CSS that Google is sending (those import urls) you’ll see:

@font-face {
  font-family: 'IBM Plex Sans';
  font-style: normal;
  font-weight: 400;
  src: [long hairy url...]
  [etc...]
}

I’m think it’s allowed for a font provider to give one of their fonts a name like IBM+Plex+Serif, but skipping through a bunch of snapshots on the wayback machine I didn’t find any times in the last four years that Google has done that. So I’d be surprised if font-family: IBM+Plex+Sans had ever worked…

4 Likes
8

Well, I thought it worked. Maybe I’m just mis-remembering. :frowning:

Thanks for the help!

2 Likes