Fuzzy text in HTML5 output on iPads and Android Tablets

I’m using Storyline 2 with Update 10. This is in regards to inserting text boxes on the stage and adding text, not for text in the notes, glossary or menu areas. Doing so, using any font (including the default Open Sans) in any example I create of a text box text results in fuzzy-looking text. In tests I’ve created, I was sure to use the default player setting for the Player size, set to “Lock player at optimal size” as opposed to the alternate “Scale player to fill browser window.” I’ve found that this makes no  difference.

I’ve read through several “fuzzy text” related forum posts and their replies, but nothing has gotten to the heart of this that I’ve found, anyways. I’m aware of what I’ve read a couple places - that “Objects aren't vectored in HTML5 output.” And I believe that traditional HTML text in a browser is effectively vector, unlike the text in Storyline. So does that saying apply to everything in Storyline?

I have a collection of tablet devices and iPads, and the results are all the same. My guess is that because most tablets have a DPR (device pixel ratio) of 2 or greater (aka high pixel density displays), the content we see in a tablet’s browser is stretched. I think that the HTML5 content is drawn using the canvas API, which is essentially a drawn bitmap of everything (including text). When that is shown on, say, an iPad whose Retina display naturally scales things up 2X, the content is actually stretched to 2X its width & height, which results in blurry text (or photos, etc.). Web design, in general, faces this problem on device displays: If you create a text in a graphic and then viewed that on an iPad, the same thing happens.

I do find that the text is relatively fine on computers (desktop/laptop) because they almost all have a DPR of 1 and do not stretch content in the browser, though there is a difference between Flash and HTML5 output (I accept that). I also know that this is separate from the usual anti-aliasing of text.

I don’t think this is necessarily a flaw in Storyline’s output, as any bitmap images on high pixel density displays are prone to this fuzzy/blurry induced effect. I’m guessing it’s mostly related to the fact that Storyline relies on the canvas API to draw everything for the browser. Alternatively, traditional web design relies on HTML (the browser and the HTML DOM) render text, which is always sharp at any size and on any device.

There might not be any real answer here, and it might be “it is what it is”, but I was curious what others have thought or have tried, or even if others have noticed this. And I was wondering if Articulate acknowledges this and if they recommend this be a “feature request” to have sharper text in HTML5 output for sharper display on devices.

Something else I have noticed is that if a text box includes any variable references, the entire text field appears to be handled difference because it’s no longer a static, bitmap-rendered text area. For example, including %myVariable% seems to force the text box to be fully dynamic, and then the text appears fairly crisp with dynamic font rendering. Can Articulate speak to how that text is displayed differently that simple, static text?

Lastly, my thought to work around this issue is to create a SL project that has a story size at 2X what I need, and insert all items at 2X the size (and use twice the pt size for fonts), then set the player to “Scale player to fill browser window.” A test I’d done actually achieved really good results, with the text appearing twice as sharp. This is that same concept that web designers use to show photos in a crisper fashion for iPad users. Of course, some shortcomings of this approach mean that you cannot use any of the stock player UI, such as menu, notes, glossary, buttons in the bottom bar, etc. because they’ll appear at ½ size (really small), so you’d need to create any UI elements yourself.

Besides this workaround, it really seems like we have to accept the text in its fuzzy state on tablets. That is sad, because my designers and clients are all going to react negatively to the standard text and its fuzziness. But it’s also a really complex issues for the Articulate engineers to find a solution to.

Thanks for any feedback or thoughts!

6 Replies
Crystal Horn

Hey there, Scott!  Thank you so much for sharing your thoughts and experiences here in such an eloquent manner.  You put a lot of time into your post, so I would like to recognize that effort.

We do have a report filed with our QA folks regarding the blurry output of text and images in HTML5 output.  I'm certain that your technical understanding of the matter is superior to mine, but I at least wanted to touch base with you.  The HTML5 experience is a focal point for us as we continue to look into how we can improve our software, so hearing feedback like this is empowering for us.  Accordingly, I'm going to add your discussion to that report so that we can update your discussion with any new information we have.

As for the difference in the variable-inclusive text boxes, I have a question put in to our development team which probably won't get answered until morning over here.  :)  But once I've got some more information to share, I'll pop in and update you!

Scott L

Thanks, Crystal!

I've attached four images of text & image examples from me tests of creating a 2x Storyline file (where I createde the Story size at twice the width & height, used twice the font pt size, twice the image size, etc. in the 2x test). Two images from a 1x demo, and two from a 2x demo. These were done via screen grabs on my iPad Air.

This approach is probably a bit prohibitive to many, but at least it shows off a currently option for providing sharper visuals in SL 2.

Crystal Horn

Hey Scott- to return to the variable text difference:  Since fonts can’t be embedded in published output for variable text and are rendered by the browser at runtime using system fonts, they look better.  This is the same reason that variable references don’t use custom fonts.

As you mentioned before, the slide text we publish to HTML5 isn't vectored; instead it becomes raster images that get blurry when scaled.

You're workaround ties in to that last point...and how novel!  The 2x example you provided looks great, so thank you for dropping that idea in here as well!

Scott L

I don't think it's exactly a limitation of HTML5. And SL does create its own internally-created art as vectors in Flash. If you publish a project and change the settings so it scales, or just view the Flash *.SWF directly, you can see that shapes, text, etc. are all still vectors and look great as you size the file up and down. But it's (the lack of vectoring in HTML5) based on a technology choice to use a well-supported browser feature called the canvas API.

Canvas is a way of drawing bitmap artwork in the browser that is very well-supported, and allows for adding tons of functionality via JavaScript. It's challenging to do from scratch, and Articulate's developers probably had their work cut out for them to "convert" what you insert lay out, and add triggers to in the Storyline authoring environment to both A) a Flash version and also B) an HTML5 canvas version.

Flash is of course vector-based (except for the bitmap photos & videos you might add), but canvas is bitmap-based, not vector based. Consider canvas a sort of Flash alternative that will play on mobile devices, because it's very "web safe" whereas Flash is a plugin and not allowed on devices. Canvas is probably a good way to draw all of our Storyline layouts in the browser and have all of the JavaScript functionality be maintained to mimic the Flash experience. And once images/bitmaps are created for use in Canvas, there's no adjusting their size without the fuzzy side-effect.

However, with regards to vectors, there is a web-based vector format called SVG (scalable vector graphics). If SVG were used instead of canvas to render our Storyline ideas in the browser, perhaps things would look nice (like they do in Flash on desktop computers). But I'm willing to guess that relying on SVG has limitations that using canvas doesn't. That being said, I have seen some web apps that draw all their visuals with SVG and it feels very "app like" and works great in mobile browsers.

I suppose a good question would be: Could the Storyline HTML5 output be re-engineered to use SVG, and maintain all of its functionality and cross-browser support? And that is probably a really big challenge, may have limitations or simply not be possible. I'm pretty sure this could never happen.

I think it would be interesting if there was a publish option to check to "Render Storyline's output at 2X", so that they would look sharper on high density displays.