Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
CrazyFlasher opened this issue Mar 20, 2020 · 5 comments
Open

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

CrazyFlasher opened this issue Mar 20, 2020 · 5 comments

Comments

@CrazyFlasher
Copy link

No description provided.

@PrimaryFeather
Copy link
Contributor

Hey Anton!

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

@CrazyFlasher
Copy link
Author

CrazyFlasher commented Mar 22, 2020

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
Copy link

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
Copy link
Author

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

@PrimaryFeather
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants