Supporting Asian fonts in BitmapFont

Discussions for core devs and contributors. Read only for normal forum members to keep the noise low

Supporting Asian fonts in BitmapFont

Postby jrenner » Sat Mar 01, 2014 2:31 am

I had an email exchange with a libgdx user a few weeks ago about the difficulty of using Asian Fonts with libgdx. I was informed that many Chinese developers choose Cocos2dx over libgdx because of this problem. Mobile gaming is huge in China, Taiwan and Korea (Even my english only game gets a fair number of users from these countries), so it would be a shame to not have libgdx usable in those markets. The core of the problem, as I understand it, is this:

1. Japanese and Chinese, on a per app basis, need a number of glyphs that could range from 100+ to 1000+. To support textfields properly (for example, allowing Chinese users to enter their name, which my contain rarely used characters), the number of glyphs can balloon to upwards of 10-20k.
(Korean does not make use of Chinese characters, so should be easier to handle, but I don't know any more than that)

2. Pre-rendered atlases of 10k+ glyphs is obviously out of the question.

I think the best way to solve this issue is to figure out a way to dynamically add glyph(s) to a font atlas as they are needed. The API should probably allow a String parameter, and every character in that String would then be added to the atlas.

There was once an issue filed regarding this, but it didn't seem to go anywhere. https://github.com/libgdx/libgdx/issues/1154
There was also a related issue in the external ecosystem: https://github.com/mattdesl/gdx-fontpack/issues/6

I imagine no one really has the time or inclination to take on this task right now. But I'd like to open up this topic for discussion, so that when someone does have time (maybe me in the future), we have a good idea of how it should be done.

I'll paste a comment nate made in one of the issues to get started:
It looks like BitmapFontData#getGlyph can be overridden to decide what to do when a glyph doesn't exist. BitmapFont was not designed for loading incrementally though, so there may be parts of the API that need to be adjusted. I'm afraid we don't have a lot of free time to implement this. We would most likely merge a PR as long as it doesn't negatively impact using BitmapFont with a texture/region. Ideally code to load incrementally would be separate from the current code, possibly as a BitmapFontData subclass.
Superior Tactics - tactical spaceship battles RTS
Google Play: https://play.google.com/store/apps/deta ... r.superior
jrenner
 
Posts: 520
Joined: Sun Apr 14, 2013 5:09 am

Re: Supporting Asian fonts in BitmapFont

Postby NateS » Wed Mar 05, 2014 12:02 am

I wrote UnicodeFont for Slick, the remnants of which are still used in Hiero. It uses Java 2D, so has limited usefulness for libgdx, but it does have an API for adding fonts on the fly.

UnicodeFont
Rendering is here: GlyphPage

The API is simple: glyphs to render are queued either explicitly or by rendering them. loadGlyphs(int maxGlyphsToLoad) is called in your game loop so they load incrementally. You see blanks until the glyphs load.

UnicodeFont used Java 2D (java.awt.font.GlyphVector) for text layout (eg combining marks and other fancy fonty stuff, but not RTL text), which is non-trivial. Can we get by for Japanese, Korean and Chinese without this?

For libgdx we probably want to use FreeType, so something like the FreeTypeFontGenerator we already have, but that can add to an existing font.
NateS
 
Posts: 1980
Joined: Fri Nov 12, 2010 11:08 am

Re: Supporting Asian fonts in BitmapFont

Postby jrenner » Wed Mar 05, 2014 1:41 am

Supporting RTL is not an issue for CJK, its only used sometimes in printing (books)
Superior Tactics - tactical spaceship battles RTS
Google Play: https://play.google.com/store/apps/deta ... r.superior
jrenner
 
Posts: 520
Joined: Sun Apr 14, 2013 5:09 am

Re: Supporting Asian fonts in BitmapFont

Postby NateS » Wed Mar 05, 2014 9:01 am

Yes but what about combining marks and any other nontrivial glyph layout?
NateS
 
Posts: 1980
Joined: Fri Nov 12, 2010 11:08 am

Re: Supporting Asian fonts in BitmapFont

Postby jrenner » Wed Mar 05, 2014 10:11 am

Sorry, I missed that part of the question.

I hadn't thought of that. Combining marks is something that's done in Japanese. I think, but can't be sure, it could be solved by just rendering all possible combinations. Probably under 100 glyphs for the two alphabets, not including the Chinese characters.

Chinese doesn't have combining marks.
Superior Tactics - tactical spaceship battles RTS
Google Play: https://play.google.com/store/apps/deta ... r.superior
jrenner
 
Posts: 520
Joined: Sun Apr 14, 2013 5:09 am

Re: Supporting Asian fonts in BitmapFont

Postby NateS » Wed Mar 05, 2014 11:16 am

I'd guess it would be better to render only the glyphs or glyphs + combining marks as needed. I don't know if Japanese combining marks are simple enough to just be drawn on top of each other. We need example text for some of the harder cases.

It would be great if there were some simple lib that we could use for layout. Poking around there are a few, but none that look simple.
NateS
 
Posts: 1980
Joined: Fri Nov 12, 2010 11:08 am

Re: Supporting Asian fonts in BitmapFont

Postby noblemaster » Wed Mar 12, 2014 1:50 pm

I am successfully using BitmapFont with English/German/etc., Korean, Japanese and Chinese. There are little less than 10'000 glyphs total which will fit on a 2048x2048 texture sheet unless you really need a large font size. There are about 6500 glyphs for 99.99% of Chinese and 2000 glyphs for Japanese. Plus about 500 glyphs for Korean. Then the rest for English, German, etc.

Pre-rendered atlases of 10k+ glyphs is obviously out of the question.

You are good unless you want to use something a lot larger than ~26pt Arial. It all fits on a 2048x2048 texture sheet.

Yes but what about combining marks and any other nontrivial glyph layout?

Not so sure what marks you are talking about? You obviously have to put everything onto the texture sheet but otherwise there isn't really much else to do there!? Maybe I am understanding the question wrong? What "combining marks"? You mean Hiragana & Katakana?

There is one gotcha for Chinese, Japanese & Korean though: no spaces! Line breaks will not happen where there is a space but can break anywhere. Shouldn't be rocket since to fix though (I have done it).
noblemaster
 
Posts: 121
Joined: Thu Dec 09, 2010 6:49 pm
Location: Tokyo, Japan

Re: Supporting Asian fonts in BitmapFont

Postby NateS » Wed Mar 12, 2014 3:06 pm

http://en.wikipedia.org/wiki/Combining_character
http://en.wikipedia.org/wiki/Complex_text_layout
I don't know for which languages it would not be feasible to use precomposed characters or to ignore complex layout.
NateS
 
Posts: 1980
Joined: Fri Nov 12, 2010 11:08 am

Re: Supporting Asian fonts in BitmapFont

Postby noblemaster » Wed Mar 12, 2014 4:56 pm

Not sure if you need it if you want to generate glyphs dynamically (e.g. via freetype)? However, all the combinations are already within unicode:

Unicode block for Hiragana:
http://en.wikipedia.org/wiki/Hiragana_% ... e_block%29

You will note that for へ the combinations are are included as well: べ ぺ

The same goes for German where the "ü" is included (no combinations are needed, i.e. you won't need to render u + ̈ separately as it is already a unicode char).

EDIT: just to be clear: the libGDX BitmapFont class already supports Korean, Japanese & Chinese (not sure about Arabic). The same way you would include "äöü..." you include the Chinese characters such as "行食..." and the Japanese characters "へべぺ..." and you are good to go.
noblemaster
 
Posts: 121
Joined: Thu Dec 09, 2010 6:49 pm
Location: Tokyo, Japan

Re: Supporting Asian fonts in BitmapFont

Postby mzechner » Fri Mar 14, 2014 6:53 pm

I implemented a full GL based rendering pipeline that support complex text layouts, including RTL. It was for Windows, so i had to dig into GDI and related APIs. It was the biggest programming pain in my life.

The solution consisted of an LRU glyph cache so memory requirements can't explode. This allowed for very easy use at the expense of some performance (texture switches etc.). As this was aimed at desktop systems, it wasn't a big deal.

I could imagine a system like this for mobile, provided we figure out a mobile friendly LRU. We could use Freetype as the basis for glyph rendering and getting layout information.

Whatever we do, it's a huge task.
mzechner
Site Admin
 
Posts: 4879
Joined: Sat Jul 10, 2010 3:50 pm

Next

Return to Libgdx Development

Who is online

Users browsing this forum: No registered users and 1 guest