I don’t know how to describe this, but vertical space for fonts in html5 is different from windows.
First one is on windows, bottom one is html5’s.
Is there any way to make them the same, without manually adjusting y position of every single textfield?
I use openfl version 5.1.3. I know it’s not the latest, and I’m willing to move if a later version fixed this problem. But I want to know the exact version first.
What browser are you using? Is this in Firefox, Chrome?
I was using Firefox. Speaking of which, I haven’t tried on anything else just yet. Will do that this evening.
I had the same issue on HTML5 when using non-system fonts (e.g. Arial Black instead of Arial).
My workaround was to use a system font that looks the closest to the font I wanted to use.
So I tried on chrome and it’s like this.
It seems each browser has its own way dealing with this.
I also take a look at Font class, it seems lime.text.Font, the class that openfl.text.Font inherits from, only supports desktop version only. and it’s just a mock up on every other platforms.
What should I do? I don’t want to use system fonts either.
There are two things we need to do:
1.) Change OpenFL to use encoded text metrics at compile-time. We can read this on native platforms (such as using the desktop tools), but in the browser, this information is unavailable. Encode and use that at runtime to help adjust the positioning
2.) (Possibly) We need to also update our HTML5 text rendering to be based on the alphabetic baseline (which should be consistent between browsers) rather than a top baseline, which (based on my research) is the top-most point of the font on Chrome, but is the top of the em-box on Firefox
So right now I edited TextEngine.hx to check for my font and give them proper ascender/descender/unitPer. It doesn’t look pretty, but it works for now. That doesn’t solve selected text and its highlight issue, but my game only has one place so far, so I can live with that.
I edited this part of TextEngine.hx:
inline function nextFormatRange ():Void {
if (rangeIndex < textFormatRanges.length - 1) {
rangeIndex++;
formatRange = textFormatRanges[rangeIndex];
currentFormat.__merge (formatRange.format);
#if (js && html5)
__context.font = getFont (currentFormat);
if (currentFormat.font == "Savior1")
{
ascent = (704 / 1024) * currentFormat.size;
descent = Math.abs(( -128 / 1024) * currentFormat.size);
leading = currentFormat.leading;
}
else if (currentFormat.font == "Antique Double Test")
{
ascent = (1716 / 2048) * currentFormat.size;
descent = Math.abs(( -418 / 2048) * currentFormat.size);
leading = currentFormat.leading;
}
else
{
ascent = currentFormat.size;
descent = currentFormat.size * 0.185;
leading = currentFormat.leading;
}
heightValue = ascent + descent + leading;
#elseif (lime_cffi)
I see that in latest version, TextEngine would read ascender/descender from TextFormat’s property, but I’m not using that version, so I hacked my way like this.
So yeah. I hope whoever in the future come and see this and get some idea. Wish you guys best.
I just merged an outstanding pull request (with some revisions) to improve font metrics.
Lime reads the font ascent, descent and units per EM for the font, and encodes it at compile-time for HTML5. OpenFL now looks for this information while rendering, allowing it to have much more accurate font handling.
The change also allows Font.registerFont () of a new font instance, which allows you to set the ascent/descent/unitsPerEM of a font yourself, and register it. This helps for fonts that weren’t available at compile-time, or if you really need to tweak it. Should go out in the next release:
Here’s a screenshot of the “TextMetrics” demo on a macOS browser before:
…and afterward:
It’s still not very precise. The worst situation is with iPhones & iPads atm (tested on Safari and Chrome).
Edit: Actually, there’s no difference between Firefox & Chrome on the previous image. I made another one with 1 px difference. But this may be related to the specifics of rendering… So the only big problem is iOS.
