Working with text you reply upon readability; after all it is text.
Working on a particular project of mine much of the text is 12pt font or possibly 10. I quickly came across the issue of blurry text when you attempt to preview the output. But this took me a while as I was working with a lot of variables in my text. I notice some text came out blurry and others crystal clear.
Put a long story short I noticed that the one factor that made the text clear in all outputs was a variable. Don't ask me why this is the way it is, but I don't think it should be. I now put a blank variable in all my shape/text captions $$claritymark$$. The variable has nothing in it and just serves the purpose of clearing up the fuzzy text.
I could be wrong about this but I would think there is a better way to have clear text in your projects.
Which output will you use? Which version? Your explnaation seems to indicate you are publishing to SWF?
Will explain why. Static text containers used to be converted to images for SWF output. If you rescale the project that can lead to blurriness, btw 10 or 12pt is very small for eLearning.
Whereas dynamic text containers, which is text with inserted variables (like the score slide after a quiz) are generated on runtime, hence the difference.
The screenshot attached indicated the output as HTML. The need for crisp clear images is due to nature of the content. I have recreated an interface of an existing program and replaced the program info with captivate variables. This would allow for more control of simulated data. I realize the sizing issue of text and will increase it as I am able within the interface, but 12pt font is an upgrade from the 9-11pt don't the system is currently using. My course interface does have lager text for instruction; thanks for looking out.
That make sense as to why adding a variable would make any text crystal clear, but not why Captivate has not corrected the issue of text sizing and the blurriness that would result. I shouldn't have to add a nonsense variable to get svg level quality of text.
I may not have been totally clear yesterday, shouldn't reply around midnight after a tiring day, my apologies.
The focus of the team is on fluid boxes projects (not on breakpoint views nor non-responsive projects). In FB projects the fonts are generated on runtime.
For other projects, you need to avoid rescaling. Although I use Scalable HTML output a lot, you should avoid it if you have a text heavy course (which I never have). You can use the inserted empty variable trick as you have found or - which I did occasionally for clients who were not very pedagogical and insisted on lot of text - convert the text containers to SVG which will remain crisp since they are vector-based.
I could invite you to log a feature request, to have the choice for non fluid boxes projects between having text containers converted to images (bitmap), which is now the default, or to have them being generated on runtime. This has serious consequences, because you need to keep to websafe or Adobe fonts in that case (same as for dynamic text). From the long complaint threads from users who see the Replace Fonts dialog, you know that this is another 'holy house' (Flemish expression) difficult to destroy. That branded print assets are not the same as web content seems to be a difficult o understand. I am happy that most management people ignore totally th difference between color spaces (RGB vs CMYK) pr there would be another cause for long complaint threads.
This comes up all the time on our team. A suggested "fix", as you've already found, is to add the variable. I've seen this in a multiple discussions.
From the screenshot on the left, it looks like HTML5 is the output format? Are you also selecting Scalable HTML? That seems to be the main setting that causes the blurry text in my projects. Whenever I have compared a module published with and without Scalable HTML, the project without it is nice and clear. It's not a perfect science, but we try to capture our sims at a resolution that won't have to scale up or down too much when played full screen in a browser compared to the non-scalable version. We don't have the ability to know the exact size of client monitors, so we continue to use the scalable html option.
I haven't used responsive projects a whole lot, but I believe the text is supposed to render much more clearly. Lilybiri and others can speak to those much better than I can. I really need to get in and test the responsive simulation feature, but until then we are living with it and trying to be smart (use larger font, use resolution that is not going to scale up or down too much).
Again, we're not 100% sure which output mode you're selecting, so sorry if I got that wrong. But, I'd recommend looking into those options (not great solutions I know) if you don't want to use the added variable. We have chosen NOT to add it and use the same text containers throughout the whole project (SmartShapes with custom object styles, as opposed to text captions). Using only Smart Shapes at least makes it consistent throughout the projects, as we've found text captions and smartshapes look different.