Pioneer dev forum

yuyingchenk expressed an interest in a Chinese translation. There's a bunch of work required to make this happen.

yuyingchenk has started a Chinese Mandarin translation, so I have a few strings to work with. I set up GNU Unifont as the UI font for the cmn translation (a terrible font, but convenient for testing). I had to add the CJK Unified range to TextureFont, and expand the atlas size because there's a lot of characters, but that was enough to get here:



There's no way this is releasable in its current state - its actually quite unstable because of the size of the glyph atlas. But at least it shows we're not that far away!

So we have a few things to do. I think we'll need to do on-demand generation of the glyph atlas. Wildfire Games did an excellent write-up about the text renderer they built for 0 A.D. There's a lot to like about it (and its open-source, so I'll look into stealing it). But anyway, section 8 of that talks about their Unicode support.

We need to select a good-quality font that fits with the game. For Cyrillic there wasn't much out there so we had to go with Deja Vu, which isn't really the right style for the game but was all we had. I suspect we'll be in a similar situation here.

We have no support for combining characters/diacritics/ligatures/digraphs/etc. We've largely gotten away with it so far. I don't know if CJK text will require this. We have options that we've discussed (including handing off text layout to harfbuzz/pango), but I think we'll continue to ignore it until it comes up, and then deal with it in the lightest way we can.

I think that's actually about it for text display. There is another side to full CJK support though, which is input. I don't really know much about this, just the term "IME" really. I see that I have alternate on-screen keyboards and things like that available on my system, so it shouldn't be much effort to test and come up with something. Fortunately we don't do a lot of text input, so I'm hopeful that this won't be a significant problem.

Please post notes and helpful links here, I'm reading everything I can :)

robn wrote:So we have a few things to do. I think we'll need to do on-demand generation of the glyph atlas. Wildfire Games did an excellent write-up about the text renderer they built for 0 A.D. There's a lot to like about it (and its open-source, so I'll look into stealing it). But anyway, section 8 of that talks about their Unicode support.

On-demand generation is a must. That WF example seems to have smarter atlas packing too.
For mixed language rendering it would be a good idea to add fallback font selection, so if a glyph isn't found on font 1 look for it in font 2. Then you don't need something like unifont.

Luomu wrote:For mixed language rendering it would be a good idea to add fallback font selection, so if a glyph isn't found on font 1 look for it in font 2. Then you don't need something like unifont.

Yeah I was thinking that too. If we're doing it on-demand then it becomes trivial.

Hello Everyone,

Nice to see this discussion here, I will translate the rest of "core" parts and "missions" tonight when I back home (actually I am in Australia and work as a network engineer , so also glad to help with networking/VPN stuff if required :)

Have a good day,

Yingchen Yu

Chinese translation: 35% completed :)

Keep going tomorrow

I posted some links that might be useful: http://pioneerspacesim.net/forum/viewto ... 1982#p1982

Current progress:





This is the same screen with two different fonts: WenQuanYi Micro Hei (derived from Droid ie Android) and Zen Hei.I think I prefer Micro Hei, it has better metrics, but Zen Hei has better CJK coverage. But they're both pleasant fonts with compatible licenses, either would make good choices.

More importantly, this is being done on an updated font renderer that fills the glyph atlas on demand rather than pre-rendering. So there shouldn't be any particular concern about running out of space, nor any need to specify Unicode ranges (though I do still have per-language font choices, mostly because we need consistent metrics). I hope to have this submitted for merge in the next couple of days, it just needs a bit more testing and tidying.

So I've been chewing on it for the last couple of days and I think I know how I want to manage the whole mixed/fallback font thing.

What we want to do assign a specific font to each Unicode range. It means decoupling FontDescriptor and TextureFont, and I think splitting out the text renderer from the glyph atlas construction. The renderer will need to be able to use multiple texture atlases. The descriptor (which is the internal representation of the font .ini files) will need to list multiple fonts as well as options (eg outline).

We'll ask Freetype to produce all fonts with the same pixel sizes, rather like now. With careful selection of fonts we should be able to get metrics that complement each other fairly closely.

I think that will work. I'll get on it soon.

robn wrote:...
We'll ask Freetype to produce all fonts with the same pixel sizes, rather like now. With careful selection of fonts we should be able to get metrics that complement each other fairly closely.

I think that will work. I'll get on it soon.

TrueType fonts do an excellent job with their tasks. The problem is how they are treated in the program. Any font type can bring to any size. And just do, why not give this function to the OS? More precisely, there are libraries of DirectX and OpenGL. Their methods allow you to customize the font for any size and even disproportionate.

Navi1982 wrote:TrueType fonts do an excellent job with their tasks. The problem is how they are treated in the program. Any font type can bring to any size. And just do, why not give this function to the OS? More precisely, there are libraries of DirectX and OpenGL. Their methods allow you to customize the font for any size and even disproportionate.

You can scale fonts any which way you like, but if two fonts don't have similar metrics then they will look wrong next to each other, even if scaled to around the same size.

The OS font engines tend to support fonts in different ways. Different hinting engines, different concepts of DPI, different ideas about when and how antialising and subpixel rendering should be used. DirectX and OpenGL don't natively provide any font support. The most reliable way we've found is to directly use the same font engine (Freetype) on all platforms we support.

What I'm working on has nothing to do with changing the engine, merely the mechanism we use to get glyph bitmaps from it into OpenGL and thus onto the screen.