Font width misscalculated

[cb88]

With the default font everything looks fine.

However if you switch to a different font that has a different width then it is broken. The more you type the more goes missing...

I am using IBM Plex Sans 12

The screenshot is of Vision but t also occurse in other text controls say the Query window for instance.

[cb88]

The text at the end should display think but it gets chopped off.

[waddlesplash]

It'd be nice, but not mandatory, if someone could look into this before beta2.

[pulkomandy]

This is a known issue with subpixel rendering. Basically, the BeAPI tells that it is equivalent to do either of these:

const char* str = "Hello World"

float a = StringWidth(str);
float b = 0;
for (auto i: str)
    b += StringWidth(i);

(or cut the string in any other way).

And likewise, that it is safe to split the string as you want and draw it piecewise with multiple successive calls to DrawString.

However, with subpixel, this does not work at all:

• The characters overwrite each other slightly when drawn as part of successive calls to DrawString
• The pen position is possibly not preserved correctly, especially if the view doing the drawing does not use the B_SUBPIXEL_PRECISE flag which allows the pen position to not be automatically rounded to pixels

BTextView relies on the BeAPI behavior and uses it a low to do only minimal redrawing of small parts of the text (one letter at a time when you type, for example).

The default fonts we use (both DejaVu and Noto) have strong hinting, which mostly forces them to stick to the pixel grid already. But whenever you use a font with weaker hinting, the issue becomes more easily visible.

Workaround: disable subpixel rendering, but then the text will look ugly.

I'm not sure we can fix this without removing this possibility from the API (which we probably have to do if we're going to support ligatures and other typography features anyway). Maybe enabling B_SUBPIXEL_PRECISE for BTextView will work well enough for beta2.

[jackburton]

Wasn't there a similar problem with Terminal, which was then fixed ? Ah right, but Terminal uses fixed-width fonts, so it's much simpler to fix.

[bitigchi]

Also present with a different weight of Noto Sans Display.

[pulkomandy]

No one is working on this and it is unlikely that a solution will be found in beta3. Moving out of the beta3 milestone.