Font size inconsistency with javascript variables

Jun 04, 2014

Brande Morrison
By Brande Morrison

Hello:

In my storyline files, I have many JavaScript variables that I want displayed. Sometimes the variable is on its own in a text box, other times it's inline as part of a larger block of text. When the variable is on its own, the rendered font size when published is much smaller than what it's set to be on the slide, and no amount of changing it on the slide will render it larger. When it's part of a larger block of text (for example, a paragraph that uses JavaScript to display today's date within), the entire paragraph will render smaller, and there's no consistency with how small, either - sometimes it's a difference between 14 and 12pt, other times it shrinks the entire text down to 6 or 8pt.

This makes development very difficult as I don't know how the variable will appear when published because it's not matching what displays in development. Also, this doesn't happen consistently - the same variable that renders too small in one instance, is fine somewhere else.

Any suggestions?

Thanks!

4 Replies
Allen Clark
over 9 years ago09/04/14 at 4:50 pm (UTC)

Sorry to see there's been no response to your query, Brande. I have the same problem and did a search to see if anyone else has posted, and this was the only prior post that lined up with my issue.

Same thing as Brande related - if I have a variable to display in a text box, it appears correctly (the same size as text in other boxes set to the same size) when in edit mode but appears smaller when in preview or playback. The boxes are all set to "Do not autofit".

Here's what it looks like in edit mode...

And this is in preview... note that the lines of the text box on the left (yellow) no longer line up with the variable text as displayed (white).

Any ideas?

Steve Flowers
over 9 years ago09/04/14 at 5:40 pm (UTC)

The troubles start with the Results column header. Dynamic and static text render differently. Couple of things I'd take a look at here:


  • The way dynamic text displays is different, including line spacing, from what I've seen. The line spacing is the most notable difference. You might be able to adjust line spacing to accommodate but given the underline renders differently, I'd go with the solution below**

  • The bigger problem is with fonts. If the user does not have the font on their machine, the dynamic field will revert to something like Times New Roman. Going with a font that's expected to be on the device will help with this.

**To correct the problem in the screen shot above, I'd make each of the correct / incorrect text blocks a separate text object and align that object with the top of your questions. With the line spacing discrepancy, each successive line multiplies the visual alignment problem. This would separate the Result header from the dynamic parts as well, making it render consistently with the Question header.

Allen Clark
over 9 years ago09/05/14 at 12:46 pm (UTC)

Thanks, Steve. That's exactly what I wound up doing as a workaround.

BTW, I haven't experienced the font issue you mention. I've used a specialized font in some areas and there's no font substitution in the published piece for users/students. If I send the .story source to a developer whose machine lacks the font, then there's font substitution (which is easily resolved by sending them the font!).

This discussion is closed. You can start a new discussion or contact Articulate Support.