Blurry fonts in Captivate

[OzBassist]

This is a well known and serious issue. Adobe have known about it for ages, and despite their large resources, simply refuse to do anything about it. 

It's not limited to scaleable projects. Unless you make responsive projects, or use the variable hack, you will get blurry text.

I can't understand why, when you use typekit fonts and have to specify a domain when publishing, that the font isn't even used. Adobe simply rasterizes the text (makes pixels of it) - and badly at that.

I've had three clients recently that have rejected work that I have done because (and I quote one of them here) "the text looks like it was drawn by an ink pen on wet paper". A great effect if that's what you were aiming for, but in my case, three completely dissatisfied clients.  It's meant that I've had to waste time going through every project and either converting them to responsive mode (which is sketchy at best), or using the variable hack. I've been using Captivate since day 1, and I'm one of it's biggest fans. But not now. Now you've just cost me a whole bunch of money and I have clients that don't trust me any more.

Adobe, why don't you just put live text on the page? Firstly, you'd have a smaller file size, as you wouldn't have to render each text block as pixels. Secondly, you'd have accessibility ticked off, rather than writing aria labels of, you guessed it, the actual text.

I'm now looking at Articulate/Storyline and Hype to replace my elearning authoring needs, because they at least make the type look better.

If I could find a way to speak to an Adobe representative directly about this, I would, but it seems that the only way to ask a question is via a user forum, which is ridiculous.

[OzBassist]

Here's a link to where you can browse this problem:

This is the published HTML5 file 

Here's a download of the cptx file 

If you open the cptx file, check out the project variables:

Project : Variables

See that I've created a user variable called $$xx$$

In the 2 columns of text on the first slide, I've inserted this into every text frame - I used Smart Shapes, but I could have used text captions.
Hopefully that'll help you guys temporarily solve this major problem with a hack that tricks Captivate into rendering the text as live text rather than rasterising it.

[Suroky5]

Hi John!

I totally agree John!  I have recently started a contract to create non-responsive courses and to clean up exisiting ones.  I have had to add the variable hack to every line of text and button in all thier lessons ( which also moves things up a couple of pixels).  Yes this works, but its a ridiculous way to make the text look sharp and not look like it was created in the 1990s.  I have many multimedia elearning friends who's companies they work for have moved onto other software due to the old fashioned look and feel, which is a real shame.  Adobe need to put more money into Captivate and focus on the cosmetics - get thier designers to work their magic on the look and feel and bring it into 2021 with more integration with their other software.  However, the 360 and simulation elements are excellent and in the right direction.

[Lilybiri]

@Suroky5  Agree about the cumbersome workaround with the dummy variable, as I explained here: 

http://blog.lilybiri.com/fonts-in-captivate

However I want to correct a sentence: you do not need to add that variable to each line of text, only to each text container which can be a shape or a caption. If you take care to insert the dummy variable with a lenght of 1 character there is very little chance that you will move the text. 

Thanks for the possitive comments.  I completely support you rrequest for improving the collaboration with other Adobe applications, although the roundtripping with Photoshop is remarkable. Roundtripping with Audition works fine, I would love to see restoring a better communication with OAMs created with Animate CC and between SVGs and Illustrator.

http://blog.lilybiri.com/roundtripping-with-adobe-photoshop-in-2020

[OzBassist]

Yeah, the hack only needs to be once in each box.

Excuse me if I laugh about your comment about 'better communication with OAMs'. 
I know in the old days we only had a couple of options.

I'd be satisfied with the ability to:

1. Set a CP variable
2. Be able to address an object or instance defined in the Captivate space
3. Call a function defined within CPM.js or any connected script and pass parameters.
4. And I'm sure Lieve would be stoked if she could get Animate to trigger some Advanced Actions!

But as you say, Adobe doesn't seem to want to spend any more money on keeping this product alive.

Lieve and I have spent years working with this produst, and although it has been full of bugs and problems, Captivate has become one of the best tools for the job. 

But the others have caught up and are passing very quickly.

For instance I use Tumult Hype for quite a lot of stuff now because the fonts are managed just like any HTML5 project - through standard CSS, and Javascript is open and works a treat.

Responsive projects are much easier to set up - much!

Animation is really easy, works just like Flash/Animate but easier

And the interactivity and ease of its use is even better than Flash/Animate.

SCORM setup is a bit clunky still, but it's super cheap, and has a really active community and responsive development team.

I say this because I'm at a point with Captivate that I've had enough of the buggy, slow, clunky and ineffective solution that Captivate has become. 

I'd stay with it and fly the flag if they made more effort to listen to customers.

If you check this topic in the forum, I believe you'll see it was brought up as far back as 2006, with many instances in between.

I think 15 years is sufficient to either fix the problem, or go and play golf, don't you think?

[OzBassist]

Just something else to add to this post, since I seem to be using it to keep notes about why you get blurry text in Captivate.

In the old days, the excuse was that because you couldn't embed fonts in Captivate (or more specifically, in SWF output), the text was converted to PNG.

But now that we have Typekit and Google fonts, there is simply no reason to want to embed fonts anyway, as the CDN should serve them up just like it does to a billion websites.

If you use common fonts it's even likely that users will already have them cached in their browsers, meaning faster delivery and load time.

But hang on - Adobe doesn't do that. They get you to choose a font from Typekit (with your account), then ask you to plug in the domain(s) you want to use it on when you publish the file to HTML5. 

And then the completely ignore the whole concept of serving data from a Content Delivery Network, and rasterise (make pixels) of all your text, making it blurry and non-scalable.

It simply doesn't make sense.

[TLCMediaDesign]

If you look at your side by side in Chrome, you'll see the difference in the line heights. The one as an actual font is almost 2 lines off at the bottom. lines also break at different places. If you look at it in IE it's a line and a half longer. Edge and Chrome render the text the same, didn't look in Firefox.

Different browsers render fonts differently so if you were to use a hotspot it could get way off. I've had this issue many times in Lectora. So I would create some text in phtoshop and save as an image to get around the difference. It's not an issue on a webpage that is not in a fixed page size.

I always select all sides and choose the quality as high 24 bit it don't have an issue with the fonts.

Adobe could render them as fonts or give you that option when publishing, but you would definitely start to see the spacing issues. Benefits to each.

Fonts could definitely be embedded in SWF's, not sure if Captivate did it or not since it greatly increases the file size.

[OzBassist]

Hi TLC, thanks for your comment. 

I'll agree that different browsers render text differently. Imagine if you could access the CSS to do a line-height adjustment based on browsers. Well OK you can access the CSS, and the DOM, but it's a bit of a fiddle.
I like your comment about giving you an option to use CDN-based fonts or rendered as bitmap fonts when publishing. I'd be happy to deal with spacing issues if I got crisper fonts.

And yeah, in Flash you could embed the fonts as symbols, but this was never an option in Captivate.

As far as 'greatly increases file size' goes, I wonder if a calculation where 50 slides which had 2 text boxes each, rendered as pixels at say 2kb each (that's 50*4 for a total of 200kb) would be any match for a font that typically weighs in at <100 KB per family. Given that one renders crisply (with the potential for some browser differences) and the other is blurred, I know where I'd be going.
So filesize is almost irrelevant, and if you start getting more slides, say with Multistate objects etc with coloured or gradient backgrounds, the rasterised text version is going to be far heavier than the live text version.

But don't take my word for it.

I think I'll do the experiment and post back here for a comparison.

[TLCMediaDesign]

I was just saying that when I worked in Flash, you would only embed the characters you were using, if you chose the option to embed the whole font family, the swf would get much larger, especially if you used a lot of different fonts.

[OzBassist]

Heck - I remember that!! What an efficient way to move!! I remember you could choose to embed the font without the special characters. Jeez that brings back some memories!
But I guess that's not gonna fly here, is it? Being able to use CDN fonts really is the answer, and your idea about having a choice is awesome!

[Paul Wilson CTDP]

For non-responsive projects, everything is converted to images, including your fonts (regardless of type). My solution to address the blurry font issue is to produce eLearning projects at resolutions similar to or greater than HD resolutions. the 1024 x 627 resolution is similar to your grandma's TV from the 70s. Lately, my standard project size is 1470 x 900. When you publish at this resolution with HTML Scaling turned on you get a much better result, not only with your text but images as well. Here is an example for you to see.
https://captivateteacher2020.s3.amazonaws.com/LSCon/index.html

[OzBassist]

Cheers, Paul.

Just checked that example out and it still looks blurry to me, and I wouldn't mind betting that on a large project, the file size is huge, particularly if you're using full screen images.
I know you're offering a workaround, but my clients just reject that quality out of hand. I can't justifiably tell them that "that's the way it is - it's not possible to get better", because they just show me other eLearning that has super sharp text. 

The only workaround I have found that delivers the quality without having to resort to the questionably effective Responsive layout, is the good old variable hack.

My question still remains "If we're having to use Typekit subscriptions to put the text on the slide in the first place,  why do we not have the benefit of a font that uses a content delivery network so as to allow us sharp text?"

99% of websites out there use fonts from a CDN, so I don't buy the "we can't do it" angle. The fact that Captivate delivers 'live' fonts while in Responsive mode and when text frames contain variables tells me that Adobe Captivate knows how to do it already. 

Why not give users a choice to either use crappy pixellated text, or clean sharp text if they prefer?

I was talking to an Adobe rep the other day about this problem, and he was genuinely surprised that this problem existed. Now he was either an incredibly good 'storyteller', or he was clearly out of touch with the marketplace. 

I can point to community posts stretching back as far as ten years or more that have described this exact topic, and still Adobe does nothing to fix it, despite having the proven ability at their fingertips.

I know I won't be popular with Adobe for this 'outburst', but, like yourself, have been an evangelist for the brand for many years. I started with Robodemo, Authorware and FutureSplash before Macromedia and Adobe got their hands on them. I worked tradeshows etc, just like you probably did, and in the case of a few products, was more deeply involved.

So what I'm saying is that I know the culture rather well. 

Despite the fact that I'm under contract to teach and support Captivate, this single issue has got me to a point where I'm ready to jump ship. 

I've seen you, Rod, Lieve and others champion Captivate to practically your last breath, and I'm sure Adobe appreciate that commitment.

For me, that commitment stops when clients reject work on the basis of nasty text.

If Adobe fix this problem once and for all, I'm happy to pilot the ship into the icy north.
But thanks anyway - I know you mean well. I apologise for using your post as a leaping-off point for a rant!

[Paul Wilson CTDP]

So you may have noticed that the text entry box on the first slide of my project used the font I was using elsewhere in the project. In this case, I was using a font from Google fonts (https://fonts.google.com). I edited my index.html to include getting the web font from Google for all variable or dynamic areas where the text isn't fixed. This capability might offer you a solution (combined with the variable hack). 

Here is the post that inspired me to go beyond the Adobe fonts: https://elearning.adobe.com/2017/03/using-custom-fonts-in-adobe-captivate/ but you still require to use the variable hack to get the nice crisp fonts you see in other eLearning authoring tools.

As you pointed out the other alternative is to design with responsive design. I think that might be what Adobe had in mind when introducing Adobe Fonts (Typekit) to Adobe Captivate. Remember that blank projects are a holdover from the SWF days. At some point, we will get a new release of Adobe Captivate and I suspect that all the old legacy stuff will simply be gone. 

[OzBassist]

Thanks, Paul. 

I've used that article as a basis for quite a few of my later projects.

I extended the JQuery and CSS so that I could use a predetermined naming convention to string split the object names and apply different styling.

I guess that there are solutions available if you look hard enough, but having to resort to hacks like this is really irritating. As always, I appreciate your informed and expert input, thank you.