Considerations When Choosing Fonts for a Multilingual Website

As a front-end developer working for global clients, I have been struggling with multilingual websites, especially the case of using both right-to-left (RTL) and left-to-right (LTR) typesetting. However, I have learned something along the way and will share some tips in this article.

Let's take Arabic and English as examples, not only because Arabic is my native language, but also because it is a classic RTL use case.

Add RTL support to your website

Before this, we need to add support for the RTL language to the website. We can do it in two ways, but neither of them are ideal.

Not ideal method one: use specific fonts for each direction

The first method is to rely on the dir attribute on any given element (usually element, so it sets orientation globally):

 /* For LTR, use Roboto */
[dir=ltr] body {
  font-family: "Roboto", sans-serif;
}

/* For RTL, use Amiri */
[dir=rtl] body {
  font-family: "Amiri", sans-serif;
}

PostCSS-RTL makes it easier to generate styles for each direction, but the problem with this approach is that you only use one font, which is not ideal if there are multiple languages ​​in a paragraph of text.

Here's why: You'll find that multilingual paragraphs mess up the UI because Arabic characters are given a default font that doesn't match the element.

In some browsers, the situation may be worse than others.

Undesirable Method Two: Use a single font that supports both languages

The second option is to use fonts that support both directions. However, in my personal experience, using one font for only two languages ​​limits creativity and the freedom to use different fonts in different directions. This may not be bad, depending on the design requirements. But I did work on some projects where this makes an impact.

So, what is the right way to do it?

We need an easier solution. According to MDN:

Font selection does not just stay on the first font on the list on the user system. Instead, font selection is done character by character, so if the available font does not have the glyph of the required characters, the following font is tried.

This means that we can still use font-family attribute, but use a fallback font if the first font has no character glyph. This actually solves the above two problems, killing two birds with one stone!

 body {
  font-family: 'Roboto', 'Amiri', 'Galada', sans-serif;
}

Why is this method effective?

Just as flexbox and CSS grid make CSS layout more flexible, font matching algorithms make it easier to handle content in different languages. W3C explains how it matches characters with fonts as follows:

When the text contains characters such as combination markers, ideally, the base characters should be rendered with the same font as the markers, which ensures the correct placement of the markers. For this reason, the font matching algorithm for clusters is more specialized than the general case of matching individual characters alone. For sequences containing variant selectors (indicating the exact glyph to use for a given character), the user agent always tries system font backing to find the appropriate glyph before using the default glyph for the base character.

(emphasis mine)

How do fonts match? The specification outlines the steps taken by the algorithm, which I will outline here.

• The browser looks at the text cluster and tries to match it with the list of fonts declared in CSS.
• It would be great if it found a font that supports all characters! This is the font used.
• If the browser cannot find a font that supports all characters, it rereads the font list to find a font that supports unmatched characters and applies it to those specific characters.
• If the browser can't find a font in the list that matches both all characters in the cluster and a single character, it uses the default system font and checks whether it supports all characters.
• If the default system font matches, the same is true, that would be great! This is the font used.
• If the system font doesn't work, that's where the browser renders the corrupted glyph.

Let's talk about performance

The sequence we just saw may affect the performance of the website. Imagine that the browser has to traverse each definition’s fallback, match specific characters to the glyph, and download the font file based on what it finds. This can accumulate a lot of work, not to mention FOUT and other rendering exceptions.

The goal is to let the font matching algorithm decide which font to apply to each text, rather than relying on one font to handle two languages ​​or adding additional CSS to handle different orientations. If the font is never applied to anything (for example, a specific page is RTL, and happens to be without any LTR text, and vice versa), the unused fonts in the stack are not downloaded.

To achieve this, you need to choose a suitable multilingual font. Suitable multilingual fonts are those that have as many character glyphs as you expect to use on the page. If you can't find a font that supports all characters, it's an effective way to use a font that supports most characters and then fall back to a font that supports other characters. It's equally good if it happens to be the default system font, as it lacks a font file to download.

The advantage of letting font-family attribute determine the font for each glyph (rather than creating an extra CSS selector for each direction) is that this behavior already exists, as we outlined earlier - we just need to take advantage of it.

The above is the detailed content of Considerations When Choosing Fonts for a Multilingual Website. For more information, please follow other related articles on the PHP Chinese website!