Font Change within a Text Entry Field

No matter what i do to the font and font size of the text within a text entry box, it always reverts back to the Articulate font, 12 point.

I've already noticed there are two ways to edit the font: You can click on the box and change the font, or you can edit the text and then change the font.

I've done both and every time it reverts back to Articulate 12pt.

Is this a bug?  What's the work around?  Highly annoying!

195 Replies
David Demyan

Now I will have to test it in SL3. For me, it always occurred in text boxes automatically generated when creating software simulations. I would take great pains to reformat the text to look like the real text entry, then every time I saved and re-opened, it would revert to some default I did not want. Locking on the timeline did not work. Changing text box properties did not work. Worse yet, sometimes it didn't show up until the course was published. Believe me, clients notice such things.

Bruce Roberts

Hi Ashley, I'm sure I'm not alone in sharing some frustration in seeing that an issue remains unresolved for some time.  We frequently see requests to report  issues.  I personally don't have time to report every issue I've encountered.  This in itself would be a full time job, even in a great product like Storyline.  What would be really useful, and already discussed in a different forum thread would be:

a) an indication of whether the issue has already been raised
b) an opportunity to "vote" (such as the "Mark as Helpful" flag) to indicate that I also have this issue.  Articulate would very quickly be able to get accurate stats regarding the extent of the impact without authors having to take time out to repeat already raised issues.

If this hasn't already been raised as an issue, I'm happy to reach out to your Support team! :-)

M. Bosscher

This issue completely changed how my department works and how we deliver training.

Same here. We just find ways to avoid text entry. Lame workarounds like "click in this box and we will enter the data for you." Doesn't work for all scenarios but what alternative do we have with SL1,err SL2 wait SL3!  

Bryan McD

The bug is a showstopper for any kind of software simulation application
requiring text entries. If you can't make data entry fields behave exactly
like the software you are emulating...its of no value to me. Storyline is
only good for simple gaming, drag and drops, crosswords. It is all macro
driven...you can't get into the API. If you need a toy for your
instructional design and development projects or very non demanding
clients)...stick with Storyline.

DJ Trent

This issue was the catalyst for us to rethink our full approach to training. 

We avoid the issue by having moved completely off SL-whateverversion. At first, we just used SL2 for the most trivial of training projects; now we don't use it at all. I don't think I've even started the program in nearly a year. 

David Demyan

I tried to use Storyline as a simulator / demo tool including text entry from SL1 and re-tried it every release. It would be soooo useful if you could ask the learner to type in exactly what they should and have it look just like the text boxes in the real system. I spent quite a bit of time with Articulate developers reporting exactly how the bug performed in SL 1 and SL 2 and it was reported fixed a couple of times. Alas, not so. Apparently it still misbehaves, ignoring specific text box formatting commands and weakening the demo/simulation features.

HOWEVER, I paid my bucks and bought 360. Why? I can do my work for most client requests more effectively and faster in SL than I can in the other tools.

I've found my own workarounds for doing the simulations my clients demand--buy another expensive tool that does it right. However, there are still many good features in Storyline and the software is improving steadily. I smell sour grapes when someone on this forum calls SL a "toy" or "totally useless." These OTT comments might do one useful thing--convince Articulate that they ought to fix the problem once and for all. I don't really think it's all that tough. Just give us a method to override the default text box properties in recorded simulation text boxes.

Justin Grenier

Hi, all.

There are a lot of replies here, and some issues seem to be blending together.  A quick update to sort the good from the not-so-good:

What We've Fixed

In Storyline 2 Update 10 (November 2016), we fixed 3 bugs related to text in data entry fields:

  • The Text Entry Font Style Was Reverting to the Theme Font When Removing the Standard "Type Your Text Here"
  • The Text Entry Font Was Defaulting to 12 Pixels When Using a Higher-Resolution Slide Size, Even if You Changed the Font Size
  • The Text Entry Field in Screen Recordings Would Randomly Change Font when Clicking Inside the Text Entry Field

These 3 bugs should no longer be present in Storyline 2, Storyline 3, or Storyline 360.  Let us know if you still see them!

What We Haven't Fixed Yet

These 2 bugs have a narrow impact or are unique to one customer:

  • Text Entry Doesn't Retain Alignment Formatting:  This works OK in almost every case, including all HTML5 cases. The text entry Flash prompt is showing up in the right location, but when the learner starts typing, the text is top-aligned.  We need to fix it so that the typed characters show up in the middle as well.
  • Action Fine Tuning Reverts the Frame Selection to 1-0 on Some Slides:  One customer in this thread reported this problem, and we haven't been able to reproduce it outside that single customer environment.

What We Can't Reasonably Fix Right Now

Fonts for Variable References May Be Different in Published Output:  We can't make variable references display using custom fonts right now because we don't know what characters a variable might use, and embedding every character in a font would seriously inflate the size of your published output.

Judging by the amount of activity on this thread yesterday, we've missed something really important (or maybe more than one important thing), and we want to help.  Please click here to tell us exactly what's going wrong and we'll investigate.

We can all continue to add onto this forum thread if that's the easiest way for folks to communicate, but that may not be the best method of digging deep into individual issues.

As always, thanks for letting us know what's important to you!

Daniel Moore

Text Entry Doesn't Retain Alignment Formatting: This works OK in almost every case, including all HTML5 cases. The text entry Flash prompt is showing up in the right location, but when the learner starts typing, the text is top-aligned. We need to fix it so that the typed characters show up in the middle as well.

To throw in my two pennies, I get this issue every single time I try to insert a text entry field. 

As most other people on this thread, I've stopped using them completely. Can't believe it's not been fixed in 5 years.

Logan Stahler

What We Can't Reasonably Fix Right Now

Fonts for Variable References May Be Different in HTML5 Output:  We can't make variable references display using custom fonts right now because we don't know what characters a variable might use, and embedding every character in a font would seriously inflate the size of your published output.

Judging by the amount of activity on this thread yesterday, we've missed something really important (or maybe more than one important thing), and we want to help.  Please click here to tell us exactly what's going wrong and we'll investigate.

We can all continue to add onto this forum thread if that's the easiest way for folks to communicate, but that may not be the best method of digging deep into individual issues.

As always, thanks for letting us know what's important to you!

So are you saying projects published with Flash as the default will always display the correct font regardless of font choice?  

Justin Grenier

I apologize for the inaccuracy of that Knowledge Base link, Logan.

We won't be able to make variable references display using custom fonts in Flash OR in HTML5.  I'll edit the text above, and we've updated the KB article accordingly.

If you're using Storyline 360 or Storyline 3 HTML5 output, you could try this creative JavaScript solution from community member Matthew Bibby.