msdf-bmfont-xml icon indicating copy to clipboard operation
msdf-bmfont-xml copied to clipboard

Metrics fixes

Open mattdesl opened this issue 6 years ago • 2 comments

Hey there,

I think it might be good to have a very robust test case for metrics that covers this module and also mdsf-bmfont. It seems like msdf-bmfont had some issues with alignment (https://github.com/Jam3/msdf-bmfont/pull/11) which means all fonts exported with it may be wrong (and perhaps also msdf-bmfont-xml, since it seemed like I was getting similar alignments there).

Keep up the awesome work in this module, by the way! :smile:

mattdesl avatar Mar 02 '18 22:03 mattdesl

Thanks for mention it. There are several commits ahead of Jam3/msdf-bmfont related on this issue like 437b2cb66276dc383cbf69510822294ea396db6c and 4a7686590611df9a0e1e66048e11790d03271a01 . I'm no expert at font metrics things, so if you found any metrics problems, please let me know, I'll try to fix.

soimy avatar Mar 15 '18 16:03 soimy

I also experienced metrics issues. When rendering the text, the bottom of the letters are getting below the line (for example the bottom of the 'g' character is cut). In my font example the lineHeight was reporting 33.6. It was looking right with a value of approximately 37. Using opentype.js.org, I checked the font properties:

  1. (os2.sTypoAscender- os2.sTypoDescender+ os2.sTypoLineGap) * fontSize / unitsPerEm = 33.5938
  2. (hhea.ascender - hhea.descender + hhea.lineGap) * fontSize / unitsPerEm = 37.5.

The actual code uses method 1. By observation, without really understanding the font metrics, I would say that taking the 3 properties from the "Horizontal Header table" instead of "OS/2 and Windows Metrics table" fixes the issue.

My test case was with the font Roboto-Regular.ttf, size 32.

jcmonnin avatar Mar 27 '19 20:03 jcmonnin