Text width is calculated incorrectly when highpdi is enabled in Love 12.0

modcos commented 1 year ago

The text width is calculated incorrectly when highpdi is enabled. Here are the examples I tested with the default font:

print(font:getWidth('a')) -- 7
print(font:getWidth(string.byte('a'))) -- 8

local rasterizer = love.font.newRasterizer()
print(math.floor(rasterizer:getGlyphData('a'):getAdvance() / love.window.getDPIScale() + 0.5)) -- 8 (7.6 float)

And an example of another mistake:

print(font:getKerning('f', 'f')) -- 0 (Ensure the kerning is zero)

love.graphics.print(font:getWidth('ffff'), 0, 0) -- 18
love.graphics.print(font:getWidth('f'), 0, 10) -- 4

In computeGlyphPositions function string 'ffff' splits into 'ff' pairs, so when calculating the width love code calculates and rounds the value for a pair of characters like floorf((glyphpos.x_advance >> 6) / dpiScales[0] + 0.5f). That's why there is a difference if you calculate each character individually.

slime73 commented 1 year ago

In the first example I believe 7 is more correct than 8 - the text shaper (Harfbuzz) produces an un-rounded value of 7.2. GlyphData:getAdvance and the other variant of Font:getWidth don't go through the text shaper.

I'll do more investigation when I have more time but it's possible the end result to fix this issue will be using the (new) text shaper in more places as well as making APIs to encourage people to use it rather than going behind its back and trying to calculate things manually.

modcos commented 1 year ago

Thanks for the reply. I want to implement ui for text input, text selection and moving the cursor through the text. I don't know if love has a function that can return the character and the position of the character, relative to a given width (from the beginning of the text).

text_offset

Here's an example of what I use glyph data for. For the same reason, I only use getting the size for a single character.

I'm sorry if I don't explain well and make mistakes in the text. I do not speak English very well.

slime73 commented 1 year ago

I don't know if love has a function that can return the character and the position of the character, relative to a given width (from the beginning of the text).

It doesn't yet, but it's planned for 12.0. :)

modcos commented 1 year ago

I figured out the reason why 'ffff' splits into 'ff' pairs in Harfbuzz.

"This is the result of ligature glyph substitutions. OpenType spec recommends that Standard Ligatures be applied by default, that's exactly what Harfbuzz is doing."

Here's more information: https://stackoverflow.com/questions/62552451/why-harfbuzz-shape-2-single-char-into-one-glyph https://harfbuzz.github.io/shaping-opentype-features.html

modcos commented 1 year ago

I found another strange behavior:

local font = love.graphics.getFont()
local _, wrapped = font:getWrap('Приветff', 1000)
print(#wrapped) -- 2
local _, wrapped = font:getWrap('Приветfff', 1000)
print(#wrapped) -- 1

slime73 commented 1 year ago

I found another strange behavior:

Just documenting this here for the future since I haven't figured out the right solution yet: this is caused by the HarfbuzzShaper::computeWordWrapIndex code using harfbuzz' cluster API to get back the original codepoint indices for a string when determining where to wrap, without accounting for clusters that are the result of multiple codepoint characters combined into one glyph (like the ff in the above code). The trouble is that harfbuzz doesn't have anything I can find to easily determine the last codepoint index in a cluster, only the first...