I've had two different clients share snapshots that show the lower case "f" is not showing up in Menus, notes, and others for a course published in HTML5. Both clients were using IE 11.
Jump to the last page for the causes of this issue. The upshot is that to avoid this you either need to change a security setting in IE or be more conservative in font selection.
Just ran into this myself earlier this week. Browser security policy locked down. Ended up switching the publish to Flash/HTML5 until we can get the LMS whitelisted.
It's an issue with IE11 trust policy set to medium high for internet sites. If set to medium for specific sites (the LMS), to whitelist the content host, then it shouldn't display the issue. Intranet is set to medium for us.
The problem is the WOFF files (web fonts) are being blocked by IE with that protected mode on and medium-high setting. The client might not be opposed to pushing out an update that whitelists their own LMS.
The alternate is finding fonts that don't cause the issue. Verdana, Arial, even Calibri or other fonts commonly found on a user's machine should resolve the issue. Don't forget to set these in the player as well.
It might be a coincidental intersection with server settings as well. If the server isn't configured to properly identify a media type, the browser might be set to go "no way, that's not what you say it is" and refuse to serve the request.
I'm a big advocate of Articulate products and support, but the BIG question for me is: why can't I find this issue being discussed by Lectora and Captivate users?
I get the server-side security issues, so one would assume the output of those development tools would result in the same problem. A Google search did not show those communities identifying the issue. Strange...
Likely all the tools render text a bit different and that could contribute to the display. We have a number of steps documented here for the missing letters, and our team is still looking into the specifics of this with Internet Explorer.
Likely all the tools render text a bit different and that could contribute to the display. We have a number of steps documented here for the missing letters, and our team is still looking into the specifics of this with Internet Explorer.
With respect, informing our customers that they must implement a company-wide update to IE 11 on all workstations is not a solution. Can't pass the buck that way.
Is this an issue that will remain open in 2018 or are there plans to resolve it in an upcoming release?
I agree with Sam. The other development tools have been able to overcome this issue and it's unacceptable that Articulate has been unable to solve it. Organizations have policies in place for a reason and given that other developers have figured out a solution means Articulate should be able to as well.
Placing the onus on ISDs to try to get a large organization to change its server settings rather than simply applying a fix is troublesome.
You're right, Sam. We take full ownership of this issue, and we know asking customers to implement a company-wide update to IE11 is extremely inconvenient and cumbersome. With that in mind, I want to stress again we don't take this issue lightly.
Our team is hard at work on a fix, and are treating it as a priority. Right now the timeline for this fix is a moving target – as the team will be continuously testing and sharing those findings with some beta users prior to a full release to confirm it's a viable solution for everyone.
Thanks for adding your voice, Rob. I can definitely understand where you're coming from as well. This post will bring you to a response from Mike, our SVP of Engineering at Articulate – you'll see that this issue reached the right people, and we're working very hard to fix it. Please know we're here in the meantime.
On one hand, this isn't completely unique to Articulate's tools. This is a fairly common problem with a relatively easy solution. There is no reason for a browser to restrict web font downloads. It breaks an awful lot of sites on the modern web. The ligatures issue is uniquely annoying since it renders the output nearly useless.
On the other hand, I suspect there's a Javascript solution that should work to detect if a font used in the story published output is available and, if not, substitute a default. The failure is not at all graceful. It should be. Maybe adding something like the item below would help to resolve the issue?
We've experienced this problem as we work to deploy content and, while it's annoying, the short term fix ended up being using a font that appears on every desktop (Arial, Verdana) in the authoring environment. Would be nice not to have to do this but part of development workflows is contending with browser quirks. This isn't the first or the last we'll deal with:)
Our long term fix is working with our IT configuration folks to get the change into the configuration. It's amazingly easy to push a policy update and propagate across the organization. A change request is not that easy but isn't impossible. This is squarely an issue of someone choosing to lock down a feature in the security configuration that is extremely low risk. Once brought to their attention and the request was made, it wasn't a problem. Couple of options. One is adding the LMS to the trusted zone. The other is changing the setting for the web fonts download for all sites.
It may be easier to persuade IT to change browser configurations when the eLearning is developed within the company. It is a different matter when a 3rd party is delivering eLearning to a large corporation.
I did a quick google of "eLearning font ligature" and "online learning font ligature" and the only place anything comes up problem-wise is Articulate. The remaining links seem to be instructional.
This doesn't mean other eLearning authoring packages aren't having the same issue, but it suggests it may be more of a problem here.
Ligatures, yes. That seems unique to Articulate outputs. Font issues pop up everywhere. Most notably is where fonts contain icons. I think it's more of an issue with SL because ligatures are used to help bring parity between the authoring environment and the output. Sounds like Articulate is making progress on a fix.
It's not unreasonable to ask a company to whitelist their own LMS. It's possible that nobody had asked for it:) IT folks aren't very good at reading minds... yet.
Thanks for offering your insights. I had the pleasure to work with you many years ago on a Marine Corps eLearning project (Heavy MachineGun), and I purchased a book you contributed to about developing Storyline. I have the greatest respect for your abilities.
That said, I've found no indications that competing eLearning development tools have negatively impacted learners with "missing letters" in their output. Looking at this thread, and related ones, this appears to have been an issue at least a year.
How is it possible that developers are still pointed to an article that advises them to have IT make a change to their server settings instead of applying a fix that empowers developers?
Yes, we all understand the need to develop to target browsers, and the challenges of catering to them all, but a known issue with IE11 that clearly impacts large organizations with many developers and big audiences?
Ashley indicated this problem is a priority. On behalf of the USMC, I hope it's priority ONE.
I just piloted tested and I have users complaining of the same thing. Has this been resolved? We are not using an LMS, they piloted the course using the Articulate Review link. We will be uploading the course on their website. Do I need to add a message about which browser would be better to use, but what happens if they are at work and don't have the option to pick a different browser? I'm just trying to figure out the best remedy, I'm a little embarrassed as I've spoken so highly about using Storyline for them and we have this issue. What is the fix?
This is an issue with web fonts in IE. You'll only see the problem in IE where the security configuration is set to block WOFF files. Couple of solutions, one is on your end, other is on the client's end:
Your end) Change fonts in the story to those you're sure will appear on all workstations and won't require a download (Arial, Verdana, Calibri, Georgia, etc..)
The client's end) Change the security settings in IE to allow WOFF files or add the launching site to the trusted sites through a global policy in the organization.
I'd tend toward doing each of these. I think the Articulate team is looking into a way to get around this and more gracefully degrade. I ran into this as well. It only appeared in IE for us. We tracked it down to a security setting (web font download).
Thank you for the quick response. I am using Calibri for my font. Were you stating that (Arial, Verdana, Calibri, Georgia) are fonts I should avoid or these the fonts that don't require a download?
I have an additional question if you don't mind, the client is the source for housing the content and will do so on a website, but people all over the state will be accessing the site from their own workspaces/organizations. Is this something that each user will need to do or just the settings on the website the client is going to point the trainings too? I will share this information with them. Thank you again
Hi, Rob. Really appreciate you continuing to add your voice, and I'm so sorry for the headaches this is causing you and your team.
While I don't have an ETA to share at this time, we'll certainly post all updates here once we have them – so you're in the right place! It's a complex issue – one that's at the top of the priority list to tackle.
Thanks again for your candid feedback. If there's anything else we can clarify or help with in the meantime, let us know! We, and our Support Engineers, are all standing by.
31 Replies
There is a long thread on this here actually:
https://community.articulate.com/discussions/articulate-storyline/letters-t-and-f-going-missing-in-storyline-360-for-small-population-of-users
Jump to the last page for the causes of this issue. The upshot is that to avoid this you either need to change a security setting in IE or be more conservative in font selection.
Just ran into this myself earlier this week. Browser security policy locked down. Ended up switching the publish to Flash/HTML5 until we can get the LMS whitelisted.
Try telling a client with 15,000 employees to revise their browser security policy. Oh wait. They can't.
Has a root cause been identified? (I have three clients that do not allow flash on employee desktops so Flash/HTML5 is not an option)
It's an issue with IE11 trust policy set to medium high for internet sites. If set to medium for specific sites (the LMS), to whitelist the content host, then it shouldn't display the issue. Intranet is set to medium for us.
The problem is the WOFF files (web fonts) are being blocked by IE with that protected mode on and medium-high setting. The client might not be opposed to pushing out an update that whitelists their own LMS.
The alternate is finding fonts that don't cause the issue. Verdana, Arial, even Calibri or other fonts commonly found on a user's machine should resolve the issue. Don't forget to set these in the player as well.
Steve, is there a security vulnerability around using woff font files? I'm just wondering why this security restriction exists.
Shouldn't be. WOFFs are pretty straight forward.
It might be a coincidental intersection with server settings as well. If the server isn't configured to properly identify a media type, the browser might be set to go "no way, that's not what you say it is" and refuse to serve the request.
Ah yes, anything not strictly allowed is forbidden.
I'm a big advocate of Articulate products and support, but the BIG question for me is: why can't I find this issue being discussed by Lectora and Captivate users?
I get the server-side security issues, so one would assume the output of those development tools would result in the same problem. A Google search did not show those communities identifying the issue. Strange...
Hi Rob,
Likely all the tools render text a bit different and that could contribute to the display. We have a number of steps documented here for the missing letters, and our team is still looking into the specifics of this with Internet Explorer.
With respect, informing our customers that they must implement a company-wide update to IE 11 on all workstations is not a solution. Can't pass the buck that way.
Is this an issue that will remain open in 2018 or are there plans to resolve it in an upcoming release?
Sam
I agree with Sam. The other development tools have been able to overcome this issue and it's unacceptable that Articulate has been unable to solve it. Organizations have policies in place for a reason and given that other developers have figured out a solution means Articulate should be able to as well.
Placing the onus on ISDs to try to get a large organization to change its server settings rather than simply applying a fix is troublesome.
You're right, Sam. We take full ownership of this issue, and we know asking customers to implement a company-wide update to IE11 is extremely inconvenient and cumbersome. With that in mind, I want to stress again we don't take this issue lightly.
Our team is hard at work on a fix, and are treating it as a priority. Right now the timeline for this fix is a moving target – as the team will be continuously testing and sharing those findings with some beta users prior to a full release to confirm it's a viable solution for everyone.
Thanks for adding your voice, Rob. I can definitely understand where you're coming from as well. This post will bring you to a response from Mike, our SVP of Engineering at Articulate – you'll see that this issue reached the right people, and we're working very hard to fix it. Please know we're here in the meantime.
On one hand, this isn't completely unique to Articulate's tools. This is a fairly common problem with a relatively easy solution. There is no reason for a browser to restrict web font downloads. It breaks an awful lot of sites on the modern web. The ligatures issue is uniquely annoying since it renders the output nearly useless.
On the other hand, I suspect there's a Javascript solution that should work to detect if a font used in the story published output is available and, if not, substitute a default. The failure is not at all graceful. It should be. Maybe adding something like the item below would help to resolve the issue?
https://www.samclarke.com/javascript-is-font-available/
We've experienced this problem as we work to deploy content and, while it's annoying, the short term fix ended up being using a font that appears on every desktop (Arial, Verdana) in the authoring environment. Would be nice not to have to do this but part of development workflows is contending with browser quirks. This isn't the first or the last we'll deal with:)
Our long term fix is working with our IT configuration folks to get the change into the configuration. It's amazingly easy to push a policy update and propagate across the organization. A change request is not that easy but isn't impossible. This is squarely an issue of someone choosing to lock down a feature in the security configuration that is extremely low risk. Once brought to their attention and the request was made, it wasn't a problem. Couple of options. One is adding the LMS to the trusted zone. The other is changing the setting for the web fonts download for all sites.
Hi Steve,
It may be easier to persuade IT to change browser configurations when the eLearning is developed within the company. It is a different matter when a 3rd party is delivering eLearning to a large corporation.
I did a quick google of "eLearning font ligature" and "online learning font ligature" and the only place anything comes up problem-wise is Articulate. The remaining links seem to be instructional.
This doesn't mean other eLearning authoring packages aren't having the same issue, but it suggests it may be more of a problem here.
Ligatures, yes. That seems unique to Articulate outputs. Font issues pop up everywhere. Most notably is where fonts contain icons. I think it's more of an issue with SL because ligatures are used to help bring parity between the authoring environment and the output. Sounds like Articulate is making progress on a fix.
It's not unreasonable to ask a company to whitelist their own LMS. It's possible that nobody had asked for it:) IT folks aren't very good at reading minds... yet.
Steve,
Thanks for offering your insights. I had the pleasure to work with you many years ago on a Marine Corps eLearning project (Heavy MachineGun), and I purchased a book you contributed to about developing Storyline. I have the greatest respect for your abilities.
That said, I've found no indications that competing eLearning development tools have negatively impacted learners with "missing letters" in their output. Looking at this thread, and related ones, this appears to have been an issue at least a year.
How is it possible that developers are still pointed to an article that advises them to have IT make a change to their server settings instead of applying a fix that empowers developers?
Yes, we all understand the need to develop to target browsers, and the challenges of catering to them all, but a known issue with IE11 that clearly impacts large organizations with many developers and big audiences?
Ashley indicated this problem is a priority. On behalf of the USMC, I hope it's priority ONE.
I just piloted tested and I have users complaining of the same thing. Has this been resolved? We are not using an LMS, they piloted the course using the Articulate Review link. We will be uploading the course on their website. Do I need to add a message about which browser would be better to use, but what happens if they are at work and don't have the option to pick a different browser? I'm just trying to figure out the best remedy, I'm a little embarrassed as I've spoken so highly about using Storyline for them and we have this issue. What is the fix?
This is an issue with web fonts in IE. You'll only see the problem in IE where the security configuration is set to block WOFF files. Couple of solutions, one is on your end, other is on the client's end:
I'd tend toward doing each of these. I think the Articulate team is looking into a way to get around this and more gracefully degrade. I ran into this as well. It only appeared in IE for us. We tracked it down to a security setting (web font download).
Thank you for the quick response. I am using Calibri for my font. Were you stating that (Arial, Verdana, Calibri, Georgia) are fonts I should avoid or these the fonts that don't require a download?
I have an additional question if you don't mind, the client is the source for housing the content and will do so on a website, but people all over the state will be accessing the site from their own workspaces/organizations. Is this something that each user will need to do or just the settings on the website the client is going to point the trainings too? I will share this information with them. Thank you again
I don't think it has been really established which fonts will or will not work unfortunately. There is another large thread on this topic here: https://community.articulate.com/discussions/articulate-storyline/letters-t-and-f-going-missing-in-storyline-360-for-small-population-of-users
Rereading that thread I think it looks like the safest bets are Times New Roman and Verdana.
Thank you!
Times New Roman, eh?
Sure glad Comic Sans isn't recommended as one of the few safe bets. :)
BTW - I was never contacted by anyone at Articulate as promised earlier in this thread.
I'm still curious as to why this issue doesn't appear to be an issue for Captivate or Lectora.
The two solutions offered are inelegant at best and not acceptable at worst for many organization's developers.
Get it fixed...
Hi, Rob. Really appreciate you continuing to add your voice, and I'm so sorry for the headaches this is causing you and your team.
While I don't have an ETA to share at this time, we'll certainly post all updates here once we have them – so you're in the right place! It's a complex issue – one that's at the top of the priority list to tackle.
Thanks again for your candid feedback. If there's anything else we can clarify or help with in the meantime, let us know! We, and our Support Engineers, are all standing by.
I'm using Arial and still seeing the same problem.
This discussion is closed. You can start a new discussion or contact Articulate Support.