Yes the potential for dubious jokes is going to be very high with a topic on fonts.
Yet this is not a light subject and it is not a laughing matter for email designers. Managing typography in newsletters regularly puts integrators in a bad mood.
Do we have to use force with the police? This is a real problem of "fonts"! OK I stop, let's concentrate a little.
System fonts
These are the ones installed and available on the terminal (computer or mobile).
In our case, the important thing is to position ourselves on the user's side: the person who will consult the emails. The fonts present on his terminal are not necessarily the same as those present on the machine that created the email (the designer's and/or integrator's).
There is a strong dependency on the operating system (hence the name "system policy"). If we are on an Apple or Windows OS we will not have the same fonts by default. This is especially related to intellectual property, copyright and licenses.
An example of this difference: a user with an Apple device will have very good support for Helveticaon Windows this will not be the case. The most visually similar font (this will make many designers cry) will be Arial. Font that is none other than a clone ordered by Microsoft.
It's not an easy story.
Police statement
The previous example allows us to understand the usefulness of defining several fonts for the same content. This is called font stacking.
For a given element (a title for example), we define an ordered set of fonts that have a similar design.
Depending on the user's environment, he will be displayed with the corresponding font. The font stack is often defined by font type (sans serif, serif, cursive, monospace,...) but other criteria can come into play.
By now you should understand that we need to start stretching and relaxing. Yes, our emails are going to look slightly different depending on the context of our users.
Need help?
Reading content isn't everything. The best way is to talk to us.
Security and control first with a web-safe font stack
The joint use of system fonts and stack fonts makes it possible to define so-called "web-safe" sets. That is to say that it will be supported in most of the web uses (including email).
For my title, if I want a sans serif font, then I will be able to list in order of preference the fonts :
font-family: "Roboto", "Calibri", Helvetica, Arial, Sans-serif;If I am on Windows and I have installed Robotothen I will have the Roboto displayed for my titles in the email. If Roboto is not installed, it will be Calibri and if I have an old version of Windows, then it will be Arial. For an Apple user it will be Helvetica and for people on a Linux distribution it will be Sans-serif.
- Advantage : we guarantee the result displayed to the user.
- Disadvantage The choice is limited because it depends on the user environment.
Embed Web font
How can I use the font of my graphic charter with such a limited choice?
There are technical solutions to integrate custom fonts. That is to say, fonts that are not present on the user's computer and display them in rendered form in emails. This requires calling in the HTML and CSS code of your email to a hosted resource that corresponds to the font of your choice.
However, there are three main limitations to this:
- You must be sure to have the license (copyright) and to be able to distribute it. It will be your responsibility to host it on a server to make it available. If your font is available on Google fonts or other similar service, it will relieve you of the responsibility. But read the licenses carefully anyway because yes they are specified on Google fonts and Open Source does not mean free or unattributed.
- Not all email clients will support these techniques (hello Outlook). So you have to plan a fallback (a fallback solution which will mean choosing a system font as a substitute in your font-stack).
- Corollary of the previous point. IThe substitute font must have a design close to that of of the original font to avoid generating a too unsightly degradation (size, fat, kerning...). Here are two examples of fonts that do not substitute well: Smooch Sans and Open Sans
It is necessary to know the environment in which your base is open before implementing such a solution. And above all be aware that it won't work for 100% of cases (only 36.36%) and therefore once again be very flexible regarding the rendering of your emails (continue your morning stretches).
Yeah, but who is LePatron in the case of an email creation tool?
Is it possible to the email builder of Badsender (aka LePatron) can integrate different fonts in the templates. Of course you can!
As you know, our motto is to make custom-made. To adapt to your needs in order to have a template that guarantees the integrity of your graphic charter.
On the other hand, having a list of a dozen different fonts available in an email builder that advocates a design system approach seems to me to be a bad idea. Especially if the template is to be used by many different people. The emails produced will look different from one user to another depending on the font choices that are made. This is the opposite of aindustrialization of its email production and the consistency of a design system.
Now if that's really what you want, it's still doable. It's just not advisable from a brand identity perspective 😉
Conclusion
Making emails is not as simple as it seems. You have to take into account a multitude of usage contexts. This applies to responsive and background-image as for custom fonts. There is always a solution, but none that can guarantee a 100% rendering applicable to all email clients. If you are a control freak or pixel perfect, you will have to learn to let go.
