[HTML5] Improving font quality in TextFields


#1

Hi all,

we are experiencing issues with TextField in HTML5, hope someone can help:

  1. We feel the font-readability in HTML5 needs improvement. The texts are heavily pixelated / blurry. Are there ways to improve that? Maybe with something like better font antialiasing?

  2. The displayAsPassword-flag of a TextField seems not to be properly converted in swflite. TextFields in the fla have defined the behavior ‘password’, which later should at runtime set the displayAsPassword-flag to be true.

Tests for font readability

myTextField.antiAliasType = AntiAliasType.ADVANCED; // does not help

Hotfix for displayAsPassword

myTextField.displayAsPassword = true; // does work, but is not nice, should be imported from .fla / .swf

Thanks in advance,
Ruben


#2

Here is a current comparison of the fonts in Firefox and Chrome (HTML5) vs Flash. Pay attention espescially to the “Password” label. The checkbox “Automatically log in” currently uses a filter, so it should not be used for comparison.


#3

This might help!

(If you patch your local install, you will need to run openfl rebuild tools in order to rebuild our SWF processing tools with this change)

It looks like the password field from the SWF text was being ignored :blush:


#4

As for readability – I don’t know. I think this is generally an issue with canvas-based text.

We could do A.) manually drawn shapes, which could be more computationally expensive, and requires that we embed all the drawing data for each glyph. This is what Flash Player does.

B.) we could render glyphs out to a bitmap, and use that at runtime. That may or may not work well at multiple sizes, and also has a size cost.

We use webfonts on HTML5, because it improves our compatibility with adding your own webfonts outside of the OpenFL tools, but we do have fonts and have information to be able to perform processing on them normally, so there are potentially some clever options


#5

Hey,

thanks for the response! Did you paste a wrong link? At least it sounds like you are talking about a fix, but the repository you linked to has not had a change in 3 months and also does not sound like it’s related to swflite :slight_smile:

About text readability: Okay so it sounds like a better rendering quality could be achieved in theory. How do we proceed? We would prefer highest quality at the cost of performance, so A) but of course this might be different for other companies. Do you already have this on your roadmap? If not, can we discuss a budget so the team works on it?

Also, have you seen / worked with TextMesh Pro in Unity? It is able to use one single texture for fonts (i.e. bitmap approach) but render at unbelievable quality even when dramatically upscaling. It used to be an asset on the AssetStore but by now they included it as an official feature in Unity because it’s so good. I don’t know if there is a source code available anywhere but the tool is brilliant, something like this in OpenFL would be huge: https://assetstore.unity.com/packages/essentials/beta-projects/textmesh-pro-84126 (I am only referring to text sharpness, no need for the advanced stuff like shadowing etc.)

Thanks in advance,
Ruben


#6

Hah, failed copy/paste. I edited the original post. As for TextField, the big thing is that a different implementation has a different renderer, which requires rework in the TextField class. StaticText already uses shape drawing for text, dynamic text in Flash actually works the same, but we’re falling out to a font-driven approach for performance and compatibility

As for a font texture, we could implement OpenGL-based text rendering, if we came up with a good algorithm for how we pack the textures. Do we update the texture for every glyph we use? Do we generate all the glyphs at once? (which could fail on Chinese fonts, for example). That’s the bigger question there


#7

In theory it should be possible to generate a texture only for those glyphs that are embedded for runtime, correct? That is the approach that Flash / Animate use when editing a .fla file and deciding which glyphs are exported and available at runtime for the dynamic TextField.

Have you checked out the videos for TextMesh Pro? Just curious what you think…


#8

Well, maybe – we do this for static text fields (as they don’t change) but for dynamic text fields, you could textField.text = randomValue; at any time


#9

Sure, you could call textField.text = randomValue; at any time, but if the glyphs of randomValue had not been exported / embedded for runtime in the .fla / .swf file, those glyphs would not be visible in Flash. You have to select which glyphs you want to export in Animate CC. That means you have a predefined set of letters at compilation time that could be rendered into a bitmap / texture, with which you can render any texts that are set at runtime by rendering the characters one by one. If a character was not embedded, you omit it and it will be invisible. (This is the same behavior in Flash already). Do you know what I mean?


#10

Yep, I see what you mean. For users outside of Adobe Animate CC, I wonder if we should consider a similar system, or something different.


#11

Oh! One other thing that can help with blurry text, if you are on a high-DPI display, try <window allow-high-dpi="true" /> in your project.xml. By default, we do not allow high DPI canvases (because it’s four times bigger) for performance, but this can certainly help with sharper text


#12

Maybe a small tool could help to create font textures for users without Animate? Thanks for the tip, we tried <window allow-high-dpi="true" /> but it has no effect (testing on 1080p screens). Are there any chances you would be working on font rendering improvements soon? (not sure if you communicate future plans).

Having something similar to the font setting quality like this would be great. I am not sure about the algorithms they use to sharpen the characters, but they state they use 2 triangles per glyph. Our Unity team is using a 512x512 texture and the quality is impressive. It looks like they are constructing vector information from the font texture, so maybe that is something that would work in OpenFL, too: https://www.youtube.com/watch?v=MX_pM8QKTAc


#13

Hi, not sure if that’s any help but that video reminded me about “Distance Field Rendering” in Starling, it’s explained there : http://manual.starling-framework.org/en/#_distance_field_rendering


#14

Nice, thanks Matse! Looks like this is exactly the algorithm that was used by the MeshText Pro team. Is there a chance to have this included in OpenFL?


#15

First step would be deciding how to create the texture, but using a distance field like this may help with making it possible to generate one texture per glyph, rather than multiple textures for each size


#16

Okay so I was doing a bit of research on packing algorithms, and from what I read the simple approach of sorting the rectangles by size and then print them into the atlas works pretty well, especially in a case like fonts where no extreme rectangles are expected. A couple of algorithms are discussed / linked here:

I did not find a good solution how to calculate the TextureAtlas size automatically, but maybe the easiest would be to have this set in the project.xml for OpenFL manually, and OpenFL just gives a warning if the texture atlas is too big or too small for the chosen font size and embedded characters.


#17

@rewb0rn Did you find anything to improve the quality of your fonts?


#18

It might be interesting to use a different Canvas element, with the same CSS webfont, and to try basic canvas text to see if it looks the same, or if they can make it look better

https://www.w3schools.com/graphics/canvas_text.asp


#19

Hi,

@loudo: So far we have not made any changes to OpenFL itself to experiment with font quality. Other tips that were mentioned in this thread did not have an effect for us.

@singmajesty: Is that something we could and should change inside OpenFL for ourselves to see if it has an impact or how would we go and use CanvasText in OpenFL? My undestanding of HTML5 is limited so I probably need to ask a bit more on the details :slight_smile: Or is it an experiment we should do in pure Javascript to compare the quality without OpenFL?

Thanks in advance


#20

I’m currently trying the <window allow-high-dpi="true" /> trick. Don’t know the result yet, I need to borrow a phone :stuck_out_tongue:
@rewb0rn can you tell me on what devices/browser you have blurry fonts? For me, it seems blurry only on mobiles. Also, can you tell me the original size of your stage and the size of the screen your are testing. I would like to compare with my issues and my results to see if there are some good or bad practices.