Web

Suitable Web-Fonts

/ by Karsten Reincke | Leave a comment

Font Symbol Picture

Select­ing good fonts is a mat­ter of design, get­ting suit­able web-fonts a mat­ter of knowl­edge. Not only, if we need some for spe­cial cas­es. With bootScore we can incor­po­rate Google Fonts direct­ly. We are even told how to host them local­ly, so we can bypass the notice in the pri­va­cy pol­i­cy. Nev­er­the­less, we have to get a lit­tle involved with Boot­strap as well:

[ en | de ]

Solution

  • Choose from the Google Fonts:
    • a font with ser­ifs (e.g. pt-serif or noto-serif),
    • a match­ing sans-serif font (e.g. pt-sans or noto-sans),
    • a match­ing mono­space font (pt-mono or noto-sans-mono)
    • and maybe a spe­cial font for head­lines (e.g. ari­ma-madu­rai or eb-gara­mond)
  • Select each font after anoth­er in the google-web­fonts-helper and
    • leave the charset on latin * select — if avail­able
    • select — if avail­able — the sizes 400 and 700.
    • select — if avail­able — the styles reg­u­lar, reg­u­lar ital­ic, bold and bold ital­ic.
    • copy the font-face-code cre­at­ed in google-web­fonts-helper into the file scss/_bscore_custom.scss.
    • down­load the zip-pack­age from *google-web­fonts-helper
  • Cre­ate a fold­er fonts in your child theme.
  • Unzip all down­loaded zip pack­ages in the fold­er fonts.
  • Extend the file scss/_bscore_variables.scss with the lines:
  $font-family-base: 'Noto sans', Verdana, sans-serif !default;
  $font-family-sans-serif: 'Noto Sans', Verdana, sans-serif, !default;
  $font-family-monospace: 'Noto Sans Mono', 'Courier New', monospace, !default;
  $font-family-code: 'Noto Sans Mono', 'Courier New', monospace, !default;
  $headings-font-family: 'EB Garamond', Garamond, serif !default;
  $display-font-family: 'EB Garamond', Garamond, serif !default;

Background

Deal­ing with Fonts is — in terms of con­cept and con­tent — a wide field1:

In typog­ra­phy, it is com­mon to dis­tin­guish between serif fonts and sans-serif fonts. Serif fonts are bet­ter for print­ed run­ning text because their hor­i­zon­tal exten­sions on the let­ter lead the eye in a bet­ter way. On the oth­er hand, it was long thought that sans-serif fonts were more read­able on screens. How­ev­er, the fin­er the screens became over time, the fin­er the ser­ifs could be dis­played. The read­abil­i­ty increased, and the eyes tired less. Thus — today — it is said that there is no longer any real dif­fer­ence in leg­i­bil­i­ty: Serif fonts and sans-serif fonts can be used equal­ly.

Using only one font for all, how­ev­er, gets bor­ing. At least the head­ings and body text should dif­fer. On the oth­er hand, too many fonts reduce read­abil­i­ty due to the graph­i­cal unrest. And read­abil­i­ty and imme­di­ate per­cep­ti­bil­i­ty is the mea­sure of qual­i­ty. Thus, the mod­ern web design­er works with pairs, one font for the head­line, and one for the body text. This is why we are so often ‘rec­om­mend­ed’ font pairs today, where the fonts are quite wild­ly com­bined.

In this con­text, the dis­tinc­tion between font-fam­i­ly and font-face is also impor­tant. With the CSS state­ment font-family: XYZ; we tell the brows­er — impre­cise­ly speak­ing — that it should dis­play the text in an HTML tag with the font XYZ. In fact, how­ev­er, we are telling it to dis­play the text with a suit­able font from the font fam­i­ly XYZ. With the CSS state­ment @font-face {...}2, we have pre­vi­ous­ly told it that a cer­tain well-designed font from a cer­tain font fam­i­ly (font-family: XYZ) with a cer­tain style (font-style: [normal|italic]) and a cer­tain weight (font-weight: [<400<...<700<]) is avail­able and where to find it. It is then up to the brows­er to pick the most suit­able font out of the group font-fam­i­ly XYZ for a par­tic­u­lar place in the HTML source code. After all, it must not only dis­play the font itself but also take into account the spec­i­fi­ca­tions ‘nor­mal, ital­ic, bold, bold-ital­ic’.3

If a spec­i­fied font is not avail­able — for exam­ple, because the brows­er could not down­load or under­stand it — then the brows­er choos­es anoth­er ‘sans-serif’ resp. ‘serif’ font from those that are acces­si­ble. If a font of a font fam­i­ly does not exact­ly fit the oth­er required prop­er­ties, the brows­er can ‘pro­duce’ them by tilt­ing or ampli­fy­ing a font com­pu­ta­tion­al­ly. How­ev­er, such ‘cal­cu­lat­ed’ fonts look worse than those explic­it­ly designed that way.4.

So, in prin­ci­ple, the web design­er can­not be sure how her text will actu­al­ly look on a read­er’s com­put­er. To increase the like­li­hood that the design­er will be able to pro­vide her read­er with what she intends, the CSS state­ment font-family: XYZ; may com­bine sev­er­al font fam­i­lies — up to the gener­ic serif, sans-serif, or monospace fam­i­ly. The brows­er assures — for each let­ter — to take the first font from that fam­i­ly, with which it can dis­play the let­ter as request­ed. Whether and how well this works also depends on the type and qual­i­ty of the brows­er. To offer the design­er even more cer­tain­ty, the con­cept of Web Safe Fonts has emerged5: Fonts from that she knows that they are (most­ly) avail­able on the devices. From these fonts, she can choose a sub­sti­tute that does not meet her design ideas opti­mal­ly, but still well.

With respect to our con­text bootScore and Boot­strap, this cre­ates a strat­e­gy for inte­grat­ing Google fonts local­ly6:

We choose our pre­ferred font pair and use — as rec­om­mend­ed by bootScore — the google-web­fonts-helper to down­load the cor­re­spond­ing Google fonts and insert the also gen­er­at­ed @font-face instruc­tions into file scss/_bscore_custom.scss.

In the file scss/_bscore_variables.scss we then apply the Boot­strap method­ol­o­gy to decide for which HTML ele­ments the fonts should be used:

With Boot­strap, we spec­i­fy the ‘main font’ via the vari­able $font-family-base. This can be the fam­i­ly of a serif font or a sans-serif font. Via the vari­able, $font-family-sans-serif we spec­i­fy the main sans-serif font. There is no vari­able $font-family-serif. If we want to use a dif­fer­ent fam­i­ly for the head­ings than the gen­er­al main font, the vari­ables $headings-font-family and $display-font-family would be respon­si­ble for this. Using this way, we eas­i­ly can com­bine all com­bi­na­tions.

And how does this …

… sup­port our migra­tion to bootScore? Well, when the web design­er has com­plet­ed her work on good illus­tra­tions, she can relax and inte­grate tags and clouds into her site, improve her overview page and design her own land­ing page. Whether the result­ing full­ness real­ly ben­e­fits her own read­er, whether it can become slim­mer and how, whether more dis­creet ref­er­ences and spe­cif­ic fonts also increase the read­abil­i­ty, all this she should nev­er­the­less con­sid­er while imple­ment­ing these fea­tures. This post sup­ports these steps towards a per­son­al­ized bootScore site.

  1. cf. https://kinsta.com/de/blog/html-fonts/ [↩]
  2. cf. https://www.w3schools.com/cssref/css3_pr_font-face_rule.php [↩]
  3. cf. https://technicalcommunicationcenter.com/2020/06/10/whats-a-font-font-family-typeface-font-face/ [↩]
  4. There­fore it is impor­tant to pro­vide the desired font fam­i­ly at least in the weights ‘400’ and ‘700’ and respec­tive­ly in the types ‘reg­u­lar’ and ‘ital­ic’ [↩]
  5. cf. https://www.w3schools.com/cssref/css_websafe_fonts.php [↩]
  6. The alter­na­tive would be to load the fonts direct­ly from Google font servers on a case-by-case basis. That makes your work eas­i­er. And com­pli­cates your pri­va­cy con­cept: Because when down­load­ing, Google asks for user data, i.e. your read­er’s data. The cause for that is your site. There­fore you have to point this out in your data pro­tec­tion con­cept. So it’s bet­ter if you down­load the fonts your­self, inte­grate them into your site, and deliv­er them your­self. [↩]
To top