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.
We have this issue too! It's totally random and inconsistent, difficult to pinpoint (because WE can rarely recreate the issue on our end, and are always going based on what clients tell us) and it's incredibly frustrating -- for us and the client. They get mad at us, thinking it's OUR fault, or asking why we didn't use 'web friendly' fonts (even when we do!). It's been an issue for more than a few months, and the ONLY workaround that has been consistent is publishing for Flash, which is not a longterm solution.
Unfortunately, this is just one of many many quirks and issues and bugs that we fight with daily using STL360 and we too will likely be moving to another tool over the next year or so. It's a shame, really :(
Would you mind posting any results from your tech support interactions? Thanks!
Here is the latest email we received from Articulate in regards to this issue in-case anyone is wondering. It doesn't appear this will ever be fixed:
Hello from Articulate,
We wanted to give you an update on an issue you’ve experienced where some characters (such as ligatures) in a Storyline 360 or Storyline 3 course would not display for some learners. A ligature occurs where two or more letters are joined as a single symbol, such as the fi in first, or the fl in flower. We want to tell you more about why this is happening, what we’ve done to try to mitigate this problem, and how we’re moving forward.
We investigated the issue and confirmed that it’s caused when font downloads are disabled in Internet Explorer, typically by a system administrator. This security setting prevents the player from downloading the fonts it needs to display the course as you’ve designed.
Storyline 360 and Storyline 3 require font downloads in order to precisely display content just the way that you’ve designed it. Our customers are super passionate about making sure their content looks right—and font downloads let us deliver on that expectation.
We explored addressing this concern by adding an option to turn ligatures on or off. We released the feature to our beta testing group and asked for feedback from other affected folks.
After months of feedback and careful analysis, we’ve decided not to move forward with this idea. Here’s why:
Customers told us that this didn’t solve the core issue because it required disabling ligatures for all learners, not just those affected by the IE security setting. It created concern amongst the majority of authors who felt they would now have to make an additional publishing decision based largely on guesswork. Overriding the text rendering engine in this way is complex and raised quality concerns because it’s impossible to ensure the feature will work as intended with different fonts and languages.
We also conducted a detailed analysis to measure the impact of this issue. Here’s what we found:
Blocked font downloads affect less than 1% of all learners. We’ve found no evidence that font downloads are a viable attack vector for malware authors. Chrome, Firefox, and Edge (widely considered the most secure browsers) do not expose a security setting to disable font downloads. In addition, Microsoft explicitly recommends against blocking web fonts.
With all of this in mind, we’ve determined that the best way to serve the needs of our customers is to continue to require font downloading, just like we require having JavaScript and other browser features enabled. We’ve revised our documentation to make this clear. As a prerequisite, learners using Internet Explorer (or their IT departments) should enable font downloads to allow the course to display as intended.
We know that this may be disappointing news, and we’re sorry. We’ve worked hard to come to a decision that allows us to deliver on customer expectations and focus development resources on the features and fixes that will have the greatest impact.
Thanks so much for working with us on this tough issue.
Has this ever been fixed? I am experiencing the same issues with Storyline 3, I have the latest update installed and am still missing letters. I did not realize it was only Ts and Fs until reading this post and then going back to look again. I am publishing to CD and it is happening. It seems to happen with publishing to HTML5, Flash and CD.
In the software everything shows as being perfect including the spacing between letters. It occurs after publishing to any one of the formats.
Can someone please advise as to a method to fix this issue.
This error is still present. I have a lot of customers complaining over this right now. It is mainly F that is missing. I thought it was our own font that caused the problem so I spent many hours to update all my modules but it didn't help. So this is not font related.
I have the latest version of Storyline 360 so it isn't a version issue either.
I can not reproduce it myself, it works when I look at the modules. So it seems to have something to do with what web browser you use. Can someone guide me in the right direction here?
I haven't tried to publish as flash yet, seems old fashioned? Should I try Flash/HTML5 or only Flash?
I don't know if the informations helps somebody but i can shorty explain my insights of the Problem.
The Problem occurs only in Internet Explorer. But the Internet Explorer is not the only Problem, all staff in our Company work with IE, but only a selected few have this Problem. We found out that this few people have an older Laptop with an old System Software (i think Windows 7, in Windows 10 it works). I think the combination of old System Software and IE is the Problem.
We dont have a solution for the Problem. We cannot change the browser because our LMS runs only in IE. We have added the LMS to the trusted sides, makes no difference. The only way to "fix" is the solution i found in the forum with the "%v%" in every TextBox. But when i do this the formatting is very, very ugly.
Maybe our IT department finds a solution when we roll out the next training, because the they analyse the individual cases. Its very complex because nobody can replicate the problem.
This is caused by a security setting in IE. If Fonts are set to "Disable" then web fonts won't load. This causes a couple of symptoms. First, it's all Times New Roman, all day. Second, T's and F's mysteriously disappear. Other glyphs might also be absent.
Publishing to Flash/HTML5 might help if the user has the Flash player installed but this is a short term fix since the Flash player will likely start disappearing at organizations starting next year.
I have had this problem in both IE and Chrome, when published to the LMS and simply to Articulate Review. The only solution I have found is to change the font to Articulate. Which is not ideal, but usable.
----------------------------------------------------------------------
The information contained in this message is confidential proprietary property of Nelnet, Inc. and its affiliated companies (Nelnet) and is intended for the recipient only. Any reproduction, forwarding, or copying without the express permission of Nelnet is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this e-mail.
Using safe fonts may help. The font problem shouldn't be present on tablet, smartphone, or any browser that isn't IE. It seems like lots of organization configurations tended toward "turn it off" for something that really doesn't have much risk.
Part of the problem with the font download is that everything will load as TImes New Roman no matter which font you use. You might have good luck using Times New Roman. The issue with missing glyphs is due to ligatures in the output. This is combinations of characters that give a more professional look. Because web fonts aren't loading, the ligatures aren't loading, which results in big blank spots in your text blocks.
I have a post publish surgery solution for this but it requires some hand jamming css files and careful selection of fonts safe on all machines. Segoe UI, Calibri, Arial, Georgia, etc.. should be found on any target machine. The local versions of these fonts should also contain the ligatures, so this trick should work in almost all cases when a safe font is selected.
Here's the trick. It takes time and care but it's worked in my tests:
I started poking around in the published files. Looking at the generated output.min.css file, I can see where the fonts are embedded in base64.
My theory (and it works) is that adding a local value to the font face rule would work to produce something a little less ugly. This might also fix the missing T's and F's in IE with or without the ligature setting, resulting in a sort of "automatic" handling. Normally, the local value goes first so that the font is pulled locally if it's available. In this case, I moved it AFTER the embedded font. So the fallback is loaded ONLY IF the WOFF can't be loaded. Having something like SEGOE UI load instead of vomit Times shotgun is an improvement. I'm considering putting together an article and video for this hack. Let me know if you try this out and it works for you.
1) Setup your browser to replicate the issue so you can see it in testing. Go into IE's security settings and drill into the custom level settings. About half-way down the custom level options page you'll see a download fonts option. Set this to disable. This will break web font downloads on your machine so you can see what's going on and test how well the trick fixes the issue.
2) Open the output.min.css file of your published output. You may need to unminify the file to make it easier to parse. Be sure to minify the file again when you're done to save a little space.
3) For each CSS font reference (there might be lots of them), look for a base64 font string. It'll be a gibberish looking block of characters. After the ') that follows the block, add a comma and then this:
local("Segoe UI");
Or substitute another font (arial, calibri, georgia) that you expect will be safe on everyone's machine.
4) Repeat for each occurrence of the base64 font block in the CSS file. It could take you a few minutes.
You can check the outcome by running the story.html file locally. You may need to redo this each time you publish the file. However, you might try keeping a copy of your edited output.min.css file to see if pasting the file in after publish continues to work. In some cases, this will be fine. In others (if you add additional content), you'll need to sweep back through the output.css.min file to find and add the local references where things aren't being updated. It'll be easy to see since the broken font will appear in Times New Roman.
Caveats:
- This won't work with special fonts that aren't present on the user's machine.
- You might break the output if you misplace a character. Articulate won't likely support this at all since it's outside of the intended tool workflow.
- There may be cases where the trick breaks down. I haven't seen any as long as you're careful to select safe fonts but it could happen.
This sounds a bit different than the issue we've discussed here and have documented here. Not to worry, we'll open Support cases for each of you and our team will be in touch soon! That'll help us get to the bottom of what you're running into and figure out next steps. Keep an eye out for an email from Support@articulate.com!
Steve, is it true that Storyline 2 did not exhibit this problem? I wonder how it embedded its fonts. I hope your fix works for some people because it seems like it is really needed.
I believe local(sans-serif); might be a safer alternative since it doesn't presume the existence of certain fonts on the remote machine, however the trade off is you don't get to choose which font the client will see.
An even more robust method might be setting a fallback stack like local('Segoe UI'), local('Arial'), local(sans-serif);.
Yeah. I think that might work. The only worry that I'd have is the possibility that the font used in SL is configured to use ligatures and the ligatures don't match up in the target font. The most faithful representation is likely going to be one where the font selected in SL matches the font configured for local display. Otherwise stuff might not align well and look way off.
Still an improvement over Times New Roman and likely a solution to the mysterious disappearing T's and F's.
We have reported this here and to our IT when last year they rolled out numerous Windows 10 laptops. So we experienced this in Edge browser. In addition, we learned to change/replace fonts in the course (Storyline) to more standard fonts found on typical pc. This is the first time we have seen this in IE and all other times reported last year it was using Edge. This course was developed in November 2018, in Storyline 3 and using up to date tools. We do not have direct access to our own LMS server as it is maintained by SAP for the giant entity Coca Cola North America, which maintains support for all its separate independent bottlers.
Some people at our company are experiencing this issue too. I'm just starting to investigate, but it's not looking promising seeing how many posts have been coming up for two years on this forum.
"We have had a couple of new staff starting and both have reported having technical issues with some of the onboarding elearning courses, including the code of conduct. The text is missing letters. For instance, User A showed me her screen when completing the code of conduct and all the letters F were missing from the text, which made it difficult to complete. Another employee showed me something similar today."
This is a terrible user experience and I can't seem to replicate. We're using custom company fonts, but most people have no problem with the course. After many completions over the last 2 months, this is the first time I'm hearing about this.
I have found out this after hours of investigation:
1. This only happens in some versions of Internet Explorer. Not in every version, only some.
2. Because of this, I can’t use any other font than 100 % safe fonts, in my case I’ve changed all my courses to font Arial. After this, none of my customers have experienced it again.
So in my experience you have two options:
Forbid Internet Explorer or change font.
Internet Explorer sucks big time, I can’t understand how Microsoft can escape massive critics for having a web browser no one can use. It is the same in many softwares, CRM SalesForce for instance.
Shame on you, Microsoft.
agreed - I opted to go into Storyline courses and do a replace fonts - and in many cases, even some standard fonts were not showing in the training for some people. I replaced each font type with Segoe UI. but overall, making a decision to replace all fonts, republish, and swap course out in LMS has caused frustration for the ones in progress but better for the masses going forward as new hires. ;-) all this because I can't tell them to not to use IE since last April/May we had a bunch of Chrome issues in our previously working storyline courses. ;-) Edge has given us more issues in other areas, especially older courses because there's no flash support and we're no longer publishing with flash support. Since some older courses, and some we borrow from other bottlers, still need flash - so they have had to use chrome and install Flash for some.
I asked the manager what browser the two employees were using and she said Internet Explorer 11. This seems to be in line with what everyone is talking about here. Would be nice to have a fix for this.
Martin, We have been able to trace the main problem to a security setting in IE 11 that blocks downloaded fonts. If your users are able to change this setting, then enabling downloaded fonts should fix the problem for those experiencing it. Here are some instructions on how to do this.
Unfortunately at some companies, IT Security locks users from being able to access these settings. In that case you would have to request that the IT department change the settings.
352 Replies
Thanks! Look forward to hearing from the Support team.
We have this issue too! It's totally random and inconsistent, difficult to pinpoint (because WE can rarely recreate the issue on our end, and are always going based on what clients tell us) and it's incredibly frustrating -- for us and the client. They get mad at us, thinking it's OUR fault, or asking why we didn't use 'web friendly' fonts (even when we do!). It's been an issue for more than a few months, and the ONLY workaround that has been consistent is publishing for Flash, which is not a longterm solution.
Unfortunately, this is just one of many many quirks and issues and bugs that we fight with daily using STL360 and we too will likely be moving to another tool over the next year or so. It's a shame, really :(
Would you mind posting any results from your tech support interactions? Thanks!
Here is the latest email we received from Articulate in regards to this issue in-case anyone is wondering. It doesn't appear this will ever be fixed:
Letters are still dissappearing with IE11 and Moodle, any progress on the fix?
Has this ever been fixed? I am experiencing the same issues with Storyline 3, I have the latest update installed and am still missing letters. I did not realize it was only Ts and Fs until reading this post and then going back to look again. I am publishing to CD and it is happening. It seems to happen with publishing to HTML5, Flash and CD.
In the software everything shows as being perfect including the spacing between letters. It occurs after publishing to any one of the formats.
Can someone please advise as to a method to fix this issue.
Hi June -
Is this happening only in IE11 for you or are you seeing it in other browsers as well?
Hi Steve,
Apparently, it is only on my laptop as one of my team members published to CD and nothing was a miss. Am baffled here.
Urgent!
This error is still present. I have a lot of customers complaining over this right now. It is mainly F that is missing. I thought it was our own font that caused the problem so I spent many hours to update all my modules but it didn't help. So this is not font related.
I have the latest version of Storyline 360 so it isn't a version issue either.
I can not reproduce it myself, it works when I look at the modules. So it seems to have something to do with what web browser you use. Can someone guide me in the right direction here?
I haven't tried to publish as flash yet, seems old fashioned? Should I try Flash/HTML5 or only Flash?
/Niklas
Hello,
It's internet explorer 11 that causes the problem. Maybe they could use another browser or you could change all font to arial?
Hi,
i also have the font Problem.
I don't know if the informations helps somebody but i can shorty explain my insights of the Problem.
The Problem occurs only in Internet Explorer. But the Internet Explorer is not the only Problem, all staff in our Company work with IE, but only a selected few have this Problem. We found out that this few people have an older Laptop with an old System Software (i think Windows 7, in Windows 10 it works). I think the combination of old System Software and IE is the Problem.
We dont have a solution for the Problem. We cannot change the browser because our LMS runs only in IE. We have added the LMS to the trusted sides, makes no difference. The only way to "fix" is the solution i found in the forum with the "%v%" in every TextBox. But when i do this the formatting is very, very ugly.
Maybe our IT department finds a solution when we roll out the next training, because the they analyse the individual cases. Its very complex because nobody can replicate the problem.
Thats is my Information to this Topic.
This is caused by a security setting in IE. If Fonts are set to "Disable" then web fonts won't load. This causes a couple of symptoms. First, it's all Times New Roman, all day. Second, T's and F's mysteriously disappear. Other glyphs might also be absent.
Publishing to Flash/HTML5 might help if the user has the Flash player installed but this is a short term fix since the Flash player will likely start disappearing at organizations starting next year.
My users are health care professionals and their computers are likely equipped with older browsers and OS’s. This is nothing I can affect.
This problem should not be present on a tablet or smartphone if the problem is as described?
Is the only solution to have the font Times new roman? Or Arial? Should that work?
I have had this problem in both IE and Chrome, when published to the LMS and simply to Articulate Review. The only solution I have found is to change the font to Articulate. Which is not ideal, but usable.
----------------------------------------------------------------------
The information contained in this message is confidential proprietary property of Nelnet, Inc. and its affiliated companies (Nelnet) and is intended for the recipient only. Any reproduction, forwarding, or copying without the express permission of Nelnet is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this e-mail.
Using safe fonts may help. The font problem shouldn't be present on tablet, smartphone, or any browser that isn't IE. It seems like lots of organization configurations tended toward "turn it off" for something that really doesn't have much risk.
Part of the problem with the font download is that everything will load as TImes New Roman no matter which font you use. You might have good luck using Times New Roman. The issue with missing glyphs is due to ligatures in the output. This is combinations of characters that give a more professional look. Because web fonts aren't loading, the ligatures aren't loading, which results in big blank spots in your text blocks.
I have a post publish surgery solution for this but it requires some hand jamming css files and careful selection of fonts safe on all machines. Segoe UI, Calibri, Arial, Georgia, etc.. should be found on any target machine. The local versions of these fonts should also contain the ligatures, so this trick should work in almost all cases when a safe font is selected.
Here's the trick. It takes time and care but it's worked in my tests:
I started poking around in the published files. Looking at the generated output.min.css file, I can see where the fonts are embedded in base64.
My theory (and it works) is that adding a local value to the font face rule would work to produce something a little less ugly. This might also fix the missing T's and F's in IE with or without the ligature setting, resulting in a sort of "automatic" handling. Normally, the local value goes first so that the font is pulled locally if it's available. In this case, I moved it AFTER the embedded font. So the fallback is loaded ONLY IF the WOFF can't be loaded. Having something like SEGOE UI load instead of vomit Times shotgun is an improvement. I'm considering putting together an article and video for this hack. Let me know if you try this out and it works for you.
1) Setup your browser to replicate the issue so you can see it in testing. Go into IE's security settings and drill into the custom level settings. About half-way down the custom level options page you'll see a download fonts option. Set this to disable. This will break web font downloads on your machine so you can see what's going on and test how well the trick fixes the issue.
2) Open the output.min.css file of your published output. You may need to unminify the file to make it easier to parse. Be sure to minify the file again when you're done to save a little space.
3) For each CSS font reference (there might be lots of them), look for a base64 font string. It'll be a gibberish looking block of characters. After the ') that follows the block, add a comma and then this:
local("Segoe UI");
Or substitute another font (arial, calibri, georgia) that you expect will be safe on everyone's machine.
4) Repeat for each occurrence of the base64 font block in the CSS file. It could take you a few minutes.
Each block should look something like this:
You can check the outcome by running the story.html file locally. You may need to redo this each time you publish the file. However, you might try keeping a copy of your edited output.min.css file to see if pasting the file in after publish continues to work. In some cases, this will be fine. In others (if you add additional content), you'll need to sweep back through the output.css.min file to find and add the local references where things aren't being updated. It'll be easy to see since the broken font will appear in Times New Roman.
Caveats:
- This won't work with special fonts that aren't present on the user's machine.
- You might break the output if you misplace a character. Articulate won't likely support this at all since it's outside of the intended tool workflow.
- There may be cases where the trick breaks down. I haven't seen any as long as you're careful to select safe fonts but it could happen.
Hi Niklas and Lywanda,
This sounds a bit different than the issue we've discussed here and have documented here. Not to worry, we'll open Support cases for each of you and our team will be in touch soon! That'll help us get to the bottom of what you're running into and figure out next steps. Keep an eye out for an email from Support@articulate.com!
Steve, is it true that Storyline 2 did not exhibit this problem? I wonder how it embedded its fonts. I hope your fix works for some people because it seems like it is really needed.
Hi Steve! Thanks for the awesome workaround!
I believe
local(sans-serif);might be a safer alternative since it doesn't presume the existence of certain fonts on the remote machine, however the trade off is you don't get to choose which font the client will see.An even more robust method might be setting a fallback stack like
local('Segoe UI'), local('Arial'), local(sans-serif);.Yeah. I think that might work. The only worry that I'd have is the possibility that the font used in SL is configured to use ligatures and the ligatures don't match up in the target font. The most faithful representation is likely going to be one where the font selected in SL matches the font configured for local display. Otherwise stuff might not align well and look way off.
Still an improvement over Times New Roman and likely a solution to the mysterious disappearing T's and F's.
We have reported this here and to our IT when last year they rolled out numerous Windows 10 laptops. So we experienced this in Edge browser. In addition, we learned to change/replace fonts in the course (Storyline) to more standard fonts found on typical pc. This is the first time we have seen this in IE and all other times reported last year it was using Edge. This course was developed in November 2018, in Storyline 3 and using up to date tools. We do not have direct access to our own LMS server as it is maintained by SAP for the giant entity Coca Cola North America, which maintains support for all its separate independent bottlers.
Some people at our company are experiencing this issue too. I'm just starting to investigate, but it's not looking promising seeing how many posts have been coming up for two years on this forum.
"We have had a couple of new staff starting and both have reported having technical issues with some of the onboarding elearning courses, including the code of conduct. The text is missing letters. For instance, User A showed me her screen when completing the code of conduct and all the letters F were missing from the text, which made it difficult to complete. Another employee showed me something similar today."
This is a terrible user experience and I can't seem to replicate. We're using custom company fonts, but most people have no problem with the course. After many completions over the last 2 months, this is the first time I'm hearing about this.
I have found out this after hours of investigation:
1. This only happens in some versions of Internet Explorer. Not in every version, only some.
2. Because of this, I can’t use any other font than 100 % safe fonts, in my case I’ve changed all my courses to font Arial. After this, none of my customers have experienced it again.
So in my experience you have two options:
Forbid Internet Explorer or change font.
Internet Explorer sucks big time, I can’t understand how Microsoft can escape massive critics for having a web browser no one can use. It is the same in many softwares, CRM SalesForce for instance.
Shame on you, Microsoft.
/Niklas
agreed - I opted to go into Storyline courses and do a replace fonts - and in many cases, even some standard fonts were not showing in the training for some people. I replaced each font type with Segoe UI. but overall, making a decision to replace all fonts, republish, and swap course out in LMS has caused frustration for the ones in progress but better for the masses going forward as new hires. ;-) all this because I can't tell them to not to use IE since last April/May we had a bunch of Chrome issues in our previously working storyline courses. ;-) Edge has given us more issues in other areas, especially older courses because there's no flash support and we're no longer publishing with flash support. Since some older courses, and some we borrow from other bottlers, still need flash - so they have had to use chrome and install Flash for some.
I asked the manager what browser the two employees were using and she said Internet Explorer 11. This seems to be in line with what everyone is talking about here. Would be nice to have a fix for this.
Martin, We have been able to trace the main problem to a security setting in IE 11 that blocks downloaded fonts. If your users are able to change this setting, then enabling downloaded fonts should fix the problem for those experiencing it. Here are some instructions on how to do this.
https://support.xmatters.com/hc/en-us/articles/207108186-Missing-icons-when-using-Internet-Explorer-11
Unfortunately at some companies, IT Security locks users from being able to access these settings. In that case you would have to request that the IT department change the settings.
Hi Martin,
It looks like Brian is helping you here, and I know this conversation has gotten pretty long, so I wanted to link to our documentation here as well.