Tabs in BitmapText

Troubleshooting
1

I noticed tab stops in BitmapText don’t work as I would expect.

One issue is clearly a bug: The first explicitely set tab stop (BitmapText.setTabPosition()) is always skipped.
The other thing is that “normal” tabs just add a fixed spacing without aligning anything to columns.

I already fixed it… but is a fix even desired?
It could break things that rely on the current implementation.
Is the fixed spacing really undesired behaviour? What would you expect from tabs?

PS: Did you know that BitmapText can parse color codes like \#c0ffee# ? Pretty cool :slight_smile:

2

It would probably be nice to have tab stops working… but note: if you fix it in one place then there are more places to fix. For example, line width is calculated using its own loop that is separate from the loop that lays out the mesh.

Yes, it’s dumb. The whole set of classes is pretty bad at this point.

3

This is the current patch:

As far as I can tell, this is the only place where the StringBlock.getTabPosition Getter is called.
Line width looks correctly updated.

4

I think with this change that BitmapFont.getLineWidth() will return different results than BitmapText.

Edit: actually that was probably true anyway…may be no way around it.

5

I see… BitmapFont.getLineWidth() doesn’t care about tabs.
But I think the interface is clear on this. There’s no way to pass custom tab positions so a caller won’t expect that it returns accurate values when using tabs.

It could however use the default value for tabWidth. Right now a tab character adds 0 width.

6

I amended the last commit and added handling for tabs in BitmapFont.getLineWidth().

I moved the calculation of tab width to StringBlock and removed the getters for tab position/width which also removes the necessity to clone the tabPos array (it is cloned and overwritten in the setter and therefore can be shared across cloned instances - kinda copy-on-write semantics).
For reference regarding cloning: More weirdness when cloning BitmapText - #12 by pspeed

Are there any more potential issues?

7

Heheh… I was going to apply the other one but now I’ll have to review it again so give me a few days.

8

Oh sorry… Please take your time.

I pushed it to another branch so the old commit is still there for comparison.

9

21days later :stuck_out_tongue: Did you manage to find time already? or should I remind you later :slight_smile:

10

I have not looked yet. Have you?

Since this is a 3.2 change, I’m less concerned about it, I guess.

11

Well I tock a glance, and did notice that a tab is assumed to be 50, always. Question here is, if this should not instead be based on the tab with the used font has.

12

It’s been a while, so I’m not sure IIRC. You’re talking about BitmapFont.getLineWidth()?
I think the “problem” is that a BitmapFont has no associated tab width. You can only set the tab width in BitmapText.
This kinda makes sense. When you change the font properties (style, size etc.) of a text in a text processor, the tabs stay at the defined position too.
The tabs are more like a property of the paragraph.

13

Hm if you view them that way, yes then it makes sense