Problem with Formatting Text Variable
Jun 29, 2012
Pinned Reply
Hi Artur,
Thanks for reaching out! One workaround you can try is to copy and paste the size of the text variable (e.g. %ch1synop% - left side) to another reference text variable to a larger size to fit the variable values.
If you have additional questions, please let me know!
45 Replies
Hi Stephanie,
Yeah, this appears to be a bug/quirk with text fields.
A couple of work arounds:
Thank you for the suggestions, Bill, but I still can't get the text which contains the reference variable (on the 2nd layer) to have the correct formatting (Tahoma 14). If I can't get it to work then I won't bother using the variable.
Regards,
Stephanie
You can also try typing the font style and press enter... I've had that work too.
Can you post the story file?
Hi Bill,
I did post the .story file with my original post.
I'll try typing the font style and see if that works.
Thanks for the ideas.
Regards,
Stephanie
Yes, I've had a similar problem if I include variables in a text box any symbols I add do not render in preview or publish.
So something as simple as...
"%Age% ≥ 18 = Legal driving limit"
...cannot be written.
I've tried the suggested workarounds above but without success.
Would someone from Articulate like to comment, indicate when a fix is likely? This is a major headache for people like me who are doing courses involving basic math functions.
Hi Laurie,
Thanks for your input and feedback on this one. I'd recommend sharing it directly with our development team if you'd like to see this looked at in a future build. As far as when or if it will be worked in, I honestly can't say, but I know that the team sees every single feature request and they play a large part in determining what goes into each update.
Curious if anyone has found a solution to this. I have some text boxes created and was surprised to find I can get the user's input to stick to font type and size I have formatted the box.
If I set my text box on the slide where the user's entry is to appear to the full size I have allotted for the entry; the text fits in although the font size selected does not register.
The top example shows how I initially set it up and the results that are achieve. (the font is resized to fit the box created)
The bottom example shows the results after I took the same text box, added a bunch of "enters" after the text variable name. (the font entry flows well, but the font size is slightly smaller than selected.
At least it's a bit of a work-around for now.
Let me add something else that's somewhat related. In my experience if you try to add a text entry field and specify a font that the user doesn't have installed it will default to the Articulate fault I think. I've tried to use Myriad Pro and a couple of script type fonts in text entry screens and they work great when played back on my PC. But when sent to a colleague who doesn't have those fonts a substitution occurs. I think I can understand why that would be (the font can't be rendered if it doesn't exist on the system?) but it's still unfortunate.
I've had this problem too and it does seem pretty consistent...any caption containing a text reference seems to re-format all the text in the caption to something other that the default for the course which is a pretty major bug in my book! I'm using a name text variable to personalise my course and increase engagement for the learner but any benefit is lost when they see a highly conspicuous caption...
Ho hum...still love Storyline though : )
I was able to resolve this issue by changing the properties of the textbox in which I place the reference to Do not Autofit. For this solution you may also want to make the textbox to be the appropriate size for your screen/shape.
Jyldyz's solution not consistent.
Sooooo looking forward to the update here.
I'd put typography ahead of sliders & motion paths; but that's just my 2 cents ;)
Note: I will send a six pack of Tofino brew to the Articulate developer who conquers this mountain of a challenge. Yes. Six.
After further soul crushing publishing results... my offer is up to a dozen beers to the Articulate engineer or dev who fixes this.
My beautiful (and I mean beautiful) elearning project is in shambles because text variables crush the typography. You can forget about that paragraph spacing feature in SL2 when you use text variables.
THIS really needs to be fixed. Text variables are the most powerful feature in SL... But if they uglify our end product, their useless.
Hi Ryan,
Thanks for reaching out here, and I know that this is something we've shared with our team and that you've also been in touch with our product development team through other avenues, so I'd recommend continuing to share your thoughts and experience so that they can see the difficulties you're running into here.
Sorry that my fix doesn't work for you.
Also looking forward to an update on this issue!
No need to apologize Jyldyz. It was worth a try.
Thanks Ashley. I'll share more with the product dev team.
Thanks Ryan.
Any progress on this bug fix? Thanks
Hi Kelly,
There isn't a change yet in this behavior, and as I shared with Ryan earlier it's something that has been shared with our product development team and you're also welcome to share your thoughts here in the form of a feature request.
Thanks, hope they get to it soon, it's important. In the meantime, after fiddling with it today, I was able to get the formatting to stick using these steps:
1. Click into the variable box and type one character
2. Select and format the character so that is displays the way you want the variable result to look in the final presentation (bold, size, color, etc.)
3. Place your cursor just after the formatted character
4. Hit Enter. Your variable box should now have 2 lines
3.Use your mouse (don't backspace) to place your cursor just after the character (on the first line) and hit the backspace key to delete the character. (The second empty line should remain in the box)
4. Save
I think the app needs the formatting assigned to a character before it will retain the formatting, if that makes sense. So, what I did was provide t a formatted character, add an extra line, then delete that character from the upper line.
Hope I got the steps right. I'm curious to see if this works for anyone else. At any rate, it worked for me while trying to change/retain the formatting for a numeric variable. Hope it helps someone else.
Thanks,
Kelly Anne
Thanks for sharing those steps here Kelly Anne and I hope that they'll assist someone else struggling with the behavior.
Unfortunately, Kelly Anne’s suggestion was of no help in my situation. Take a look at the attached project. The cup was a freeform figure that I added text to (which was a suggested workaround on a related thread). The cup on the left has the typography as it should look (which I should mention was a nightmare to do). The cup on the left looks perfect—the leading is nice and tight, and everything looks fairly centered. But change that text to a text variable (in this case,
%Cup_1%
) and suddenly it scrambles up. A pain to work with, but with some careful cursoring via the arrow keys, it’s workable.But now the kicker—compare what you see in Storyline 2 with a slide preview, HTML output, HTML5 output, and Storyline Launcher (CD) output. They’re all different. (I know to expect some limitations with various output forms, but even the internal slide preview comes out wrong!) The default value of the variable (“8¼”) should make both cups identical, but it doesn’t. Even if this was a simple text box and not a freeform shape, these same issues would still occur.
I must agree with Ryan here—the typography tools have some serious issues that should be addressed. Workarounds (such as multiple text boxes atop a shape) can serve in a pinch, but that’s a quick way to stifle creativity and turn a beautiful project into something mediocre.
This one is still an issue guys, caught me out this week. Sadly Kelly-Annes workaround failed for me too.
Make sure you all submit it as a suggestion for improvement to the development team... they won't know how desperate we are for a fix if no one tells them. The more of us that bring it to their attention the more likely it is to get action.
Thanks Kelly for submitting the feature request - and we'll keep folks updated if there is a change to this behavior.
I am having the exact same problem now. The work around is not working either, a fix for this 4 year old problem would be very much appreciated, since text readability is the most important part of our elearning.
My current semi work around is to have the %textvariable% in its own text box, so it doesnt ruin the styling for the rest of the text. This works sometimes when the variable can be kinda standalone. The variables text style is still horible, but at least it doesnt ruin the rest of the text.