I am getting some really odd feedback for one of our Storyline 360 courses (published for HTML5 with Flash backup). Has anyone encountered this / knows what is going on? Unfortunately I haven't been able to replicate the issue. Here are some of the comments the course is getting:
"Why are all the t's and f's missing?"
"Most all T's and F's are missing"
When opened in Explorer there were missing letter so it was very hard to read.
"Some of the slides had letters missing"
"All the missing letters were very odd. Was there a point?"
"The content was difficult to read mostly because of there were letters missing throughout the slides. It seemed mainly all the "t's" and "f's"
Why are all the t's and f's missing? That was very strange and might be very hard for people with visual difficulties.
This was essentially my issue as well (client/security settings).
I reapplied a different font (Arial and Verdana to test), which fixed the dropped letters issue. But IE settings override the font choices to TImes New Roman, and so the look and feel has changed...I have yet to just build our content using TNR, but that is my next step to see what the overridden content looks like once deployed.
Honestly, I've published so many versions that I don't remember. I think it was html5/flash. I've had them try every combination from our server and none of them worked.
3) Try to disable Compatibility Mode and test your course again (Compatibility Mode does not support HTML5 pages). Follow the steps below: - Press Alt + T in your keyboard > select Compatibility View Settings - Verify that the site is not in the list and that "Use Microsoft compatibility lists" and "Display Intranet Sites in Compatibility View" is unchecked
Please feel free to let us know here or respond to your case with Jonathan!
No, they're not able to. I suspect the issue is #1, but they're not able to change those settings. Not even their IT is able to disable it. They say it's locked for security reasons and they are unable to change it.
Wanted to share what my company has learned. We rolled out a new internet group policy about the same time the courses, new and existing, started dropping letters, so we started there.
Our IT team went through line by line and finally found the setting "Data URI Support" being disabled was causing the letters to disappear. This security setting needs to be enabled or not configured through group policy.
We pushed the change to everyone and instantly they all started displaying correctly again. Hope that's the answer for the rest of you!
Following up on this post, after changing all of the fonts to TNR across the whole project, there are no more dropped letters and things display mostly as intended.
I will say though, with the heightened security for my particular team/project, IE still strips from the Notes panel any font changes like bold, underline, or italics, but the text displays otherwise fine.
Thanks for sharing what worked for you, Katherine!
Regarding IE stripping the Notes panel of any formatting, I'd like to investigate this a bit. What version of Storyline are you using? Are you on the most recent update of that version?
Found out whats going on here. I've been running into this problem as well in Storyline3 and after digging into it found the cause. Should be the same in 360. It is a couple of things actually.
1st. Webfonts are sometimes blocked by security settings on the user's computer. for example our corporate IT security standard is for Downloaded fonts to be blocked in IE. This means the default non-webfont font will display instead (Times roman is the default here)
2nd. the text is saved by Storyline with "ligature" characters in it. These are special versions of characters like t and f or even combinations like ti that are used for the text to flow together or connect to characters around them. This works great with webfonts, but when the browser falls back to regular fonts, it has no characters to use in these cases and just leaves them off instead.
I assume that Storyline only uses those characters when a font is selected that supports them, or when it detects that the font does. Perhaps someone from the Storyline team can shed some light on that?
We are going to try switching fonts to see if we can find one that does not have this issue. Unfortunately we are also translating to a number of languages and not all fonts support them all, so it might be tricky finding one without ligatures but that supports 13 languages.
We do support ligatures in fonts within Storyline version 2 and later. The missing Ts and Fs have been traced back to the LMS and using Internet Explorer (which was forced into compatibility mode).
I'd suggest contacting your IT team or LMS admin to ask about the compatibility mode settings before replacing all your fonts - a bit less work with the first option. 😉
Thanks for the response! Unfortunately in this instance it is an IE Security setting (download fonts disabled), not an LMS server setting that's causing the Font not to display. We are part of a large corporation and getting corporate level IT Security settings changed is not the easiest.
It's not really a bug and may not be that big of an issue depending on how many people end up in the same boat we are in, but the fact that the Storyline courses don't gracefully handle not being able to load WebFonts may be something to put on the roadmap for future updates.
Ideally it would be able to fall back to regular system fonts without concern about whether the original font had ligatures. And since we can't always control the settings of the end users browser it would be great to know it will still be readable no matter what.
That said I completely understand if its not a top priority. Hopefully these posts about Web fonts and ligatures will at least help point people in the right direction if they run into the same problem.
I'd just like to "ditto" what Brian said. We've had to switch to Captivate for one of our biggest clients because of this. Just as Brian said, their corporate level IT is unable/unwilling to make the settings change and individuals aren't able to override that. The developers and in fact our entire team prefer Storyline, but we're not able to use it more and more because of concerns about not being able to control the end user's settings. It's a pretty big deal.
Can anyone explain why some (most) of the letters will print when the Browser's security setting is supposed to block downloadable fonts? This doesn't sound like a credible explanation when only certain letters fail to print.
I think Brian discovered this when he said that, "... the text is saved by Storyline with "ligature" characters in it. These are special versions of characters like t and f or even combinations like ti that are used for the text to flow together or connect to characters around them. This works great with webfonts, but when the browser falls back to regular fonts, it has no characters to use in these cases and just leaves them off instead."
So it has to do with the fact that ligature fonts are involved and t and f take advantage of this font feature in web fonts, but default fonts can't represent this.
That's an interesting observation. Code this have any impact on screen readers or is there already something in place to provide different text to screenreaders?
Really good question John, I did not think about the impact on Accessibility. Although I can't test things out to verify right now, this post seems to suggest that screen readers do not handle ligature characters well:
It's possible that Storyline has something in place to correct this or that the information in the post is outdated though. Perhaps Ashley or one of the other Staff members can look into it for us and let us know if we need to be concerned with ligature fonts breaking accessibility requirements?
That's a good question about accessibility, Brian. We can't use 360 as it is for our client, so I'm not sure.
Can anyone on the Storyline staff let us know whether this font issue is being addressed? We have a new round of work coming up and unless this is fixed or if there's anyway to make Storyline 2 available as html5 only (no flash whatsoever), we're going to have to switch to Captivate which I really hate to do.
The last response I see in your case with Jonathan was his recommendation about the IE settings, especially adding it as a trusted site and disabling compatibility mode and how those were impacting the course fonts.
I haven't seen that this issue is replicated by our team as it does seem specific to the browser and settings being used. We have a couple issues specific to some custom fonts not display correctly, and if you're using something like that - again, we'd love to take a look.
As for the accessibility, if the font is not appearing correctly on the screen, it may not be accessible to screen readers. This is something I'd suggest testing to confirm - and since our team hasn't consistently replicated the missing fonts, I don't know that we'd be much help here. 😕 You could look at adding in alt text to ensure that the text was there and visible to the screen readers.
Please let me or our Support team know if you need anything else. We're here to help! 🙂
We are able to consistently replicate in our Stores and can not currently use Articulate 360 or Storyline for those courses because of it. Due to PCI compliance we can not adjust the IE settings as suggested on those computers. I did try adding our LMS as a trusted site but I still get the same thing. The images I posted earlier were after setting the site as trusted.
If anyone has a font that works please let me know so we can update and try that. The courses that are not working do seem to be the templated ones we created.
Yes, I am confident that the IE settings would fix the problem, but for security reasons, our client cannot and will not change the setting. We've talked at length with their IT and is simply not an option. Based on what others here are saying, we're not the only ones with this problem.
We had to rebuild our courses in Storyline 2, which was no small feat, and after all that they don't even work all that well because our client also strips all Flash and Storyline 2 just isn't all that great in html5. We're really in a bind with them because of this.
352 Replies
This was essentially my issue as well (client/security settings).
I reapplied a different font (Arial and Verdana to test), which fixed the dropped letters issue. But IE settings override the font choices to TImes New Roman, and so the look and feel has changed...I have yet to just build our content using TNR, but that is my next step to see what the overridden content looks like once deployed.
Honestly, I've published so many versions that I don't remember. I think it was html5/flash. I've had them try every combination from our server and none of them worked.
Hi Kristen,
Were your colleagues able to go through the steps that Jonathan shared for compatibility/protected mode in IE? I've included them here as well.
1) Try to disable Internet Explorer's protected mode by following the steps here and then view the page again:
http://www.sevenforums.com/tutorials/63141-internet-explorer-protected-mode-turn-off.html
2) Try to reset Internet Explorer's settings by following the steps here then view the page again:
http://support.microsoft.com/kb/923737
3) Try to disable Compatibility Mode and test your course again (Compatibility Mode does not support HTML5 pages). Follow the steps below:
- Press Alt + T in your keyboard > select Compatibility View Settings
- Verify that the site is not in the list and that "Use Microsoft compatibility lists" and "Display Intranet Sites in Compatibility View" is unchecked
Please feel free to let us know here or respond to your case with Jonathan!
No, they're not able to. I suspect the issue is #1, but they're not able to change those settings. Not even their IT is able to disable it. They say it's locked for security reasons and they are unable to change it.
Wanted to share what my company has learned. We rolled out a new internet group policy about the same time the courses, new and existing, started dropping letters, so we started there.
Our IT team went through line by line and finally found the setting "Data URI Support" being disabled was causing the letters to disappear. This security setting needs to be enabled or not configured through group policy.
We pushed the change to everyone and instantly they all started displaying correctly again. Hope that's the answer for the rest of you!
Hi All,
My friend Sagar has solved this issues. you need to enable this option in IE.
Following up on this post, after changing all of the fonts to TNR across the whole project, there are no more dropped letters and things display mostly as intended.
I will say though, with the heightened security for my particular team/project, IE still strips from the Notes panel any font changes like bold, underline, or italics, but the text displays otherwise fine.
Thanks for sharing what worked for you, Katherine!
Regarding IE stripping the Notes panel of any formatting, I'd like to investigate this a bit. What version of Storyline are you using? Are you on the most recent update of that version?
Found out whats going on here. I've been running into this problem as well in Storyline3 and after digging into it found the cause. Should be the same in 360. It is a couple of things actually.
1st. Webfonts are sometimes blocked by security settings on the user's computer. for example our corporate IT security standard is for Downloaded fonts to be blocked in IE. This means the default non-webfont font will display instead (Times roman is the default here)
2nd. the text is saved by Storyline with "ligature" characters in it. These are special versions of characters like t and f or even combinations like ti that are used for the text to flow together or connect to characters around them. This works great with webfonts, but when the browser falls back to regular fonts, it has no characters to use in these cases and just leaves them off instead.
I assume that Storyline only uses those characters when a font is selected that supports them, or when it detects that the font does. Perhaps someone from the Storyline team can shed some light on that?
We are going to try switching fonts to see if we can find one that does not have this issue. Unfortunately we are also translating to a number of languages and not all fonts support them all, so it might be tricky finding one without ligatures but that supports 13 languages.
Hi Brian,
We do support ligatures in fonts within Storyline version 2 and later. The missing Ts and Fs have been traced back to the LMS and using Internet Explorer (which was forced into compatibility mode).
I'd suggest contacting your IT team or LMS admin to ask about the compatibility mode settings before replacing all your fonts - a bit less work with the first option. 😉
Ashley,
Thanks for the response! Unfortunately in this instance it is an IE Security setting (download fonts disabled), not an LMS server setting that's causing the Font not to display. We are part of a large corporation and getting corporate level IT Security settings changed is not the easiest.
It's not really a bug and may not be that big of an issue depending on how many people end up in the same boat we are in, but the fact that the Storyline courses don't gracefully handle not being able to load WebFonts may be something to put on the roadmap for future updates.
Ideally it would be able to fall back to regular system fonts without concern about whether the original font had ligatures. And since we can't always control the settings of the end users browser it would be great to know it will still be readable no matter what.
That said I completely understand if its not a top priority. Hopefully these posts about Web fonts and ligatures will at least help point people in the right direction if they run into the same problem.
Thanks Brian, and we're always looking at ways to improve and ensure that courses work for all users.
I'd just like to "ditto" what Brian said. We've had to switch to Captivate for one of our biggest clients because of this. Just as Brian said, their corporate level IT is unable/unwilling to make the settings change and individuals aren't able to override that. The developers and in fact our entire team prefer Storyline, but we're not able to use it more and more because of concerns about not being able to control the end user's settings. It's a pretty big deal.
Can anyone explain why some (most) of the letters will print when the Browser's security setting is supposed to block downloadable fonts? This doesn't sound like a credible explanation when only certain letters fail to print.
I think Brian discovered this when he said that, "... the text is saved by Storyline with "ligature" characters in it. These are special versions of characters like t and f or even combinations like ti that are used for the text to flow together or connect to characters around them. This works great with webfonts, but when the browser falls back to regular fonts, it has no characters to use in these cases and just leaves them off instead."
So it has to do with the fact that ligature fonts are involved and t and f take advantage of this font feature in web fonts, but default fonts can't represent this.
Sam, read Brian's post above that starts with "Found out whats going on here". He explains why only certain letters are affected.
That's an interesting observation. Code this have any impact on screen readers or is there already something in place to provide different text to screenreaders?
Really good question John, I did not think about the impact on Accessibility. Although I can't test things out to verify right now, this post seems to suggest that screen readers do not handle ligature characters well:
http://adamdscott.com/ligatures-on-the-web/
It's possible that Storyline has something in place to correct this or that the information in the post is outdated though. Perhaps Ashley or one of the other Staff members can look into it for us and let us know if we need to be concerned with ligature fonts breaking accessibility requirements?
We are having the same issue and its on the pop up system windows as well for the course.
But oddly enough the issue of no "f" is not on the TOC. The TOC displays the letter 'f' fine.
That's a good question about accessibility, Brian. We can't use 360 as it is for our client, so I'm not sure.
Can anyone on the Storyline staff let us know whether this font issue is being addressed? We have a new round of work coming up and unless this is fixed or if there's anyway to make Storyline 2 available as html5 only (no flash whatsoever), we're going to have to switch to Captivate which I really hate to do.
Hi Kristen,
The last response I see in your case with Jonathan was his recommendation about the IE settings, especially adding it as a trusted site and disabling compatibility mode and how those were impacting the course fonts.
I haven't seen that this issue is replicated by our team as it does seem specific to the browser and settings being used. We have a couple issues specific to some custom fonts not display correctly, and if you're using something like that - again, we'd love to take a look.
As for the accessibility, if the font is not appearing correctly on the screen, it may not be accessible to screen readers. This is something I'd suggest testing to confirm - and since our team hasn't consistently replicated the missing fonts, I don't know that we'd be much help here. 😕 You could look at adding in alt text to ensure that the text was there and visible to the screen readers.
Please let me or our Support team know if you need anything else. We're here to help! 🙂
We are able to consistently replicate in our Stores and can not currently use Articulate 360 or Storyline for those courses because of it. Due to PCI compliance we can not adjust the IE settings as suggested on those computers. I did try adding our LMS as a trusted site but I still get the same thing. The images I posted earlier were after setting the site as trusted.
If anyone has a font that works please let me know so we can update and try that. The courses that are not working do seem to be the templated ones we created.
Hi Ashley,
Yes, I am confident that the IE settings would fix the problem, but for security reasons, our client cannot and will not change the setting. We've talked at length with their IT and is simply not an option. Based on what others here are saying, we're not the only ones with this problem.
We had to rebuild our courses in Storyline 2, which was no small feat, and after all that they don't even work all that well because our client also strips all Flash and Storyline 2 just isn't all that great in html5. We're really in a bind with them because of this.
Not sure it helps, but I'm wondering if turning off ligatures in the .css might be a way to work around this?
see https://stackoverflow.com/questions/39504775/disabling-font-ligatures-css-letter-combining
Also: http://blog.fonts.com/2016/06/to-ligature-or-not-to-ligature/