Data Entry Font Difference Between Preview and Published

This is a known issue and is because fonts for variable values are not embedded into the published files.  

Phil,

Thank you.  This is disappointing. Imagine doing a Powerpoint presentation with two different fonts in the same bullet point.  What level of professionalism does that convey?  I know the team has lots to work on, but this bug is big enough in my opinion that upper management should put it on the A list.  Who can I go to and ask about a fix for this? 

VJ

You can raise a case with customer support or you can make a feature request

I think they both use the same form http://www.articulate.com/support/contact/submit.php

Hi Val Jon,

I don't see a support case or feature request yet for this, but you can always connect with our Support engineers here to submit a case  and to submit a feature request you can do so here.  

Ashley,

Great thanks!  Here is what I sent . . .

Hello team,

When publishing a data entry field and its reference (e.g., using narration bubbles for characters, "Hello Val Jon...") the data entry name defaults incorrectly to Times New Roman font in the Publish mode, but displays properly in the Preview mode as say, Articulate 12 point.  This is unacceptable.  Imagine giving a Powerpoint presentation live with such a font problem in a bullet item.  Would it seem professional?  Can you guys fix this?  It's a huge glitch for Storyline.

Thanks,  VJ

And Phil,  Thank you too!

Thanks Val Jon, and I see you sent it in as a support case which is great as then our team can take a look at your files and do some additional testing to confirm if it matches the known issue Phil mentioned. I'll continue to follow along in your case as well so that I can update the thread. 

Hi everybody,

I just came across the same issue last week. I totally agree with you Val Jon this is just unacceptable an prevents me to publish my courses. I will submit the case to support and also introduce a feature request. Just hope a second vote will help.

Have a nice day.

Thanks Dominique, it looks like based on the files you shared with Miker he was able to confirm that was the known issue that has been reported to our QA team regarding how variable reference text displays within a text box of other text, and suggested placing the variable reference text in a separate text box.