Just for my understanding: The tool allows to enter any font name, regardless if actually used by the template or not, and saves the files locally, but it doesn't influence which font is used by the template, right?

(https://wptavern.com/themes-team-releases-a-web-fonts-loader-likely-to-prohibit-hotlinking-any-off-site-assets)

but it doesn't influence which font is used by the template, right?

Yes and no. So this is just a field and if the client part reach the full functionality should have a JSON value stored in the DB. https://github.com/joomla/joomla-cms/pull/30914/files#diff-3001ea626c0063d81109c9aa32830d8cR110

So we can have an object like:

{
  "google": [
    "Roboto": {
      "sizes": [100, '100i', 300, 700, 800], // 100i == 100 italics
    }
  ]
}

Also as @brianteeman posted a simple API to handle this kind of info would be a 1 liner for template devs/ designers

@brianteeman basically solving the same problem... Nice to see that there's a greater movement in this direction

That's why I posted it ;) Saw it last night

I'm really in favor for local fonts for several reasons but a google font downloader in core really?!

Yes and no. So this is just a field and if the client part reach the full functionality should have a JSON value stored in the DB. https://github.com/joomla/joomla-cms/pull/30914/files#diff-3001ea626c0063d81109c9aa32830d8cR110

So we can have an object like:

{
  "google": [
    "Roboto": {
      "sizes": [100, '100i', 300, 700, 800], // 100i == 100 italics
    }
  ]
}

What is stored in the DB? All fonts which we ever localized? Or only the one which we localized last time? What happens if we once localized a font and then later decide not to use it anymore?

Well, the discussion which initiated this RFC PR was started in the repository of the Cassiopeia improvement, see the link in the description.

We have implemented there a very basic way to use local font files with the restriction not to add new dependencies to external 3rd party packages.

If this restriction is dropped for implementing what is proposed here, I am ok with it.

I just wanted to mention it so readers can understand why what we have in the Casssiopeia repository does not go that far.

What is stored in the DB? All fonts which we ever localized? Or only the one which we localized last time? What happens if we once localized a font and then later decide not to use it anymore?

Well, it needs some imagination here: think instead of the single input and button a different interface where you can add/remove edit each Font and the related sizes, italics, etc. More like the https://perfectgrid.io/demo (same principle also that client app is the front end of a single form field). Check the HTML and you will connect the missing dots

What happens if we once localized a font and then later decide not to use it anymore?

Well, this is an RFC and this is one of the things that needs a solution

I'm really in favor for local fonts for several reasons but a google font downloader in core really?!

Honestly I'm fine with it if it will make all joomla sites a click faster. But then again this doesn't have to be Google specific, it's just Google fonts are the most common provider and actually this is my response to Richard on the issue in the other repo. It's nowhere near production ready or even feature complete...

Well, this is an RFC and this is one of the things that needs a solution

@dgrammatiko Sure, and I did not want to block anything. An RFC doesn't have to be the final implementation. I just wanted to write down things which came into my mind, possible tasks or problems to handle, so it's not forgotten.

I'm really in favor for local fonts for several reasons but a google font downloader in core really?!

Honestly I'm fine with it if it will make all joomla sites a click faster. But then again this doesn't have to be Google specific, it's just Google fonts are the most common provider and actually this is my response to Richard on the issue in the other repo. It's nowhere near production ready or even feature complete...

I don't think we should make Cassiopeia or any shipped template a "framework" for templates,

We can't change the font now in backend right? so why should we allow to download any font? If people want to create a new template based on Cassiopeia then they should be able to download google fronts and add them to the template.

I'm against this pr, but I would really like to see an awesome documentation entry how to change Cassiopeia on docs. Including things like how to download google fonts to make your template faster. For example explain how https://google-webfonts-helper.herokuapp.com/ works and what's needed to move the font files (and which one) to the "new" template.

@HLeithner The webfonts helper is not a good example because either you use it like most people and npm packages do and combine the different character sets all into one font file and so have much bigger font files than when loading from google fonts, where they are divided into separate files for the different character sets, or you pack them separately with that tool but then have to manually combine the css files into one using the "unicode-range". See joomla/cassiopeia#129 for a detailed explanation. The way proposed in this PR here does it better and results in same font files as when using Google fonts from web.

ok then explain the way to do it with this tool but don't add a font downloader to a simple template which is in every joomla installation.

Maybe it could be decoupled from the template and become a "Font Manager" like we have a "Media Manager".

but I would really like to see an awesome documentation entry how to change Cassiopeia on docs

Let me bring few examples why this approach won't work on the Joomla context:

• The flagship site joomla.org has more than 5 secs of blank screen on a 3g connection (much of this as a result of using Goole Fonts). I would like to see how the maintainers of this site are failing to use your approach

• Joomla sites in the showcase suffer the sane exact problem. Here's a recent audit for all those sites: https://joomla-needed-fixes.netlify.app/data/ In sort 94% fail hard the RAIL

• Template authors won't invest in such tools so Joomla might have to provide it for them

Maybe it could be decoupled from the template and become a "Font Manager" like we have a "Media Manager".

It's a Form Field. Use it or not up to the template author as with all the rest Form fields. Same thing as the Hue selector Field in the Atum, the field is Global...

It's a Form Field. Use it or not up to the template author as with all the rest Form fields. Same thing as the Hue selector Field in the Atum, the field is Global...

Sure. But the process of maintaining the fonts could be de-coupled from this form field into an own UI, and the form field could just be populated with the available local fonts (or combinations of those? E.g. one may want to use font x for body and font y for headings.).

Maybe it could be decoupled from the template and become a "Font Manager" like we have a "Media Manager".

That idea is even worse.

It's a Form Field. Use it or not up to the template author as with all the rest Form fields. Same thing as the Hue selector Field in the Atum, the field is Global...

The font is part of the template creation, normally you change your template every day,week,month and your font is changed even less...

I don't see a good reason to bloat joomla more then it is already with functions that's used once in the lifetime of a joomla installation if you are lucky.

about j.org property, I'm pretty sure you can create a pull request to fix this problem.

I really like this idea. With the EU having file issues, yall know more about it then me, I can see how this would be extremely helpful. A LARGE majority of joomla users are affected by EU rules.
I can also see this being useful for those who don't use template devs. This function in one form or another is used similarly in every major template framework I know of. Only 99% of the time its not localised which this would do.
being its an extension it does ZERO harm to have it included in core.

being its an extension it does ZERO harm to have it included in core.

Actually that's not true.

• Someone have to maintain it, if google changes anything we have to adapt
• it introduce another punch of 3rd party extension which have to be maintained if they are compatible or introduce security issues

What about shipping some comon Google fonts with the template for the user to choose from and a docs page explaining how to download new fonts?

Like we do for codemirror and the tinymce templates stuff.

Would be an option but what does the license say ?

https://developers.google.com/fonts/faq

So it seems to be it is allowed to be downloaded? What kind of license do you mean? Are they special licenses for the fonts?

Would be an option but what does the license say ?

It's fine. D/l the particular fonts was my initial response to the issue, I also suggested a tool for that operation. Fwiw the front end code here is not that different than that tool, it's only GUI...

Edit: here's the proof from @jakearchibald and @surma https://youtu.be/TsTt7Tja30Q?t=922
Also a great resource on performance best practices

I think this PR has served its purpose. I've showcased how you can have a GUI interface for localising Google fonts. That was all there was supposed to be exposed here. The code could serve you as a base for any future implementations (pretty sure you will come back to this is couple of years, common patter with most of my proposals - they need their time)