Custom Fonts in HTML Emails

Fonts in HTML Emails – Limitations, Solutions and Industry Standards

Fonts in HTML emails are known for causing troubles. You may use whatever fonts you like on your website, but the rules for using fonts in HTML emails are a little different.

To guide you through the unknown, winding paths of the use of fonts in HTML emails, we have listed for you the most common problems you will face and the tools you will need to solve them.

Pros	Cons
System Fonts	The safest option.	Limited number of fonts.
Google Web Fonts	A library of over 600 fonts. Free for commercial use.	Not all email clients support these fonts, you have to have fallback fonts.
Self Hosted Fonts	You may use your own, copyright protected fonts.	Not all email clients support these fonts, you have to have fallback fonts. You have costs for purchasing the font, hosting and bandwidth.
Text In Image	You have creative freedom.	Images are usually blocked and need authorization to be displayed. The use of images slows down the loading time of the email.

1. System Fonts

What are System Fonts and why should I use them?

System fonts are those fonts that are already installed on your computer and all email clients have access to them and use them.

There are 10 system fonts that might be called `email safe`. That is because these 10 fonts are present by default on all PC and Mac computers.

The use of one of these 10 fonts will ensure that all your subscribers see your message displayed the same way.

It is hard to present your unique identity if you have just 10 fonts to choose from, so you may try using different font sizes and colors. This should add an extra flavor to your email.

2. Web Fonts & Google Web Fonts

What are Web Fonts?

Web Fonts are hosted on a server and downloaded by the email client while rendering your email and then applied to the text. Not all email clients display them, that is why it is important to use fallback fonts with them.

How does fallback fonts look in the code?

Here’s how you can use correctly custom fonts in your emails:

Lorem ipsum dolor sit amet 

Lorem ipsum dolor sit amet
 

You may wonder why the “Open Sans” font is placed at the end. Well, the tree bad guys – Outlook 2007, 2010 and 2013, as you may know, use Microsoft Office Rendering Engine to display the emails. Placing a custom font in the begining will make these clients to display Georgia instead. So the solution here is to place the font in the end.

With the following code, placed anywhere in the you overwrite the above code and show “Open Sans” instead.

The above will work on Thunderbird, Mac Mail, iOS, Windows Phone and any email client that support CSS3.

Here is the complete example:

         
 
Lorem ipsum dolor sit amet
 
 
   

Which email clients support web fonts?

The following email clients provide the best support of Web Fonts: Apple mail, iOS devices, Outlook 2000 and 2011, Thunderbird, Lotus Notes 8 and 8.5 and Android 2.3./4.2+.

Why Google Web Fonts?

There are several services that provide web user interface fonts for email, but we find Google Web Fonts to be the least complicated and they also come for free.

Google Web Fonts offer a wide variety of free fonts (over 1000) and an easy-to-use interface which helps to generate the font stylesheet for your email. You can use Google Web Fonts for both commercial and non-commercial purposes.

One of the best Google Web Fonts features is the option to download a desktop version of the fonts for use at the project design stage.

How does Google Web Fonts work?

The implementation of the Google Web Fonts is really quick and simple:

1. Follow this link https://www.google.com/fonts

2. Choose a font family from the list and click the Quick-Use button on the right hand side.

3. Pick up styles and a character set. Bear in mind that adding more styles in the code will affect the email template load time.

4. You have three options to add the code to your email template – Standard link, @import and Javascript. We prefer to use the Standard link. Here is an example:

5. Copy and paste the generated code into the of the email and the font will be accessible in your CSS code.

3. Self-Hosting Fonts

If you don’t want to use services like Google Web Fonts or if you own your fonts, you may host them on a server and use them in your emails.

Self-hosting also enables subsetting. It ensures that you stay in control of your font delivery and do not depend on third party servers.

However, self-hosting your fonts incurs some costs. While system and Google Web Fonts are free of charge, you will have to buy the fonts you are hosting with you. You have to also calculate the cost of hosting and bandwidth.

4. Displaying text as an image in email

Is this a smart choice?

Displaying text as an image gives you all the freedom you need when customising your text, however, you have to also consider the following:

• With most email clients images are blocked by default and the user have to authorize their display.
• The use of images may slow down the loading time of your email. The loading time increases with the number of images used.
• A text will always look better, no matter how good the quality of the images used in the email.

Conclusion

Having various email clients with different sets of rules on displaying fonts makes it a little harder to come up with a single, best solution. That is why we offer you several options to pick up from, depending on your wants and needs. But remember, whatever your option of choice, you have to have your html email template tested with a service like Litmus or Email On Acid to ensure that you know how your message is displayed on the various email clients and devices.

Need help with your next HTML email design? See how we design and code the email templates for our clients.

Further reading:

Источник

Using web fonts in HTML email or newsletters

The @import CSS embed code can be used to include custom web fonts in HTML email or newsletters.

JavaScript font loading is used for Adobe’s dynamic subsetting, which is required for East Asian web font serving. Since there isn’t a CSS embed code option, these web fonts–including those with Chinese, Japanese, and Korean language support–cannot be used in HTML email.

Choose fonts to use

Follow the web font tutorial to choose the fonts you want to use and create your project.

Add the embed code

To find the embed code for your project, visit the Web Projects page. Locate the project name, then click on the “@import link” option.

Add the tags with the @import embed code to the of the email, along with the font family names.

The font family name to use in the CSS to style your text is listed in the web project as well; read more about using fonts in CSS.

The @import embed code has to be at the beginning of the tag with any other @import statements or the fonts will not load. Only a @charset entry is allowed to be listed before the @import lines.

Email client support for web fonts

Some email clients do not support HTML email or web fonts in email, which will affect what your recipients see. Be sure to specify fallback fonts in your email and test your email before sending it, so that it performs well in all clients.

Here is a short list of popular email clients and their compatibility with web fonts.

Client Name

Источник

You Kinda Can Use Custom Fonts in HTML Emails

And you use them pretty much just like you’d use custom fonts on a website. Jaina Mistry had the scoop on this last year over on the Litmus blog:

• AOL Mail
• Native Android mail app (not Gmail app)
• Apple Mail
• iOS Mail
• Outlook 2000
• Outlook.com app

Aside from using a JavaScript font loader, which definitely won’t work in email (no email client will be executing JavaScript), ultimately it comes down to @font-face in CSS. So let’s do that.

Say we wanted to use Lato in an email, if we can. Go do the normal Google Fonts thing and find the URL for loading Lato. If you just visit that URL, you can see it’s loading Lato over @font-face, and you can totally snag that code:

In your HTML template, you’d put that into a block in the , as well as set the font-family :

Notice there are some fallback fonts set there. Might as well fall back to some Lato-like fonts, if we can.

Here we can see this working in the Litmus Builder:

But just to make sure, we’ll have to blast it to some actual email clients and see what happens:

I think the way to think about it is: some do, some don’t, meh, kind of a cool progressive enhancement to help match your brand.

Psst! Create a DigitalOcean account and get $200 in free credit for cloud-based hosting and services.

Comments

This is something I’ve been thinking about: email design. The designs we’re able to achieve on the web, are transitioning to the email. That would then lead me to believe that all said benefits might come w/ same known challenges. How to you account for #ux w/ email? What about latency? Do FOIT or FOUT come into play? What are the fall back rules w/ email engines? #inSearchOf

I think there is an error there. As written above, it shouldn’t work on Gmail on Android. In fact, the screenshot does not seem to depict lato. Check out the curvature of “r” or the shape of the “y”. That is the default Android system font.

Don’t forget: some older Outlook clients require you specify an alternative font in the @font-face block itself: @font-face <
.
mso-font-alt: Arial;
> Otherwise you will see good ol’ Times New Roman as a fallback font.

There’s also the option of backing up custom fonts with (or relying solely upon) modern system font stack: font-family: -apple-system, BlinkMacSystemFont, «Segoe UI», «Roboto», «Oxygen», «Ubuntu», «Cantarell», «Fira Sans», «Droid Sans», «Helvetica Neue», sans-serif;

A potential “gotcha” to look out for, is that some email service providers incorrectly count the loading of an @font-face font as a click or open. Best to test before using @font-face in your production emails.

a big gotcha to watch out for when doing these emails: if you’re not the designer of the email, and the designer will see the email once it’s sent, inform them about the fact a fallback font will get used if the email client doesn’t support custom fonts. You should also seriously avoid doing anything fancy with typography, don’t try overlapping text in some cool way, because once that fallback font kicks in your beautiful typographic work of art will look like garbage. percieved line-heights can change, spacing of letters can change, nearly everything about the font can be a bit off when it fallsback. Keep It Simple Stupid. Fortunately some of this you might be able to work around by using @supports in your CSS. a lot of email clients don’t support @Supports yet but if you’re familiar with @supports you know that lack of support for @supports just means you specify a fallback before the @supports.

Thanks for the shout-out Chris! Though I believe the screenshot for Gmail on Android shows a negative outcome—the web font Lato is not displayed. Still holding out for Gmail to enable web fonts on their apps.

One thing to note is Outlook’s greater than 2007 will revert to Times New Roman as it will not read the font stack properly. The best bet will be to put an important tag to the body tag that has web fonts and declare the fonts inline for each element. Or with the important tag in the body you can use a Outlook conditional statement for the fonts in the body.

Источник