Feature request: allow change char offsets
Maligan opened this issue · comments
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.
I'll look into that next week. Maybe add both letter spacing
& baseline offset
modifiers. What do you think?
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.
Just tested your font, looks great. I didn't find any offsetY
issue for now @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.
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:
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
.
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.
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.