Font Library: where to store the list of Google Fonts?

[matiasbenedetto]

What ?

For Font Library we need to host the list of available Google fonts somewhere.

Context

In Create Block Theme plugin, we are bundling the list of Google Fonts as a JSON file in the plugin source. We decided to do this because it was an easy way to do it, and it don't require any additional infrastructure. For the fonts library we used the same approach but due to the library is intended to be in core, maybe it could worth some additional infrastructure, like hosting this file possibly on wordpress.org.

More context:

What is the file?

The file is the data coming from Google Fonts API, processed to have a format like the font families in theme.json

Will this file be requested by site visitors?

Nope, site visitors will never request this file, it is used only in the editor by the font library.

How is the file used?

It's used in the font library to render the list of all fonts available to be installed by the user.

What are the benefits of hosting the file?

An update to this file will be automatically available for all the users (in CBT we update it with each release). Avoid adding ~150kb ( ~1.5 MB uncompressed ) to the WordPress zip.

:question: Do you think hosting the file is worth or convenient instead of bundling it?

Some ideas:

(non mutually excluyent)

• Host it on the wordpress.org CDN
• Bundle it into the distribution zip
• Bundle it into the distribution zip and update it using the WordPress code updates infrastructure.
• Split the file into multiple smaller ones.

:bulb: Do you have any other ideas or input? Please, share!

[mikachan]

My vote would be to host this on the wordpress.org CDN. I like the idea of having a font provider service that is independent of the WordPress install zip. This way it can be managed independently for updates, and doesn't add any extra weight to the install zip.

Maybe to start with, we could upload a static version of the google-fonts.json file somewhere appropriate on wordpress.org. Then as a follow-up, we could create a separate repo that holds a build tool for the file and keeps the hosted version up-to-date (i.e. automatically re-creates the .json file based on the latest list of fonts from Google, similar to how the Create Block Theme plugin handles the Google font updates).

[azaozz]

I'm most likely missing something here, but have a related question: Why a list of Google fonts? Has the use of external APIs that belong to third parties (corporations) been discussed somewhere?

Asking because this was one of the reason for the initial "Fonts API" patch to not be committed: user privacy issues in WordPress arising from use of third party APIs. Later on there was a court case in EU specifically about usage of Google Fonts. So is it really "wise" to expose all the WP sites to potential investigations of their use of a third party API for fonts?

As discussed several times before all the fonts that are available in the Google Fonts CDN are also available from other sources, for example https://fontsource.org/ and their GitHub repo at: https://github.com/fontsource/fontsource, and also as NPM packages. Seems using an open source provider would be better?

[hellofromtonya]

Where would the src point to pull the font asset file?

user privacy issues in WordPress arising from use of third party APIs. Later on there was a court case in EU specifically about usage of Google Fonts.

If each Google font asset file src comes from an open source party, such as wp . org, then the privacy concerns @azaozz mentioned should no longer be applicable. Serving the files from wp . org though would also require infrastructure work.

[azaozz]

Yea, the problem here is just with "possibly leaking private info to third parties". Using the wp.org APIs (like checking for updates, etc.) is part of WordPress.

[mikachan]

So is it really "wise" to expose all the WP sites to potential investigations of their use of a third party API for fonts?

I believe the idea with this issue is that there is a JSON file that lists all Google fonts which is built independently from anything else, so would not expose WP sites to third-party APIs. Only the build tool for the JSON file would interact with the Google font API. This is similar to how Create Block Theme supplies its list of Google fonts, in its fallback-fonts-list.json file. This file is kept up to date using a GitHub action, which is where the Google fonts API is interacted with.

Seems using an open source provider would be better?

I think this could also work well, but my current thinking is that it would be best to manage this also as an independent build tool that acts as a proxy between the font provider and the end users, so would probably require a similar new infrastructure.

Where would the src point to pull the font asset file?

The way this currently works in Create Block Theme is that when a font is chosen, the font file is copied from the Google file URL (e.g. http://fonts.gstatic.com/s/abeezee/v22/esDR31xSG-6AGleN6tKukbcHCpE.ttf) into the local assets location (for Create Block Theme this is the assets folder of the current theme; for the Font Library this could work similarly to image management). Therefore, the font src would point to a local version of the font asset file.

I hope I've helped answer some questions - @matiasbenedetto, pinging you as well in case I've missed anything or got anything wrong!

[priethor]

Just to confirm, even if this issue is grouped under the extensibility phase, it's still a strong requirement for the Font Library launch, which would become much less compelling with only manual upload. We can iterate later by adding more font indexes, and Google should only be one of many font sources; adding by third parties is indeed part of a second phase focused on extensibility.

Is there any blocker to adding a consent popup before browsing and previewing the fonts to avoid connecting to Google without prior notice?

[matiasbenedetto]

Just to confirm, even if this issue is grouped under the extensibility phase, it's still a strong requirement for the Font Library launch, which would become much less compelling with only manual upload. We can iterate later by adding more font indexes, and Google should only be one of many font sources; adding by third parties is indeed part of a second phase focused on extensibility.

Thanks for confirming @priethor . The sub-division of the Font Library development in stages helps to organize work efforts in smaller units. We must decide which stages should be fully completed for the 6.4 release. As you say, I agree that Stage 1 and 2 should be completed for the next release.

[matiasbenedetto]

The list is currently living here: https://s.w.org/images/fonts/16.7/collections/google-fonts-with-preview.json

[johnstonphilip]

even if this issue is grouped under the extensibility phase, it's still a strong requirement for the Font Library launch, which would become much less compelling with only manual upload.

A full Google Fonts integration should be a plugin. Otherwise, where do we draw the line with including brands in Wordpress core that provide a useful service? Including Google Fonts in WP core is a "vote of confidence" in Google's brand, and its free marketing too.