# Improving BMfont

## Recommended Posts

legolas558    122
I am writing down the following suggested improvements for BMfont, grouped in 'current version' and 'future version' Current version improvements
• add "<?xml version="1.0"?>" to XML file start
• specify somewhere in the info tag the TGA filename (e.g. fontfile_00.tga)
• specify the 'size' attribute before the 'face' attribute in the text FNT file(this may help reading through scanf-based C functions)
• attribute-less XML format, some XML parser comes unhandy with attributes. A full XML tree approach would be better. I suggest each attribute being a tag subchild and removing the <autoclosed /> tag style
• raw 8/16/24bit output of font data, instead of a TGA one (less important)
Future version improvements
• make BMfont OS-independent using freetype
• a command-line tool for 1-step conversion between fonts and (FNT, TGA|RAW) sets
The above are only suggestions, I am not pretending nothing but since the program is not yet open-source, I can't do better! To: Andreas Feel free to comment/criticize/absorb the above ideas
[Edited by - legolas558 on March 30, 2006 6:00:34 AM]

##### Share on other sites
WitchLord    4677
Thanks for the suggestions. I'll take note of them for a future time when I get the chance to work on BMFont.

• add "<?xml version="1.0"?>" to XML file start - OK. I'll do this

• specify somewhere in the info tag the TGA filename (e.g. fontfile_00.tga) - I don't see much use for this, but I suppose I could add a new tag for the texture file names

• specify the 'size' attribute before the 'face' attribute in the text FNT file(this may help reading through scanf-based C functions) - This just don't make sense. Why would the order of the attributes make a difference for scanf? Could you show me an example?

• attribute-less XML format, some XML parser comes unhandy with attributes. A full XML tree approach would be better. I suggest each attribute being a tag subchild and removing the <autoclosed /> tag style - I don't agree with this. If your XML parser can't handle attributes, you should consider exchanging it for another. It's not difficult to implement in your own XML parser. Or if you prefer to use a 3rd party library then TinyXML is an excellent one.

• raw 8/16/24bit output of font data, instead of a TGA one (less important) - Why do you want the raw data? And why can't you take it from the TGA file?

• make BMfont OS-independent using freetype - Perhaps I'll do this someday, but it would require considerable work.

• a command-line tool for 1-step conversion between fonts and (FNT, TGA|RAW) sets - This makes sense. I'll see if I can do this.

##### Share on other sites
legolas558    122
Quote:
 Original post by WitchLordspecify somewhere in the info tag the TGA filename (e.g. fontfile_00.tga) - I don't see much use for this, but I suppose I could add a new tag for the texture file names

I think it is useful to allow using only the FNT file as the main specification file; parsing the proper field(s) would allow the program to load the associated bitmap files

Quote:
 specify the 'size' attribute before the 'face' attribute in the text FNT file(this may help reading through scanf-based C functions) - This just don't make sense. Why would the order of the attributes make a difference for scanf? Could you show me an example?

It is just for optimization, however it is not critically important. Here is the example, about retrieving only the charset size information.

FILE *f;int charset_size;// Optimized versionfscanf(f, "info size=%d", &charset_size);// Current versionchar useless_buffer[100];fscanf(f, "info face=\"%[A-Za-z ]\" size=%d", useless_buffer, &charset_size);

Quote:
 attribute-less XML format, some XML parser comes unhandy with attributes. A full XML tree approach would be better. I suggest each attribute being a tag subchild and removing the tag style - I don't agree with this. If your XML parser can't handle attributes, you should consider exchanging it for another. It's not difficult to implement in your own XML parser. Or if you prefer to use a 3rd party library then TinyXML is an excellent one.
Mmmh..you're right, indeed. However I think I will implement it myself.
Quote:
 raw 8/16/24bit output of font data, instead of a TGA one (less important) - Why do you want the raw data? And why can't you take it from the TGA file?

Let's suppose I do not want to implement TGA files...I think it maybe easy to directly read the data from an 8bit uncompressed TGA...however I should have to use TGA in some way if I cannot get the raw data.
Quote:
 make BMfont OS-independent using freetype - Perhaps I'll do this someday, but it would require considerable work.

I don't know, however implementing freetype is enough easy...the most hard part would be to rewrite windows-related code
Quote:
 a command-line tool for 1-step conversion between fonts and (FNT, TGA|RAW) sets - This makes sense. I'll see if I can do this.

Simply great.

##### Share on other sites
WitchLord    4677
Well, you could determine the file names of the texture files by looking at the file name of the font descriptor file. But in either case, I think I'll just include an extra tag for specifying the texture file names as well.

The 'info' tag isn't really meant to be used by the applications for rendering the font, instead I suggest you use the lineHeight, or base attribute from the 'common' tag. Besides, what if someone wants to read the font face, but not the size?

The TGA file format is really quite simple, implementing a function for reading a TGA file is only about 80 lines of code. And TGA files are normally much more widely accepted by image applications than raw data.

Regards,
Andreas

##### Share on other sites
legolas558    122
Quote:
 Original post by WitchLordWell, you could determine the file names of the texture files by looking at the file name of the font descriptor file. But in either case, I think I'll just include an extra tag for specifying the texture file names as well.

...you're the boss, if you think that it is not worth, don't! [wink]
Quote:
 The 'info' tag isn't really meant to be used by the applications for rendering the font, instead I suggest you use the lineHeight, or base attribute from the 'common' tag. Besides, what if someone wants to read the font face, but not the size?

Now I got it! the base attribute is what I was looking for

Thank you for your support and excuse me for my almost useless talk

Best Regards

##### Share on other sites
WitchLord    4677
Thank you for your suggestions as well. Even though I do not use all of them, some are very valid, and I'll definitely implement them when I get the time.

Regards,
Andreas