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!