search

Gamua / Starling-Framework

The Cross Platform Game Engine
http://www.starling-framework.org
Other
2.82k stars 821 forks source link

TextFormat leading doesn't affect last line's height #1072

Open CrazyFlasher opened 4 years ago

PrimaryFeather commented 4 years ago

Hey Anton!

Could you maybe add a small sample and screenshot so that it's easier for me to reproduce? Thanks!!

CrazyFlasher commented 4 years ago

Hi. Prestory: I have some issues with all related Apple (iOS, MacOS) products in Chrome browser and given font and Thailand language :) image Some of the symbols are too tall and do now fit. On is screen, I've set 50 to leading, but last line in this case (and the first line in other cases) are vertically cutted. This is a phrase used on screen:

สัญลักษณ์อักขระ
หลักของคุณ
ระหว่างรอบโบนัส
การหมุนฟรี

By the way, on Windows or Android - everything is fine.

Is there a way to add some padding or offset in case, when real height of the character is more than font size?

UPD: If textfield contains only 1 line, adding leading helps in this case

JohnBlackburne commented 4 years ago

Fonts are a known cause of incompatibilities between platforms for Flash/AIR apps. If you don’t embed fonts it uses system fonts which can lead to different output. This is especially an issue for languages like Chinese, where fonts might be too big to include. But it can happen in any language, including English – as a Mac user I have had many experiences of Flash games with broken text from developers who tested only on Windows.

I don’t know what the cause is but if you use an embedded font it should ensure similar output across platforms so might fix it, while giving your users a more consistent experience across platforms.

CrazyFlasher commented 4 years ago

I cannot use embedded fonts. So the only ugly workaround I found to add "\n" + text + "\n" to fix the issue visually

PrimaryFeather commented 4 years ago

As John said, this is probably one of the known compatibility / rendering problem of fonts in Flash/AIR. The thing is: if it's not a bitmap font, Starling doesn't do the font rendering itself. It just draws a Flash TextField into a texture. So if Flash/AIR does it in the wrong way, Starling will — and it looks like this is happening here.

However, you say you cannot use embedded fonts – but don't rule it out altogether. If you know at compile time exactly which glyphs are needed, you can also selectively embed those fonts, which will greatly reduce the memory requirements. Here is a quick sample of how that works, but you'll probably find more information about it online. Perhaps that's an option?