Currently we use integers and do lots of calculations and recalculations resulting in rounding errors which mess up with text spacing specially at low resolution screens.
We should switch to using floats to store glyph positions instead, which would make the rounding errors less visible. It would also allow us to benefit from sub-pixel positioning support in the graphics libraries we use.
*** Bug 105936 has been marked as a duplicate of this bug. ***
My Bug 105936 report was moved here. Probably the right place. But here I read "earliest affected version 126.96.36.199 release".
Not true on MacOSX: All LO versions up to 5.2.5 have no problems with glyphs positioning, all work excellent.
This problem begun only with LO 5.3, and there it is on MacOSX massively. I had to downgrade to LO 5.2.5. It's not possible to work with this broken font display.
(On Linux and Windows this might be different.)
The problem is HarfBuzz, which was only introduced in LO 5.3. I hope this gets fixed soon.
The underlying issue is as old as this code base, it started showing up on Mac because we no longer use Core Text (which uses floats for glyph positions) and share the same code on all platforms.
I assume the "float" problem lies in the Firefox code, since HarfBuzz is used in Firefox and Chrome also, which have no problems with glyph display. Will this "float" bug be fixed anywhere soon?
*** Bug 106495 has been marked as a duplicate of this bug. ***
Sorry, my commentary from February had an error. It should read:
"I assume the "float" problem lies in the LibreOffice code and not in HarfBuzz, since HarfBuzz is used in Firefox and Chrome also, which have no problems with accurate glyph display. Will this "float" bug of LibreOffice be fixed anywhere soon?"
No one is currently working on this, feel free to work on it yourself or recruit someone to work on it.
Caolan may have fixed this here.
tdf#107249 round ascent/descent/extleading on conversion to int
(In reply to Yousuf Philips (jay) from comment #8)
> Caolan may have fixed this here.
> tdf#107249 round ascent/descent/extleading on conversion to int
That is a different issue.