LuisMayo / objection_engine

Library that turns comment chains into ace attorney scenes, used in several bots
MIT License
105 stars 20 forks source link

Add multi-lingual fonts #37

Closed Tadaboody closed 2 years ago

Tadaboody commented 3 years ago

Currently, the bot doesn't work with non-latin characters, this is because the font in the asset pack doesn't support them.

My example.py

from renderer import render_comment_list
from beans.comment import Comment
import anim

comments = [
    Comment(user_name = 'a', text_content='Hello שלום'),
]  *  1
render_comment_list(comments)

Using the default font:

image

Using stanger (first pixel font I found with hebrew)

image
LuisMayo commented 2 years ago

Hi! I'm so sorry this slipped past me.

Thanks for the report.

Currently the font supports:

It's lacking loads of font sets (Arabic, Hebrew, Kanji, both Chinese and Japanese).

The ideal solution would be a font that covers all this charsets while being Ace Attorney-like. Since this (probably) isn't posible, the solution may be making a switch code so Ace Attorney font is used if there are only supported characters, and another one is used if there are not supported ones.

So in summary we need

That'd ideal and fix this issue for once. Thanks

reibitto commented 2 years ago

The GBA Japanese font looks to be basically a scaled-down/pixelated MS ゴシック.

I don't know if this has to be 1 font across all languages or not. Typically you'd have "fallback" fonts depending on the language I think. Not sure if that's easy to support or not in this project.

If not, I guess there should be tools out there that can combine a bunch of fonts into one file?

exoego commented 2 years ago

For Japanese characters, Izumi Fonts are 16px x 16px bitmap font, which is a nostalgic pixel game-like. Maybe Ace Attorney-like? It support JIS Level-2 Kanji set, which covers little-used Kanjis. It is published as public domain. http://izumilib.web.fc2.com/izumi-bf/dl-jp.html

LuisMayo commented 2 years ago

I don't know if this has to be 1 font across all languages or not. Typically you'd have "fallback" fonts depending on the language I think. Not sure if that's easy to support or not in this project.

If not, I guess there should be tools out there that can combine a bunch of fonts into one file?

To be honest I don't really know how fonts work. I don't know if they can be merged like you suggest or if we should have several fonts to allow fallback. I know that in web programming you can just select loads of fonts and it will apply them in order, using the rest as fallbacks. In this project I'm not sure how easy is that.

Pillow (used for rendering) doesn't seem to support more than one font at a time: https://pillow.readthedocs.io/en/stable/reference/ImageDraw.html?highlight=text#PIL.ImageDraw.ImageDraw.text

We can emulate the font fallback behavior by having an array of fonts sorted by preference. Then, before rendering, we could check which is the first font to support the text we want to render

Both the current font, and the fonts provided by @Tadaboody and @exoego could be in that array. To make things even easier, the array doesn't even need to be hardcoded, it could just read all the fonts from a folder.

I'm positive about this method. What do you guys think?

LuisMayo commented 2 years ago

(For reference, this file is where the text rendering is being done in Objection Engine) https://github.com/LuisMayo/objection_engine/blob/main/beans/text.py

reibitto commented 2 years ago

That sounds reasonable to me. It seems unlikely to me that multiple very different languages would be used in the same Twitter thread anyway. So choosing just 1 font from the list will likely be fine. Besides, practically all CJK fonts support English as well.

The merging of fonts idea was a last resort hack. I'm pretty sure it's not feasible anyway if vector and bitmap fonts are being mixed.

LuisMayo commented 2 years ago

Even if multiple languages were used in the same thread the same code could be run for each message. I don't think it will end up being that computationally expensive. It should be tested though

I'll start working on this ASAP, as this is an accessibility issue

LuisMayo commented 2 years ago

Fixed by #45