Auto-wrap wraps incorrectly for fonts with wider bold characters

When using a font that has different normal and bold character widths, auto-wrap to window size does not account for the different bold character width when deciding where to wrap.

I use the JetBrains Mono font from https://www.jetbrains.com/lp/mono/
It comes with an ExtraBold variant that has different character widths for its regular and bold styles.

This is with the "Show Bold" font setting _not_ active https://imgur.com/i08TQsw

This is with the "Show Bold" font setting active https://imgur.com/UA4TRPY
Note here that it runs past the edge of the text rect.

The auto-wrap is just a convenience-thing^TM to help calculate the number of characters needed for a certain font to fit into a certain window width.

It assumes, I suppose, that the text is normally “normal” and thus the calculation is based on a non-bold font size.

If it assumed all bold then it would under-estimate for text which is usually not bold.

I don’t think this is a bug - you know that the wrapping occurs at a character count and not a pixel count. If the auto-wrap (which is something you would not frequently use) underestimates then just bump up the count a bit manually.

This isn't practical because lines nearly always have an arbitrary mixture of bold and non-bold on them at the same time. A line could be all bold or all non-bold or anything in between.

Wrapping correctly, whether using the bold setting or a non-monospace font (which apparently some players do), will require determining pixel widths based on line styles and actual text instead of a simple index. I like the simplicity of using a column width when it works, but it doesn't work for these cases.

What do you mean "works"?

MUD output is generally not right-justified, so if some lines wrap a bit earlier than they might have, it's no big deal.

Just make your width enough to allow for all-bold text.

"Works" here means wrapping at the player's desired place on the screen, not just at a fixed index that wanders around the screen with the wind direction. Wrapping at an index is a reasonable proxy if a given index always corresponds to a specific horizontal position. But it doesn't make sense to wrap at an index when the index does not correspond to a specific horizontal position. The human players want the text to fill no more than a certain amount of horizontal space. They don't actually care what index is involved. They care about where on the screen the wrapping happens.


The width difference is significant enough that that looks quite bad. In fact, it looks like something is broken, which is a bad impression to give. And players already don't have enough room on their screen for all of the things they want to display. Adding a bunch of dead space that makes the client look like something is broken and also takes away from the usable room for other things is not user-friendly.

How's the air quality these days by the way? Did you hear? Now _we're_ on fire. It never rains, but it pours!

Adding a bunch of dead space that makes the client look like something is broken and also takes away from the usable room for other things is not user-friendly.

This is the first time this has come up since the client was released in 1995. For this to look “broken” the user would have to enable display of bold (which I personally don’t do because a lot of so-called “bold” text looks weird if it is displayed in a bold font) and have a lot of discrepancies about the amount of bold text from line to line (otherwise the RH margin would not be noticeably out.

Bold text is already displayed in different colours, to make it stand out. Actually using a bold font is perhaps overkill for text. That’s why I don’t enable that option.

Anyway, it could conceivably wrap the lines at a calculated pixel width (based on the current font) however that would be somewhat slower than counting characters. Each line would have to be re-rendered (internally) character by character, as they arrived, to see if they reached the desired wrapping point.

Then you have the somewhat major issue of, what happens if someone alters their font mid-session? All the line wrapping will be out, since it was based on pixels and not character counts. So potentially all the (thousands of) lines would have to be re-wrapped, possibly breaking existing plugins which might be keeping track of things. For example, the bookmark feature bookmarks lines. What happens if the line wrapping changes?

To make this work smoothly and reliably sounds like a lot of work, for a problem that has only surfaced after the client was released 25 years ago.

OMFG! 25 years ago! That was before Facebook, YouTube, eBay, and so on. It seems a lifetime ago.

How’s the air quality these days by the way? Did you hear? Now we’re on fire. It never rains, but it pours!

Yes I did hear. We had major bushfires last Summer, and now you have them. But don’t worry, apparently the Earth is going to get cooler soon.

The air quality here is fine, we are just coming out of Winter, plus we have a fairly severe lockdown, so there aren’t many cars on the road.