Roboto Fonts

[brianteeman]

1. Is it really necessary to load both the regular and the bold versions of the font when loading the local version. We dont do that when we load the google version.

2. The local version is massively bigger
   Font size from google 15.8kb
   Font size from local 130kb (65 +65)

[richard67]

The size of the local font is bigger because it contains more character sets than Latin, while those loaded from Google Fonts are separate files for character sets (in the css: Unicode ranges).

[brianteeman]

and the reason for loading regular and bold ?

[richard67]

You mean in the css file media/vendor/roboto-fontface/scss/roboto/roboto-fontface.css? That's a vendor file, not maintained by us.

[brianteeman]

when loading from google

when loading local

google version

[richard67]

@brianteeman Not sure if I understand right: The first screenshot shows what is loaded when using font scheme "Roboto + Noto Sans (web)", and the 2nd one shows what is loaded when using font scheme "Roboto (local)"?

[brianteeman]

Yes that is correct.

In the first screenshot only one roboto font file is loaded
In the second screenshot there are two roboto font files loaded

[richard67]

The "Roboto + Noto Sans (web)" uses "Roboto" for the headings and "Noto Sans" for "normal" text (body, ...).

The "Roboto (local)" uses that font for both headings and "Normal" text. Headings are bold, normal text not.

Does that explain it? Let me know if not.

Beside this: I know the local fonts implementation could if not even should be improved.

But we were limited by the following:

1. We shall not add a new 3rd party dependency.
2. When we started with developing the local fonts, we wanted to establish a way how to manually maintain them in our source code, open for later adding of more fonts by the site admin. But we were accused to pollute the installation and sources in this way with too much stuff (or to use Joomla as a trash can or something like that), so we decided to start with what we have and see if we later can extend that.
3. Due to the way how most if not all npm packages which offer local Google Fonts work - they all seem to use https://google-webfonts-helper.herokuapp.com/fonts, the font files are bigger because they combine the different character set into a font file and the css looks like media/vendor/roboto-fontface/scss/roboto/roboto-fontface.css, in opposite what you can see e.g. when checking the content of https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap, where smaller font files are used for particular unicode-range.

We decided to use what we have and later see if it is possible to improve that.

But if you have ideas, or if you see we load more font weights than necessary, let us know.

Thansk for your reviews and tests so far.

[brianteeman]

Ok I think I understand you now. I am really not impressed with this local font thing. Especially as its the default. Its addressing an issue which only one country seems to have and is impacting the performance for everyone. If a user really wants to not use google fonts then that should be their choice and not something forced upon them. There are even options for privacy focussed google web fonts such as https://fontless.varld.co/

[richard67]

@brianteeman And I pretty much understand your concerns and points. We can collect more opinions and easily change the default if that's desired.

We decided to use it as default because of that privacy issue of which I think it won't be an issue anway in near future because either US and EU agree a new kind of safe harbour or privacy shield or however they call it, or they have to make an intranet in EU to replace internet and cut all cables betwen the EU and the rest of the world ;-)

[richard67]

I think whatever we will do will be wrong: If we make web fonts the default, people in EU will complain it is not safe regarding GDPR, and if we make local fonts the default, people outside EU will complain about performance issue and too big font file, and in both cases we can write the best documentation and add hints about that to every release announcement, but people very likely won't read that.

[richard67]

Regarding https://fontless.varld.co/: I could read in their readme on GitHub that they also use google-webfonts-helper, so it's very likely that they don't use separate different particular charactersets and the unicode-range but combine all available character sets into one font file. So the "bigger file problem" would also exist here.

[brianteeman]

yes but they dont do any tracking and its self hosted - that was the point

[richard67]

Yes, that's true, and they offer so send it to a CND so no performance issue on the server.

The good thing is: With our font schemes one can use any font from web, not only Google fonts.

It just needs to specify the right URL in the SCSS for the font scheme. So one could use https://fontless.varld.co/ from the Vercel where they send the fonts and css to, or one could pack own fonts (and that can be done in a way so the character sets can be separated into separate smaller files) and copy that to the CDN of his or her choice.

Now in the core it is hard-coded in the template's index.php, so one would have to make a template copy just for changing that.

It is worth a discussion if we could add a web based font scheme using that, in addition or as replacement for the Google Fonts (but again, this would mean larger font file). But in this case we either should make a 3rd group for fronts from web but being safe, beside the local and web groups in the grouped list field, or we have to change that yellow warning box telling about privacy issue with web fonts.

[richard67]

Hmm, thinking over it, for adding a new font scheme one has to add it to the templateDetails.xml, and if that shall be safe from being overwritten by a core update, one would have to copy the template, too. So not a big difference, I admit.

[dgrammatiko]

FWIW there are tools (npm) that will download a google version of any font (with all the optimisations) So you get all the things for free (perf, small size, any G-font).

[richard67]

@dgrammatiko Not small size, read my comments above, those tools almost all, if not all, use google-webfonts-helper. you can keep size small by using only latin character set, but the npm packages i found combine the character sets all together and so the files are much bigger than those from google.

[richard67]

@dgrammatiko P.S. and we were limited to not add a new dependency, so we had to use what is already there, and that has the big file with all character sets.

[dgrammatiko]

@richard67 there is no dependency or whatever, just do an npx google-font-downloader https://fonts.googleapis.com/css?family=Roboto:400,400i,700,700i; (npx will run a node module without installing it)

https://www.npmjs.com/package/google-font-downloader

[richard67]

yes and it downloads the fonts and a css.

and where to store it? we had started with that in the build/media_source/fonts folder but were blamed to pollute Joomla with that.

[dgrammatiko]

and where to store it?

In the template that is using this font, casiopeedia

[richard67]

@dgrammatiko That's what we had at the beginning. Then we were blamed here #18 (comment).

Maybe the CMS shouldn't be used as garbage bin.

Then we decided to change to a solution with minimum impact on what we have now in the core regarding additional files or folder and additonal dependencies.

Maybe it is not optimal yet, maybe far away from it.

But we did not want to risk acceptance for the template works in general by that.

We still extend it later and make it better.

[richard67]

@dgrammatiko The tool you've linked seems to do it right with the character sets, divide them into smaller files like google does. So that could be indeed better that the google-webfonts-helper. I will discuss that in the team. It could be at least an option for future improvement.

[dgrammatiko]

@richard67 basically you can create a new field, and with some js magic you can allow users to d/l any google font. No tracking, no 2 more DNS resolves. Big gains for everyone. Don't think small here (eg solving the problem for roboto and 1 template, solve it for everyone 😉)

[richard67]

@dgrammatiko And how should it be for a new installation initially? shall we already provide some of these fonts with the installation in the template's folder structure somewhere? or only have that field so backend user can use it in template style settings to add some fonts plus the css but we don't ship some with the core?

[richard67]

@dgrammatiko Technically I understand what you mean and I already investigated about that. For js details I for sure would need help. But mainly it is a question of what shall we ship with the core.

[dgrammatiko]

I'm guessing you should respect the designers opinion here and provide roboto as the default.

[dgrammatiko]

But mainly it is a question of what shall we ship with the core

Ship anything that helps a11y, perf and users workflow

[richard67]

@dgrammatiko Well the original design of Cassiopeia was with "Fira Sans". We only have chosen Roboto for the local fonts because that was already there for the backend, and for the web fonts we decided to have an additonal option with better character set support than Fira Sans, and so we came to the combination "Roboto fore the headings and Noto Sans for the text from Googlefonts". If you want, checkout our development branch here and check the options in the template style settings. These 3 we have, "Roboto (local)", "Roboto + Noto Sans (web)" and "Fira Sans (web)".

[brianteeman]

Thank you @dgrammatiko #129 (comment)

[richard67]

1. Is it really necessary to load both the regular and the bold versions of the font when loading the local version. We dont do that when we load the google version.

2. The local version is massively bigger
   Font size from google 15.8kb
   Font size from local 130kb (65 +65)

@brianteeman I think the 1st issue has been answered. The reasons for the 2nd issue have also been explained.

Regarding the 2nd issue I agree that (especially on older servers not supporting http/2 yet) it might be a page speed issue to load the bigger font file(s). This might be ok for the backend but not for the frontend.

I also agree with @dgrammatiko 's ideas for having a user friendly interface to manage local fonts in a better way.

We've discussed that in the Cassiopeia team, and we agree that we don't have the resources and the time to develop that.

E.g. I personally lack especially the javascript skills.

As a first step to solve the page speed issue we decided to change the default value for the font scheme to "None", which is safe regarding privacy AND page speed. When doing this I found a mistake with font family and weight not being correctly set when the font scheme is set to "None". See PR #166 for solving both. With this PR, the font-family will be set to the bootstrap values.

As the 2nd step we think about removing the "Roboto (local)" and the "Roboto + Noto Sans (web)" font schemes, so only "None" and "Fira Sans (web)" remain, and change the "Font Scheme" list field back to a "Use Google Fonts" toggle, so that at the end it works the same way as the Google Fonts toggle in J3 in Protostar, with the difference that in J4 it will be switched off by default.

This would still be an improvement to what we have now in the CMS repo, use "Fira Sans" from web without the possibility to switch that off.

We still can later improve that in the CMS when the work in this repository has been finished, and this should happen soon, and we don't want to delay that by developing additional features for handling local fonts.

@brianteeman @dgrammatiko Would that 2nd step be ok for you?

[dgrammatiko]

@richard67 let me try some js magic: https://github.com/joomla/joomla-cms/compare/4.0-dev...dgrammatiko:4.0-dev-google-fonts-for-all?expand=1

[richard67]

@dgrammatiko Sure I let you try.

As I can see you are doing it based on the 4.0-dev branch of the CMS. If you want us to do it here with the Cassiopeia enhancements, you'd have to change that so it is for the development branch of this repo here. But I think it could be better to do it in the CMS repo, not here, so these 2 little projects don't depend on each other. What would be better for you? Do it in this repo here or in the CMS repo?