Font issues with Hungarian

[smileyhead]

Hey, I've translated Aseprite to Hungarian, and I have some feedback on how the font is displayed.

I've noticed that the Aseprite fonts are loaded from a sprite-sheet, instead of a more traditional font file. Had this not been the case, I would have tried to fix the issues myself and submit a PR, but as it is, I'm not sure how the characters are supposed to be laid out. Perhaps this could be changed in the future for easier fixes and wider character support?

My main issues are the following:

Firstly, several characters with diacritics do not share a common baseline with others, which makes them difficult to read: Comparison of the current state (left) and the proposed change (right).

Secondly, concerning my language specifically, several characters are currently missing from the font, which makes the programme use a fallback font only in those specific strings, which looks strange, is blurry, and gets cut off in several places: A pretty bad example of one such occurrence: The diacritics for ‘Visszavonási előzmények’ are completely cut off.

…also, missing characters in the smaller font do not get rendered at all: This should say ‘Szürkeárnyalatos’.

The following characters should be added to the font sheet or have their baseline adjusted: á/Á, é/É, í/Í, ó/Ó, ö/Ö, ő/Ő, ú/Ú, ü/Ü, ű/Ű, „, ”, », «, –, …

Aseprite and System version

• Aseprite version: 1.3.10.1-x64, Steam
• System: Windows 11, 22631.4317

[TakWolf]

Please try this theme as a temporary solution:

universal-pixel-theme-latin-v1.3.10.1-build-2.aseprite-extension https://github.com/TakWolf/aseprite-universal-pixel-theme/releases/tag/1.3.10.1-build-2

[TakWolf]

About bug text cut off supplement:

When the characters őŐ are missing in the font

miss őŐ: universal-pixel-theme-v1.3.10.1-build-1.aseprite-extension

have őŐ: universal-pixel-theme-latin-v1.3.10.1-build-2.aseprite-extension

[smileyhead]

Having an unofficial workaround is nice, but it won't solve the core problem. The built-in languages should be supported fully.

Also, one of the screenshots (which you've edited out since) showed that the Á character is displayed as A in the small font.

[dacap]

Hi @smileyhead,

concerning my language specifically, several characters are currently missing from the font, which makes the programme use a fallback font only in those specific strings, which looks strange, is blurry,

Could you give a try to the beta version? The blurry fallback should be fixed.

Anyway the fallback doesn't do a good job, we should add the missing characters, but I think the font is too small for some cases like "ő" which can be confused with "õ".

or have their baseline adjusted

Some chars have their baseline modified just to fit in the Aseprite font height of 7px and to make sense of the character:

We should see if we can add a baseline parameter to bitmap fonts in the future.

[smileyhead]

The beta version's approach is not ideal but definitely an improvement. Some issues I've noticed is that the ő character, like in your screenshots, gets crunched and misaligned into a mess of pixels (see below). I don't know how you got the second case in your images to appear, with the higher-resolution ő, but that one would definitely be preferable.

Also, the … character is displayed as .. instead:

The small font is missing a solution: The string Szürkeárnyalatos is still displayed as Sz rke rnyalatos:

Additionally, the upper-case Á is rendered as A for some reason:

My proposal would be the following: Increase the font size to 8 pixels tall, so that we can have a common baseline for all characters, whether or not there are diacritics. This would push every ‘regular’ character down by one pixel to conform to the ones that need more space:

I understand that this would increase the line height globally by one pixel too, so it could just be a fallback font for languages that need it, with English remaining with the base 7-pixel font.

Another solution would be to add a ‘proper’ fallback font that is used globally (not just in strings containing bad characters) when a language with unsupported characters is selected. Minecraft does this as well, and uses a slightly higher-resolution, but still pixelated font called Unifont. I believe this would still fit with the pixel aesthetic.