orxFontGen with mono fonts - padding issue

sausage

I am having an issue with orxFontGen setting the size of a character, but making the character itself too small and the rest being padding even though 0 is specified.

Using a mono font I get the following result with these parameters:

-t char.txt -s 40 --font "d.ttf" -o fontout -m -p 0




Which is technically correct. The dimensions between one character an the next is 40 pixels, but I have no padding, yet there is padding.

sausage

I fiddled with the values on line 464 of the source code and added 15 pixels to both dimensions as a trial:

eResult = FT_Set_Pixel_Sizes(sstFontGen.pstFontFace, (FT_UInt)orxF2U(sstFontGen.vCharacterSize.fX + 15) - 2, (FT_UInt)orxF2U(sstFontGen.vCharacterSize.fY + 15) - 2) ? orxSTATUS_FAILURE : orxSTATUS_SUCCESS;

And got this result:





Which is the result I am expecting from the tool. From debugging the source, I think all the calculated values from orxFontGen are correct, but I think that the conversion inside freetype is wrong.

Here are some parameters of interest at the point of line 464:

sstFontGen.vCharacterSize.fX: 40
sstFontGen.vCharacterSize.fY: 40
sstFontGen.fPadding: 0
sstFontGen.fFontScale: 0.0416666679

sstFontGen.pstFontFace.available_sizes: 0x0
sstFontGen.pstFontFace.bbox.xMin: -23
sstFontGen.pstFontFace.bbox.yMin: -120
sstFontGen.pstFontFace.bbox.xMax: 521
sstFontGen.pstFontFace.bbox.yMax: 840

sstFontGen.pstFontFace.units_per_EM: 1100
sstFontGen.pstFontFace.ascender: 800
sstFontGen.pstFontFace.descender: 200
sstFontGen.pstFontFace.underline_position: -155
sstFontGen.pstFontFace.max_advance_height: 600
sstFontGen.pstFontFace.max_advance_width: 520
sstFontGen.pstFontFace.height: 600

I did wonder if fFontScale was the culprit, but changing it at this point in the code had no effect.

sausage

To eliminate the possibility of a bug in the current freetype, I compiled up the latest version of freetype under extern and recompiled orxFontGen using the new includes and lib. But no change to the output.

Hopefully all this helps to pin point if there is an issue. I know the source is old for this tool, but I am pretty sure the fix is quite small.

sausage

After another couple of hours at this... I'm probably at the conclusion that there's probably nothing wrong at all. After looking at the font in fontforge and inspecting the headroom, baseline on the heights (mono widths become the same as the height), perhaps the output is not so unreasonable.

And I can adjust the mono widths and spacings manually in the ini anyway.

:unsure:

iarwain

I'm afraid some fonts are just designed this way. However I can add a parameter to compensate for that. Either a negative padding value or an "oversize" one?
I'd request for a bigger size and put it in the actual size. So if you were to ask for a size 40 + oversize 5, I'd actually request a 45 size but try to fit it in a 40 one.
What do you think?

sausage

Yeah, I took a journey into the internals of fonts, seeing several different types of ascent, etc etc.... it's a science all of it's own.

I do like the idea of allowing a negative padding value as a way of compensating. Might be the cleanest?

I did notice looking at the source that the scaling value is stored in the struct, but isn't used? Anyway just mentioning out of interest.

iarwain

I liked the negative padding as well, but to be consistent, that would mean that you'd need to ask for a size 45 padding -5, to get something that fits in 40 with 5 of oversize, which might be a bit confusing. What do you think?

And yep, the font scaling is an history artefact, before using TrueType2, I was using stb_truetype which was using it. I shall remove it next time I touch that file.

sausage

Yep I am totally happy to go with what you recommend. It'll be a nice feature to freshen up the tool.

iarwain

Would you mind adding an issue on bitbucket for me?