Created attachment 141731 [details]
Ambiguous where the cursor actually is when inside italic text
I originally discovered this while working on a composition in Writer 188.8.131.52, but it is still present in 184.108.40.206 and probably applies outside of Writer as well.
When document text is italic, under certain conditions it can become ambiguous where the cursor actually *is* within the text. See attachment for the example that affects me currently -- due to the displayed size of the text here, it is ambiguous whether the cursor is located before or after the space between two words. (For comparison, at a higher zoom level there is absolutely no doubt.)
Although this is literally a cosmetic issue, it's surprisingly intrusive to my workflow -- i.e. every time I move the cursor somewhere and start editing, I belatedly realize the cursor was one character off from "where it should be" and likewise was whatever edit I juts made. I have to stop, go back, and make a fix.
This could be alleviated if the cursor is displayed using the same angle (normal or italic) as the surrounding text.
I sometimes have the same problems. So I would support your proposal. But let's also ask design-team.
Would be really nice. Looking through the web I found GetCaretMetrics() but not a setter method. And nothing similar on Linux. Caloan, any technical showstopper?
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6hhea.html documents that there is a Truetype feature in the hhea table caretSlopeRise, caretSlopeRun, caretOffset (and italicAngle in the post table) Checking Caladea-Italic as a random italic font I see it has these values set, so it looks like we could pull the correct slant to use for the cursor out of the font directly (like we do for ascent/descent). Looks initially plausible that we could do something like this.
References for Harfbuzz https://github.com/harfbuzz/harfbuzz/blob/master/src/hb-ot-hhea-table.hh and MSDN https://docs.microsoft.com/en-us/typography/opentype/spec/hhea
*** Bug 140694 has been marked as a duplicate of this bug. ***