https://bugs.documentfoundation.org/show_bug.cgi?id=103322
--- Comment #13 from Rachel Greenham <***@strangenoises.org> ---
For me it presents as a HiDPI bug, in that it's when desktop scaling is at
200%, 300%, text (any font) can be quite a reasonable editing size on screen
but show this poor positioning of glyphs within each word, making it
headache-inducing to look at, and actually a serious impediment to wanting to
use the software. Of course it was there before, HiDPI just amplifies it,
making it a problem at larger font sizes as displayed on screen.
As the worst problem is just the positioning of glyphs within words I looked
for the code that does that. It seems to be mostly in
vcl/source/gdi/CommonSalLayout.cxx, where the actual work is delegated to
Harfbuzz, which appears to work in integers, but I think at a very high
resolution (whatever a upem is). The values that then come out of that then
have a scale applied at double, rounded, and I suspect subject to more scaling
later, in particular with respect to the desktop scaling factor in HiDPI modes.
And that's probably where it's going wrong.
I had a play with trying to fix things locally in here and in
vcl/source/gdi/sallayout.cxx, changing all the glyph positioning code to use
doubles (and B2DPoint etc), including changing GlyphItem (sallayout.hxx) to use
those types for its positions, widths and offsets and rounding as necessary at
the edges of that, but I did rather get lost in the weeds, specifically, where
to find the edges of it, to minimise the disruption to the rest of the
codebase.
I suspect a fix can't really be confined like that, and it's probably
undesirable anyway. It looks like we'd probably want to make DeviceCoordinate a
double (as controlled in config_host/config_vcl.h.in showing this has been at
least partially prepared-for) and follow *everywhere* that leads, one such
place being the text functions in outdev.hxx of course.
Then final rounding to integers for actual pixels on screen would probably want
to happen in platform specific code. As absolutely late as possible, at the
moment of output, anyway. Then if and when there's a platform that takes double
coordinates that rounding simply doesn't have to happen there.
Regarding the suggestion of going via B2IPoint and friends as an intermediate
step towards B2DPoint and friends, I note that the B2I types are carefully
defined to use 32-bit ints (sal_Int32), whereas Point, Rectangle et al use long
(which let's face it *is* 64-bit almost everywhere that matters now) as does
much existing position-calculating code. So I'd worry that we'd be setting
ourselves up for a fight to resolve issues relating to that loss of range when
it's only needed as an intermediate step.
... All of which would be an absolutely gigantic changeset, no wonder no-one
who knows the code wants to do it! The more I poked around in this the more I
thought, "Oh God, no..." and "Can we *really* not localise this fix in
sallayout?" :-) But no, ultimately changing *all* the device coordinate code to
double is probably what has to happen one day.
Another thought I had, noticing that in OpenOffice.org Writer on a 4K screen of
course has no HiDPI awareness to speak of, so its user interface is unusable,
but zoom in on the text to an editing size and it looks fine - at 240% zoom you
would expect that, of course. Pretty much the same applies in LibreOffice
Writer if you set your desktop scaling to 100% on a 4K screen. So I wondered,
what if instead you just *not* apply desktop scaling on the document view
panes/frames whatever they're called here, and, um, *lie* on the user
interface, ie: multiply the user selected zoom by the desktop scaling factor?
:-)
--
You are receiving this mail because:
You are the assignee for the bug.