I am using Google Font Libre Caslon Text for the body of our email and a fall-back font of Times New Roman. The results are weird.

When I use this inline style font-family: 'Libre Caslon Text','Times New Roman',serif; Neither font works in Outlook 2019.

However, if I use this inline style font-family: 'Libre Caslon','Times New Roman',serif; Times New Roman Works in Outlook 2019.

What am I missing?

CodePudding user response：

Outlook 2019 (as all Outlook on Windows since Outlook 2007) uses Word’s rendering engine. Word does not support web fonts embeds. But it kind of does. So any @font-face declaration will still be interpreted by Outlook, but the font files won't be downloaded and applied. To get a better control of the fallback font used, you can use one of the two following properties in your @font-face declaration:

• mso-font-alt: lets you declare the name of a single fallback font. For example: mso-font-alt: "Times New Roman";.
• mso-generic-font-family: lets you declare a font family among the following values: decorative, modern, roman (akin to serif), script, swiss (akin to sans-serif) or auto (defined to roman by default up to Outlook 2016, then changed to swiss since Outlook 2019).

In your case, you'd need to declare your font like so:

 @font-face {
   font-family: 'Libre Caslon Text';
   font-style: normal;
   font-weight: 400;
   src: url('https://example.com/Libre-Caslon-Text.woff2') format('woff2');
   mso-generic-font-family: roman;
   mso-font-alt: 'Times New Roman';
 }

Here’s an article I wrote about this two years ago: Today I learned about mso-generic-font-family…

CodePudding user response：

I'm not 100% sure why Times New Roman (TNR) isn't loading for scenario 1 as normally you shouldn't wrap web friendly fonts in apostrophes but that doesn't seem to be the deciding factor here. Also, your method of fall back for web fonts isn't quite complete for Outlook.

Unfortunately Outlook doesn't follow the front-end & email industry standards to fall back to the next possible font declared. Instead when a web or non-web friendly font is encountered, Outlook will simply break the font declaration and apply TNR. Now I would agree that this doesn't make sense since your scenario 1 doesn't follow this condition, but I think there may be something going awry with the declarations, TNR being wrapped in apostrophes or Outlook is confused by your web font naming.

Anyhow, the final piece of defining a fall back for Outlook clients on Windows machines is:

<!--[if mso]>
    <style type="text/css">
    h1,h2,h3,h4,h5,h6,p,a,span,td,strong,li {
        font-family:Times New Roman,serif !important;
    }
    </style>
<![endif]-->

<iframe name="sif1" sandbox="allow-forms allow-modals allow-scripts" frameborder="0"></iframe>

You can tailor the element labels to your specific use case or just use a broad set of selections like I use above.

Add this in and give both scenarios another test run and let us know how it goes.