Hi all. I've spent the last two weeks writing an open-source Rust BMFont parser that works with text, XML, and binary BMFont formats.

The homepage is here: https://github.com/shampoofactory/bmfont_rs

However, I have a question that I need help with.

Based on the `Bitmap Font Generator - Documentation` my understanding is that the binary file is the de facto standard when it comes to defining the content and the other formats reflect this. For example, common::lineHeight is a size 2 unsigned integer, and not a string, a boolean, an elephant, or anything else.

However, I've noted that some tools, like Hiero (https://github.com/libgdx/libgdx/wiki/Hiero) produce output like this:

`info face="Arial Black" size=33 bold=0 italic=0 charset="" unicode=0 stretchH=100 smooth=1 aa=1 padding=0,0,0,1 spacing=-2,-2`

Here `spacing` is negative, whereas the binary format defines it as a size 1 unsigned integer. This line cannot be encoded into a valid BMFont binary info block.

Question: Is Hiero incorrect, or am I incorrect in my interpretation. If Heiro is incorrect, I think there is already a ticket about this, I can try and assist in submitting a patch. If I am incorrect, then how do I determine the parameter types for text format files?

@theshampoofactory I have used Hiero to create SDF font bitmap files. Usually you need to add some padding around any glyph to avoid that they mix together when you use them.
But that creates a problem, you are adding extra space between your letters, so your words are now not close enough. To avoid that, you use a negative spacing so

padding_left + padding_right + x_space = 0
padding_up + padding_down + y_space = 0

https://github.com/libgdx/libgdx/issues/5125​
“This is how padding is meant to work in Hiero. Use padding to add space around glyphs in the texture (which will affect layout). Use the X/Y advance fields to add space for laying out glyphs (which will not affect the texture). If you want to add space around glyphs in the texture but not affect layout, then use padding and add the same amount of negative X/Y advance. Eg, padding=2,2,2,2 and x=-4,y=-4.”

Thank you for the prompt feedback Gotanod. I did come across that ticket in my travels. My concern is that Hiero produces invalid BMFont output, in that it just doesn't obey the rules. My understanding, as stated above, is that negative spacing is not a thing in BMFont format. Hence the question at clarifying the format.

http://www.angelcode.com/products/bmfont/doc/file_format.html

Block type 1: info

field        size    type    pos    comment
fontSize     2       int     0     
bitField     1       bits    2      bit 0: smooth, bit 1: unicode, bit 2: italic, bit 3: bold, bit 4: fixedHeigth, bits 5-7: reserved
charSet      1       uint    3     
stretchH     2       uint    4     
aa           1       uint    6     
paddingUp    1       uint    7     
paddingRight 1       uint    8     
paddingDown  1       uint    9     
paddingLeft  1       uint    10    
spacingHoriz 1       uint    11    
spacingVert  1       uint    12    
outline      1       uint    13     added with version 2
fontName     n+1     string  14     null terminated string with length n

Spacing (horizontal/ vertical) is encoded as an unsigned char type. It can hold a value of 0 to 255. It cannot hold a negative value

Additional discussion here:

https://github.com/libgdx/libgdx/issues/5125​​

theshampoofactory said:
Hiero produces invalid BMFont output

Do you mean that angelcode's bmfont file format is the official standard used for Bitmap fonts? → In that case, Hiero does not follow the rules.

Or, do you mean that the product that is going to use the BMFonts follows the angelcode's bmfont file format? (like Godot engine) → In that case, Hiero fonts with negative spacing will not work or will not work as expected.

In my opinion, the file format, and its usage, must be agreed between who creates the file and who consumes it, nothing else.

@gotanod Hi again. I'll try to be clearer. Hiero is just an example, we can put it to one side.

Let me rephrase my question:

If we take http://www.angelcode.com/products/bmfont/doc/file_format.html​ then:

Are the text file parameter types defined by the binary standard, e.g. info::stretchH is an unsigned short (size: 2 uint). If not, how do we determine the parameter types?

I am the creator of BMFont and “inventor” of the file format used by BMFont. To my surprise BMFont and its format became quite popular, and since many different tools have been created which uses the format used by BMFont.

I claim no ownership of the format though, and Hiero and the other tools are free to do whatever they want.

http://www.angelcode.com/products/bmfont/doc/export_options.html​

I can't speak for Hiero, but in BMFont the spacing cannot be negative. The spacing is used to leave empty pixels between the glyphs in the texture to avoid color bleeding from one glyph to another when mipmapping is used. A negative value for spacing would mean that the glyphs are overlapping in the texture, which doesn't make sense to me.

Padding also can't be negative. The padding is used to add surrounding pixels to the glyphs in the texture that will be drawn together with the glyphs. This is used when the texture is post-processed to add pre-baked effects, e.g. blur or drop shadow. A negative value for padding would crop the glyphs.

theshampoofactory said:
Are the text file parameter types defined by the binary standard, e.g. info::stretchH is an unsigned short (size: 2 uint). If not, how do we determine the parameter types?

The binary file format is the most representative of the internal format used within BMFont, so you can use this to see the limit of the values that the text/xml format can contain.

@witchlord Thank you! That's helped me enormously. I was uncertain as to whether I'd correctly interpreted the format as written. Due to its popularity, I can make a note on my repo about Hiero's particular take on the BMFont format and how one might work around it.

On further reflection, the Hiero situation is a can of worms. Whilst unequivocal interoperability with different BMFont format applications would be a wonderful thing, changing a core mode of Hiero's operation and potentially breaking existing downstream applications would not. I can understand why its maintainers are reluctant to make changes.

I have one more question, but it's not that important. Would it be possible to re-upload BMFont version 1.9c as mentioned here:

https://www.gamedev.net/forums/topic/682933-bmfont-v19c/5314268/​

I would like to support BMFont format v1 and v2, but I cannot find any information on the mysterious v2 common block encoded field. In particular, its binary format details. I was hoping to pull the code apart to figure it out.

You can download the source code for version 1.9c here:

http://www.angelcode.com/products/bmfont/BMFont_source_1.9c.zip​

Regards,
Andreas

@witchlord Thank you again.