Feature request: allow change char offsets

[Maligan]

Hello, soimy!
In first let me express my gratitude for your work!

Several otf/ttf fonts output incorrect char offsets, for example attached font have huge yoffset, all characters are shifted down. Usually, I run script which fix offsetY values on all char.

This is not a bug of your utility, this is font's peculiarity.

It will be cool if msdf-bmfont-xml can change offsetX / offsetY by custom value.

• Marvin.zip

[soimy]

I'll look into that next week. Maybe add both letter spacing & baseline offset modifiers. What do you think?

[Maligan]

I'm nether faced with baseline in my projects - and can't make useful comment.
Custom letter spacing may be useful in case font with large stroke for avoid char overlapping.

[soimy]

Just tested your font, looks great. I didn't find any offsetY issue for now @Maligan

[Maligan]

Wow, yesterday I was ready to swear that there is this problem.
But today I reassemble bitmap font and all is ok.

However I understand why I confused, if try to use custrom distance range then offsets appears:
msdf-bmfont -m 1024,1024 -r 8 Marvin.otf

There is one important note: in starling if text field use autoSize = TextFieldAutoSize.BOTH_DIRECTIONS then it trim offsets from text, but if autoSize = TextFieldAutoSize.NONE it doesn't do it.

[Maligan]

Khm... I try another my font - FiraSans.zip, and it produce bad y-offset:

With autoSize = TextFieldAutoSize.NONE:

With autoSize = TextFieldAutoSize.BOTH_DIRECTIONS offsets is trimmed in starling text filed:

[soimy]

From your image every thing looks fine to me. For the first image, what is your textField.horizontalAlign and textField.verticalAlign ? If I guess right, they are left and top.

[Maligan]

Sorry for my late reply, I restored spaces in my typography understanding.

As I read there are next font metrics:

In bmfont file format next two metrics are available:

• lineHeight (13)
• baseline (4)

What I called an excess yoffset is shoulders (14). It is no excess, I misunderstanded this moment.

---

Look on this case there are two starling text fields - top with autoSize = NONE (and height equals font's lineHeight), bottom with autoSize = BOTH_DIRECTIONS:

Simple toggle autoSize to NONE make starling ignore any free spaces around letters and gives such an unobvious result. Change chars offsetY in output file cut top shoulder. This allow place text field in UI independed their autoSize mode - font's shoulders will be ignored.

[soimy]

Great explanation on font metric graph! And I've tested the autoSize settings. You are right, when set to autoSize = BOTH_DIRECTIONS, textField's height is cropped to bodyHeight and lineGap(shoulder) is ignored.
For your case:

• fontSize: 42
• lineHeight: 50
• baseline: 32

Case 1: autoSize = NONE

Smallest Textfield's height is lineHeight (50), smaller height will remove all text render.

Case 2: autoSize = BOTH_DIRECTION

Textfield's height is fontSize+1 (43)

For packing efficiency all glyph is rendered and packed in smallest bounding-box, all font metrics is in bmfont .fnt file and rely on bitmap render framework to place them properly. There's nothing I can do for now. (Hard fix in rendered glyph is not a good approach, will break metrics computing)
I should let Daniel take a look at this.