Is there a place within 360 that I can find a list of web-safe fonts to use, by which I mean those that will show consistently across all browsers? There are websites that will list them for those directly coding in HTML and CSS but they tend to vary in their recommendations.
Thank you! No, I'm not having any issues right now. I'm writing a review of the capabilities of the most popular authoring tools and just wanted to know if Articulate provided any guidance on which fonts to use. Thanks!
Just to be clear with my understanding: These fonts are installed with Articulate and are then also part of the published output(or linked to the corresponding CDN), so that there is no real need to worry about websafe fonts?
Yes, those fonts are installed so that you may author with them in your Articulate courses. You can also install other custom fonts and those should appear to users while they view your published output.
Some exceptions to this:
Text entry or variable references would need to use a font the user has installed or else it'll default to system fonts
Some LMSs or servers may need to have the configuration for the font type enabled, we included a fix for this in an earlier update of Storyline 360 but I have seen other users still running into it, and resolving it with their LMS/web admins
So, there are many facets to any "Web-Safe" font discussion. It is not a new discussion and there are definitely still issues. FWIW, here is the most significant one we have encountered:
When a browser is configured to not allow use of downloaded fonts, it instead falls back to some other font, often just the basic "system font" (which is also often a mono-spaced font). Note: what font is actually used could be controlled in the CSS and is the typical way websites attempt to deal with issues like this. However, I have noticed that Articulate does not use any fallback fonts in the CSS that is published. But, there is actually a bigger problem with what happens in published Articulate courses when downloaded fonts are disabled and that is related to what is called "ligature combinations".
The bigger issue is that many downloaded fonts will replace some character combinations (called ligatures) with reserved Unicode characters. A good example of this is with the Roboto, Futura, & Lato fonts (to name a few). Those particular fonts typically replace the following ligature character combinations with reserved Unicode characters. They are: 'fi' -> \uFB01, 'fl' -> \uFB02, 'ffi' -> \uFB03, & 'ffl' -> \uFB04. What then happens when a browser has downloaded fonts disabled and encounters these ligature replacements is that nothing will be displayed for those characters. So words like 'first', 'final', 'flow', 'office' become ' rst', ' nal', ' ow', 'o ce'. Also note, that typically the character kerning throughout will be off since the usual default "system" font will most likely have a different kerning.
I am not aware of any setting(s) in Articulate that would cause it not to replace those ligatures with the resulting reserved Unicode character. Perhaps I am just not looking in the right place, so please reply if you happen to know how to disable this ligature replacement behavior.
So, the net-net is that I would recommend trying to stay away from any downloaded font that replaces those ligatures with reserved Unicode characters, unless you feel you can convince your customers to: A) not use MSIE/Edge; and/or B) always have 'allow downloaded fonts' enabled in their security policy. That seems somewhat futile to me...
Also note this Articulate support article: https://articulate.com/support/article/Learners-See-the-Wrong-Font-or-Missing-Letters-in-Internet-Explorer#font-download-setting. The primary issue we have encountered being Item 2, and where customers are not willing or able to make the Articulate (and rest of the world) suggested changes to enable download fonts. Realize that our "customer" is typically an HR or training dept, and they have very little influence over an IT/Network Admin security policy - no matter how asinine it may be.
I am continuing to test different solutions/alternatives to how to handle this 2% scenario (that's about how often it is reported to us by our customers) and I will post an update here if/when I ever find a reasonable solution. (IMO, merely telling customers to change their security policy is not exactly the most viable - it typically results in them merely finding a different supplier/solution).
The release of accessible fonts fixes this issue , it is all probably academic as Articilate are dropping support for IE as it is now a legacy browser.
10 Replies
Hi Joseph,
We install a set of fonts with Articulate 360 as detailed here.
Are you having issues with fonts displaying in your published output? Could you tell us more about where you're hosting and viewing the courses?
This is a list of web safe fonts
https://websitesetup.org/web-safe-fonts-html-css/
Thank you! No, I'm not having any issues right now. I'm writing a review of the capabilities of the most popular authoring tools and just wanted to know if Articulate provided any guidance on which fonts to use. Thanks!
Ah, awesome Joe! Let me know if you need anything else. 😀
Just to be clear with my understanding:
These fonts are installed with Articulate and are then also part of the published output(or linked to the corresponding CDN), so that there is no real need to worry about websafe fonts?
Yes, those fonts are installed so that you may author with them in your Articulate courses. You can also install other custom fonts and those should appear to users while they view your published output.
Some exceptions to this:
So, there are many facets to any "Web-Safe" font discussion. It is not a new discussion and there are definitely still issues. FWIW, here is the most significant one we have encountered:
The primary problem we occasionally encounter is specifically with some versions/installations of MS IE/Edge browsers (typically in a government or large corporate environment where they stick to Microsoft supported software only). Basically, there are versions of MS IE and/or corporate configurations that disable the browser's use of any downloaded fonts. This means that any font that is not built-in to the browser/operating system will not be used on those browsers. This policy is due to security flaws that Microsoft had with MSIE (see https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2011/ms11-087?redirectedfrom=MSDN, and https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2015/ms15-044?redirectedfrom=MSDN, with a good summary written here: https://threatpost.com/of-truetype-font-vulnerabilities-and-the-windows-kernel/101263/).
When a browser is configured to not allow use of downloaded fonts, it instead falls back to some other font, often just the basic "system font" (which is also often a mono-spaced font). Note: what font is actually used could be controlled in the CSS and is the typical way websites attempt to deal with issues like this. However, I have noticed that Articulate does not use any fallback fonts in the CSS that is published. But, there is actually a bigger problem with what happens in published Articulate courses when downloaded fonts are disabled and that is related to what is called "ligature combinations".
The bigger issue is that many downloaded fonts will replace some character combinations (called ligatures) with reserved Unicode characters. A good example of this is with the Roboto, Futura, & Lato fonts (to name a few). Those particular fonts typically replace the following ligature character combinations with reserved Unicode characters. They are: 'fi' -> \uFB01, 'fl' -> \uFB02, 'ffi' -> \uFB03, & 'ffl' -> \uFB04. What then happens when a browser has downloaded fonts disabled and encounters these ligature replacements is that nothing will be displayed for those characters. So words like 'first', 'final', 'flow', 'office' become ' rst', ' nal', ' ow', 'o ce'. Also note, that typically the character kerning throughout will be off since the usual default "system" font will most likely have a different kerning.
I am not aware of any setting(s) in Articulate that would cause it not to replace those ligatures with the resulting reserved Unicode character. Perhaps I am just not looking in the right place, so please reply if you happen to know how to disable this ligature replacement behavior.
So, the net-net is that I would recommend trying to stay away from any downloaded font that replaces those ligatures with reserved Unicode characters, unless you feel you can convince your customers to: A) not use MSIE/Edge; and/or B) always have 'allow downloaded fonts' enabled in their security policy. That seems somewhat futile to me...
And here's yet another perspective on the whole ligature replacement issue: https://nedbatchelder.com/blog/201604/latos_unfortunate_ligatures.html
Also note this Articulate support article: https://articulate.com/support/article/Learners-See-the-Wrong-Font-or-Missing-Letters-in-Internet-Explorer#font-download-setting. The primary issue we have encountered being Item 2, and where customers are not willing or able to make the Articulate (and rest of the world) suggested changes to enable download fonts. Realize that our "customer" is typically an HR or training dept, and they have very little influence over an IT/Network Admin security policy - no matter how asinine it may be.
I am continuing to test different solutions/alternatives to how to handle this 2% scenario (that's about how often it is reported to us by our customers) and I will post an update here if/when I ever find a reasonable solution. (IMO, merely telling customers to change their security policy is not exactly the most viable - it typically results in them merely finding a different supplier/solution).
Hello, great info all!
Any updates?
The release of accessible fonts fixes this issue , it is all probably academic as Articilate are dropping support for IE as it is now a legacy browser.