Font Change within a Text Entry Field

As with Steve above could you please +1 me into the thread so I see replies.

Very frustrating as the output is looking amateurish!

Thanks Liam for weighing in here as well. Now that you've responded to the thread you'll receive updates via email. 

rant/

I want to +1 as well. I don't have a lot of good feelings about a resolution as this has been going on for over 3 years across at least two full versions, and who knows how many point releases. Incredible. 

i set my story size to: 

Story size - 1024 * 576

Record size - 1260 * 710 - I have to stretch it to this size to capture all of the screen for software simulations. None of these work arounds are of much value to me. They are not reliable.

About all I do are "click through" software demos with tons of text entry. So my results are that some slides have MS Sans at 12.5 while others have Tahoma 11, and others, well, whatever storyline feels like putting in and it's near impossible to change. The unreliability of the software, and the distinctly inconsistent results is embarassing, and is making me rethink my purchase and how best to deliver uniform, consistent, demos. 

This is a portion of why I am slowly developing a deep, abiding, hatred for storyline. It does have some really good features, but those rapidly fade when you get caught up in something like this and literally waste DAYS trying to fix it, only to discover it's an antique problem with zero reliable resolutions.

sarcasm/ It always helps when I get the "can't replicate the problem" from this site and support. /sarcasm

There is simply no way this many people have the problem but it can't be replicated by the company. 

/rant

Greetings, DJ:

I'm really sorry for the frustration and for the feeling that we're not trying to fix your problem.  To clarify, it seems like there are 2 or 3 separate and distinct issues being discussed in this thread:

1. During preview in higher-resolution slides, the font size of a text entry box reduces in size:  This is a problem that we have been able to reproduce reliably, and have reported to our Quality Assurance Team.  We can't guarantee if or when we'll have a fix, but we'll certainly keep this thread informed of any updates.
2. In the Storyline authoring environment, the font size of a text entry box always reverts to Articulate 12 point:  This is a problem that is consistently irreproducible during all internal attempts in all testing environments.  We're still hoping that one of our customers can demonstrate how to reliably reproduce this problem.

When you say that "some slides have MS Sans at 12.5 while others have Tahoma 11, and others, well, whatever Storyline feels like putting in," this problem description seems to be still slightly different from both of the above issues, and this is not something that I've heard of before.

I know it sounds cliché, but it's really difficult to troubleshoot a problem we cannot reproduce.  Would you be willing to send us (1) a copy of a .story project file that demonstrates this problem and (2) a screen recording that documents what the problem looks like on your end?  This would be a really helpful step toward understanding the behavior a little better.

Thanks in advance for your help!

HI Justin

I may be able to help with point 2.  This only happens if you remove the help text completely  (type your text here).

Remove that text, set the font whilst the control has focus, click off and then back on again and the font reverts to your theme font. It does not happen if you leave the instruction text in the field.

Phil:

The text entry boxes in step-by-step demos don't have help text, at least in my version, they are empty. 

Justin:

Here are two videos of it happening in the edit screen. It's a crap shoot what you'll see in the published material. It may be Segoe_UI, which is the font we use, or if may be, well whatever font and at whatever size. I have NEVER seen it go to the Articulate font. It's usually Arial, MS sans, or Tahoma, all in various sizes, but mostly 12.5.

I will send you the story, but it's near 100 MB and I'd want to do that privately, as I don't want it "in the wild". 

I do know how hard it is to fix a problem you can't see; but it looks like you *(Articulate/not "you" personally)* has had plenty of story files and other documentation of this problem. At least judging by this thread. 

And just as an aside, I started recording these videos with Articulate Replay, and was absolutely appalled to discover that it only supports video editing (cutting out a section) at the end or the beginning, but not in the middle of the video. I then edited the mp4 in SnagIt, which did the job without fuss at a fraction of the cost.

I realize it sounds like I'm a hostile (fill in the blank). But this is a huge frustration and time waster. Not to mention that my boss is a "don't blame your tools" kind of guy. So this ends up as my responsibility to fix. 

Hi Phil,

Thanks for sharing that piece here - and I was able to replicate that following the steps you mentioned and so was Justin, so we'll be reporting it to our QA team as a new issue. 

Thanks DJ for sharing the videos here as that was also helpful to see. If you'd like to share the file privately you can send it along to me here and I can include it in the report filed with our QA team. Are any of the fonts you mentioned set as your theme font or it's just randomly being assigned? Following the steps Phil mentioned it always reverts to my theme font (which I was using the default of Open Sans). 

As previously mentioned for the other issue in this thread I'm unable to offer a time frame in regards to this issue, but once we have information to share we'll post in this forum thread and if you share your file with me privately I will respond via your case as well. 

No, here is the theme I'm using. I also double checked my slide master and it looks like it's all Segoe_UI to me. 

edit/ I uploaded the story file. /edit

Thanks DJ - I saw the file come through and I will include that in the report filed with our team as well. I'll also respond via the case you submitted. 

If you are using Segoe UI then this will change on a users machine as it is not a default font.

The work around I found was to set the Font and size and then lock the textbook on the timeline , but must admit I never tried with screen record

@Ashley Terwilliger - Any traction on this issue? 

Hi DJ,

I don't unfortunately have any updates to share at this time but it's still being investigated by our QA team. Once I have additional info, I'll share it here for you. 

I created this thread 3 years ago. Still not a single update???

None. Did you find any sort of solution for the font changing in software simulations?

Luck. Just gotta get lucky. 

Well, that leaves me out. ;)

I'm really hating this. My work looks like a 6 year old did it. So inconsistent...

Most of the times, I find ways to avoid using text entry in my simulations. I'll find work arounds - like "for the sake of time, I have entered the user name for you" and animate it being added. It's a poor solution, but it's better than oversized text that doesn't fit in the textbox, right?

Yes, it is. I simply do not have that luxury. I do what I can, especially with longer text strings, but it's not much help. When "25" will not fit in a text box 1 inch long and 0.5 inches tall, there is a problem. A big problem.

Hi M,

This thread has gone on for some time - but there are actually 3 separate issues here, the latest of which DJ seems to have stumbled upon and was able to provide consistent steps to reproduce it. Unfortunately looking back to the original few posters it doesn't seem that our team was able to reproduce it and therefore it takes a bit longer to get additional information in regards to fixes, workarounds or updates. 

We've shared the information here in reports filed with our QA team, and I'll also include the recent comments in our next discussion of this issue. 

Thanks for your understanding and patience and once we have information to share, we'll update here. 

I'm using the work around suggested by Alexander. In addition, I've added another layer trigger to change the state of the separate text box to hidden, if the text entry variable is "not equal to (blank)". This prevents the separate text box from overlapping the text in later text entry fields that contain the same variable.

Hi.

I feel I MUST reawaken this sleeping link, which lay dormant for 11 months.

I got an idea from one of the freebie things on this website....to create a crossword puzzle for a chemistry class. I created 130 squares that make up 21 chemistry words, each with a data entry control and one button to check each and every entry. This is an enormous amount of tedious work, and it is literally painful that the font does not keep. I must set the font to 11 points and each data entry box is 32px by 32 px, so that the entire puzzle can fit on the page. i've set each and every box to 11 points, however on previewing, the data entry font is more like 16.5 and the letters simply don't fit in the box. Additionally, no matter what I do the m's get cut off. Is there a way to decrease the inner padding of a box, as in html so that perhaps the padding won't hide the text?

So has this link become inactive because a reasonable solution has been found and would somebody mind sharing? I've tried all the above but alas the font keeps reverting to whatever font size it thinks is right for itself, rather selfish I must say.

Kindly advise. Thanks.

Nope, no solution. Appears that they feel it isn't repeatable. 

Hi Daniel,

This thread started a bit ago and for awhile it wasn't reproducible based on the steps or files that had been shared. Our team has now identified reproducible steps for 3 separate issues that are discussed in this thread which my reply on November 3rd indicated. I did share these issues with our Quality Assurance team to investigate further - but at this time I don't have any updates or additional information to share. If you'd like us to take a look at your file, we're happy to as well and can then share it with our QA team for additional files to review. If you don't want to share your file, I completely understand that as well and once we have additional information to share we'll post as a part of this thread. I can't offer a time frame in regards to when I'll have information to share, but as long as you stay subscribed to the thread you'll receive the update via an email notification. 

I'm posting to follow this thread. I'm of course, dealing with the same issue. 

The strange part for me is (not sure if anyone else has a similar issue, there were so many comments in this thread i didnt read them all) When I change the text size, it DOES change for both the default text that appears in the text entry, as well as when the user begins to type.  I'll try yo explain:

Although a font size change does happen, it is inconsistent between the default text, and the users typed text. Lets say the default size of a uncustomized text-entry field is 12pt. Upon preview, the default text is smaller than 12pt, but the typed text is correct at 12pt.  If I change it from 12pt to 14, both the default and typed text sizes go up. However, the default text is still too small. I'm faced with either changing the default text to match the body of the course, and then the typed text being comedically huge, or the default text being nearly too small to read, and the typed text being normal. 

Hopefully this isn't an exact copy of what someone else said. Just hoping to possibly shed some light on whats happening and help the storyline QA team.