Jump to content
Eternal Lands Official Forums
Sign in to follow this  
Lachesis

Character Definition File

Recommended Posts

For simplifying the inclusion of new characters and for support of different fonts with different character sets, I'd like a font definition file that lists all fonts in the game and all contained characters. It should store the texture file and font id of each font, and the unicode value, in-texture position, height, width and possibly kerf of each character. The advantage would be getting these informations out of the code, the disadvantage additional initialisation work. What do you think about this?

 

If we'll implement it, it'd be neat to have a quick and space-efficient data structure to hold the mappings of unicode values to character properties. Something like a search tree compressing leaves with contiguous keys into arrays maybe? If we'd just use an array it'd waste space for huge gaps of unsupported characters. However the overall memory consumption of such an array probably won't ever exceed 8 MB** per font, and 32 KB* in near future.

 

With regards

Lachesis

 

---

*) 1024 entries for ASCII, Latin-1, Latin-Extended-A and Latin-Extended-B, 32 Byte properties per entry

**) 161K entries of full unicode range, 64 Byte properties per entry

Edited by Lachesis

Share this post


Link to post
Share on other sites

Has anyone tried using TTF rendering directly in OpenGL instead of bit mapped fonts? A quick search shows that there are TTF (or freetype) libraries for this. If so, then there are free unicode fonts with large character sets (eg, Code2000). Though this would entail some reinterpretation of the colour defining char values...

Share this post


Link to post
Share on other sites

I would favour this, however we'd someone to pick the suitable fonts for EL. Could you do this? The two fonts currently used would be nice, some space-saving yet well readable font for window texts and maybe some italic font that has a good support for mathematical symbols, especially in case the others don't. All libraries and fonts we use however have to allow redistribution under the ELC license. Additionally, I'd need the dev team's opinion on what method they'd prefer.

Share this post


Link to post
Share on other sites

There is a shortage of [L]GPL compliant unicode fonts. However, you could take a tip from Java's handling; form "virtual" fonts by mapping character ranges and styles to different physical fonts. This does save space, since, for example, western font variants (italic, gothic, etc) may not map to asian character sets (chinese doesn't have an italic form), so an "italic U0002000B" would map to a regular form glyph.

 

As per Java, final configuration can be left upto the installation, using fonts available on the system, rather than necessarily supplying the TTFs.

 

Just checked -- "Code 2000" is shareware, so not suitable. Need to look for UNICODE LGPL projects...

Share this post


Link to post
Share on other sites

Using the installed fonts is too complex, you never know what fonts someone has on his or her machine. Regarding your last post, I think it's best to stick with the texture mechanism. Anyway, I'll wait for further comments by the other developers before continuing implementation.

Share this post


Link to post
Share on other sites
I would favour this, however we'd someone to pick the suitable fonts for EL. Could you do this? The two fonts currently used would be nice, some space-saving yet well readable font for window texts and maybe some italic font that has a good support for mathematical symbols, especially in case the others don't. All libraries and fonts we use however have to allow redistribution under the ELC license. Additionally, I'd need the dev team's opinion on what method they'd prefer.

161209[/snapback]

 

The courier new styled font we are using at the moment is really not very practicable. I suggest using a more narrow font, especially for the chat window, since that one really takes a lot of space.

Share this post


Link to post
Share on other sites

The problem with using custom font bitmaps is that this method is limited wrt I18N. The font set has already been increased to include some accented characters for other western languages -- but what happens when the community demands support for cyrillic, greek, japanese, or (the biggy) chinese?

 

If I18N support is desired, then EL will have to switch to ttf/freetype and UTF-8 encoding. The colour codes (and other display directives) would be moved to an appropriate block of unicode values reserved for custom use.

 

Font configuration is an issue -- for pre-installated fonts I was refering to OS default fonts (well defined for Windows, maybe detectable or pre-req for linux?). But in anycase defining virtual fonts are the way to go (which would be defined in data files as per java).

 

Is I18N support an intended feature for EL? Should there be a developement thread for it? (I18N is far more that just providing textual translations!)

Share this post


Link to post
Share on other sites

We don't really support Unicode because the game wasn't meant to support it. It would require a LOT of server modification (and client as well).

We can 'cheat' and use some extended ASCII chars to support other languages, as we are doing it now. But other than that, not really.

As for the TTFs, it won't make a really big difference because it is hard to draw pixel accurate stuff in OpenGL (when you resize the text, that is). Besides, this is a game, not a text editor or document viewers.

If someone has too much time, they can implement other useful features, such as, for example, some magic spells.

Share this post


Link to post
Share on other sites

Thank you for your comments :P This feature in its current outline would not affect the server, it's only for displaying Unicode text. Furthermore, it'll be an addition, not a replacement to the current mechanisms (at least for now). It can be used for displaying strings read from XML files, that are encoded in UTF-8 by libXML, thus allowing new locales to be added without any interference with client code. You said you "cheat" in order to use extended ASCII. You probably agree that a true solution would be better than a hack. This proposition is a small jigsaw piece that opens a path to (but doesn't require) such a solution.

 

With regards

Lachesis

 

P.S. If anyone of you has additional comments, either on how to do this or on whether to do or not, please file them here. I doubt Entropy is the only one :)

Share this post


Link to post
Share on other sites

We never had the goal to support ANSI characters. We needed only ASCII.

Eventually, we implemneted some characters from other languages, but we don't plan to support asian or arabic characters.

For the encyclopedia, it's ok, but for the communication with other players, well, they can live without ANSI.

So if you feel like implementing it, go ahead. Can't hurt.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×