*** 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 5.2.2.2 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.

*** 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.

*** Bug 113665 has been marked as a duplicate of this bug. ***

Do we have a (compact) API subset that needs to be changed from int to double to start the change?

(In reply to Mike Kaganski from comment #11)
> Do we have a (compact) API subset that needs to be changed from int to
> double to start the change?

I’d start with the “Text functions” section in include/vcl/outdev.hxx and go down and up from there.

We will need to switch from tools::Point, tools::Rectangle etc. to basegfx::B2DPoint, basegfx::B2DRectangle, not just int to float/double. May be using basegfx::B2IPoint first since they are still int-based, so the first round would focus on the difference in semantics and API between tools and basegfx, then next round would tackle the actual floating pint conversion.

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? :-)

Another alternative to floating point, is to keep using integers but use a scale, so instead of shaping at 10 pixels and drawing at the coordinates we get, we shape at 10 * SCALE and shape ant coordinates / SCALE. Which is what many other libraries do, and I vaguely remember that we have something similar by may be we are not using it thoroughly. Worth investigating.

*** Bug 108484 has been marked as a duplicate of this bug. ***

Alexander Farrow committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/a39f2e1943c7092dd32bd1f4e480ee6da54a80e4%5E%21

tdf#103322 GlyphItem::m_aLinearPos use getX() instead of X()

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

I'm the reporter of bug 113665 which was marked as a duplicate of this bug.

I have tried the following daily builds but the problem described in bug 113665  is still present:
* libo-master64~2019-05-22_00.57.02_LibreOfficeDev_6.3.0.0.alpha1_Win_x64.msi
* libo-master64~2019-05-29_09.41.50_LibreOfficeDev_6.3.0.0.alpha1_Win_x64.msi
* master~2019-05-24_22.08.51_LibreOfficeDev_6.3.0.0.alpha1_Win_x64_en-US_de_ar_ja_ru_vec_qtz.msi
* master~2019-05-29_04.28.58_LibreOfficeDev_6.3.0.0.alpha1_Win_x64_en-US_de_ar_ja_ru_vec_qtz.msi

So, maybe that bug is actually not related to this bug?

(In reply to horus from comment #17)
> I'm the reporter of bug 113665 which was marked as a duplicate of this bug.
> 
> I have tried the following daily builds but the problem described in bug
> 113665  is still present:
> * libo-master64~2019-05-22_00.57.02_LibreOfficeDev_6.3.0.0.alpha1_Win_x64.msi
> * libo-master64~2019-05-29_09.41.50_LibreOfficeDev_6.3.0.0.alpha1_Win_x64.msi
> *
> master~2019-05-24_22.08.51_LibreOfficeDev_6.3.0.0.alpha1_Win_x64_en-
> US_de_ar_ja_ru_vec_qtz.msi
> *
> master~2019-05-29_04.28.58_LibreOfficeDev_6.3.0.0.alpha1_Win_x64_en-
> US_de_ar_ja_ru_vec_qtz.msi
> 
> So, maybe that bug is actually not related to this bug?

Please revisit after this report is marked RESOLVED FIXED

(In reply to horus from comment #17)
> So, maybe that bug is actually not related to this bug?

It remains the same, the commit in comment 16 is only a part [1] of what will be a major refactoring--functionally nothing has changed yet in composing what displays.

Hang in there!

=-ref-=
https://gerrit.libreoffice.org/#/c/70436/

(In reply to Buovjaga from comment #18)
> 
> Please revisit after this report is marked RESOLVED FIXED

OK

(In reply to V Stuart Foote from comment #19)
> 
> It remains the same, the commit in comment 16 is only a part [1] of what
> will be a major refactoring--functionally nothing has changed yet in
> composing what displays.
> 
> Hang in there!

Alright

I also noticed this bug and finally found this thread... Two points from my side: First, I do not really understand how this is a desktop scaling / HiDPI bug? For me this would mean that at 100% desktop scaling this issue should not appear, or am I wrong here? I also tested two different Full HD screens and an old 1280x1024 screen that all use desktop scaling 100% (here I'm referring to the 100% scale that can be configured under Windows' screen properties) - and the issue is definitely visible. How can this happen if it is a HiDPI issue?

And then my second question, where I'm especially referring to Rachel's comment. I didn't look into the code, but if the whole coordinate stuff has to be migrated from int to float (or double), wouldn't it be a feasible approach to start with changing "only" any involved variable definition from int to float as a first step, without changing anything else? So we would only save our ints in float-valued variables (maybe introducing implicit cast warnings) but once done, the positioning code could be migrated step by step to fully support float?

Also hoping this issue gets fixed soon. Especially for Impress presentations it can really be a show stopper if the slides are not properly rendered...

Changing enhancement priority to 'high' since the number of people in CC is higher than 20

Created attachment 157431 [details]
Artifact when scrolling text

Adding this image to this bug because the one I opened depends on it. It shows an artifact that I get when I scroll a document: text gets deformed, with elongated characters, often unaligned. I think it's related to the problem with using integers rather than floating points for glyph positioning.

*** Bug 135445 has been marked as a duplicate of this bug. ***

I just posted a humble bounty on this in bountysource. Don't forget to claim it when it is solved!

(In reply to P. Rosquin from comment #29)
> I just posted a humble bounty on this in bountysource. Don't forget to claim
> it when it is solved!

I found it: https://www.bountysource.com/issues/93297186-use-floating-point-for-glyph-positioning-in-vcl

Hey it took me a while but I finally found this bug.

I experience this too, on Linux, and it's really debilitating - it's why I still run MS Office through Wine.

Is using floating point numbers going to be much of an issue?

The bug bounty on this has been raised to $250 USD:

https://www.bountysource.com/issues/93297186-use-floating-point-for-glyph-positioning-in-vcl

FYI, I'm inclined to blame:
fdo#52028: sw: let text formatting ignore RSID in automatic styles
A suprising regression from 062eaeffe7cb986255063bb9b0a5f3fb3fc8e34c:
The RSID text attributes that are inserted for every user-inserted text
cause the text formatting (SwAttrIter) to create a lot more text portions,
and the portion breaks make font kerning impossible.

based on bug 140161. The whole floating point topic might not solve the issue at all.

Created attachment 171468 [details]
Libre Calc, toggling between good and bad kerning

In Libre Calc, pressing F2 to edit text produces mostly-accurate kerning until editing mode is escaped. See attachment.
Libre build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff

Created attachment 171469 [details]
Libre Calc, toggling between good and bad kerning

Replacing poorly encoded gif.

*** Bug 135127 has been marked as a duplicate of this bug. ***

I noticed that using FreeType and HarfBuzz in OpenCV, it is possible to write strings with integer precision to images that look absolutely fine. Still, the whole string is put as a whole to the image, please refer to the OpenCV documentation for or details: https://docs.opencv.org/3.4/d9/dfa/classcv_1_1freetype_1_1FreeType2.html

Thus I thought that the reason for this ugly rendering might simply be that LibreOffice splits the whole strings into individual characters that are  written individually? For example, instead of writing "Hello world!" as a whole, LibreOffice puts all chars/glyphs "H", "e", "l", "l", "o", etc. one after another and recalculates the glyph position every time again in integer arithmetic only? Even if the latter was replaced by floats, I don't know if this even fixes the problem if HarfBuzz still uses integers for the initial rendering of the string... I don't know LibreOffice's code, still if FreeType / HarfBuzz is used correctly, rounding issues coming from integer instead of floating point accuracy should only influence the initial position of the string (i.e. a whole line of text), but not between characters / words.
I might be wrong, still this seems rather plausible to me such that a fix might be even easier than migrating all of LibreOffice's code to floats...

Created attachment 176857 [details]
"California" rendered in Liberation Serif at 12pt, 120% zoom on my screen

During some work on related Bug 142940, I came across a particularly bad example of the issues caused by this bug and wanted to add it as an example.

It's the single word "California" rendered in Liberation Serif at 12pt, 120% zoom on my screen. In this case, among many other issues, the renderer has chosen to place the 'r' and 'n' characters so close together that they actually overlap and appear to be an 'm'. It's a good illustration of how the lack of subpixel positioning for glyphs ruins any attempt at proper kerning.

Incidentally, the related bug is about the fact that disabling pair kerning ameliorates some of these problems. In this case, an extra pixel is placed between the 'r' and 'n', probably because kerning nudges them slightly closer together and creates situations where rounding will force them to overlap.

This specific image was created with a script I wrote to rerender a screenshot as virtual subpixels with the same RGB alignment as my actual screen, and then point upscaled three times. This allows users who may be on very different screens to see exactly what rendering decisions Libreoffice + Fontconfig is making for my screen.

A lot of issues associated with this enhancement should be fixed in 7.4 by Caolán's fix to bug 144862. Would be good to systematically retest these bugs, and if they're indeed fixed, mark as duplicates of that, and clean up the see also/duplicate/blocked bugs.

I agree with Aron’s comment above. I think folks are overemphasizing what kind of issues this change can fix. To be honest, I don’t expect it to fix any glaring issues any more, possibly only subtler sub-pixel positioning issues.

Created attachment 182345 [details]
Tahoma example text in LO 5.1, 7.1, and 7.4

I hope the attached image helps.  To me, at least, the kerning issue appears resolved in LO 7.4.  Previously, I had _mostly_ noticed kerning issues around punctuation in the Tahoma font, as you can see in the attached image of text taken from the same document as rendered in PDF (which pretty well shows something more than just a sub-pixel issue).  You can also see that 7.4 is nearly the same as 5.1 with some minor sub-pixel differences.  Kerning between letters (such as "fa") also appears better.

I looked at the previous mention of "California" in Liberation Sans, 12pt, 120% zoom, and it appears better as well in 7.4--although, that "rn" will likely always be a bit hard to discern.

This is not going to happen, and we have better fix in 7.4/7.5 already.

(In reply to خالد حسني from comment #43)
> and we have better fix in 7.4/7.5 already.

No, we don't. Can you explain what you mean and why you suddenly closed this bug?

(In reply to Eyal Rozenberg from comment #44)
> (In reply to خالد حسني from comment #43)
> > and we have better fix in 7.4/7.5 already.
> 
> No, we don't. Can you explain what you mean and why you suddenly closed this
> bug?

This bug is about subpixel glyph positioning, floating point coordinates is one way to fix it but it isn’t going to happen and we now have achieved this using something closer to what is described in comment 14.

(In reply to خالد حسني from comment #45)
> This bug is about subpixel glyph positioning, floating point coordinates is
> one way to fix it but it isn’t going to happen and we now have achieved this
> using something closer to what is described in comment 14.

Ah, so coordinates are now scaled fixed-point? Or is it just something being planned?

(In reply to Eyal Rozenberg from comment #46)
> (In reply to خالد حسني from comment #45)
> > This bug is about subpixel glyph positioning, floating point coordinates is
> > one way to fix it but it isn’t going to happen and we now have achieved this
> > using something closer to what is described in comment 14.
> 
> Ah, so coordinates are now scaled fixed-point? 

Yes, though I think this is done selectively (e.g. inside the documents but not for UI text, or something like that). There are quite a few bug reports that track this.

(In reply to خالد حسني from comment #47)

Ok, I see... well, in that case, I have to open a separate bug about positioning/coordinate precision that's not specific to text glyph positioning... some of you on the CC list may be interested in 152079, and sorry for the spam.

(In reply to خالد حسني from comment #45)

IIUC, this still forces integral pixels on the start/end of any text run, right? So only the middle of the text benefits from whatever library may provide. And the bounds would still suffer from the same problem? I might of course misunderstand how it is implemented.

(In reply to Mike Kaganski from comment #49)
> (In reply to خالد حسني from comment #45)
> 
> IIUC, this still forces integral pixels on the start/end of any text run,
> right? So only the middle of the text benefits from whatever library may
> provide. And the bounds would still suffer from the same problem? I might of
> course misunderstand how it is implemented.

I don’t know.

Re-opening as I’m working again on this and the results are encouraging so far.

(In reply to ⁨خالد حسني⁩ from comment #52)
> Re-opening as I’m working again on this and the results are encouraging so
> far.

Ok, so, now that this open again... are you sure that we should be using floating-point?

That is, if we're doing calculations on large-value positions, you'll get rounding errors even if you're doing them in a floating-point value. The benefit of floating-point is that the magnitude of the error is relative to the magnitude of the values you're working with (and thus errors at the origin of a coordinate grid will be smaller). But is that really what we need? (As opposed to, say, a  fixed-point with more bits before and after the decimal point?)

(In reply to Eyal Rozenberg from comment #53)
> (In reply to ⁨خالد حسني⁩ from comment #52)
> > Re-opening as I’m working again on this and the results are encouraging so
> > far.
> 
> Ok, so, now that this open again... are you sure that we should be using
> floating-point?
>...

Hey Eyal, stick to things you have a clue about. 

This is a rendering issue on the VCL canvas--think crispness in antialiasing, kerning, leading heights, and proper support for sub-pixel rendering. 

Also, moving the core beyond integer calculations opens more standard graphics libraries. Which offers potential to move some of the VCL canvas onto a Skia surface--think accelerated compositor supporting vector objects. For example it would open up alternatives to Cairo and Poppler for print and PDF parsing using pdfium libs.

So, floating point is good in general with some specific wins in font and text span renderings near term.

You go Khaled!

(In reply to V Stuart Foote from comment #54)
> Hey Eyal, stick to things you have a clue about. 

That's why my comment had the form of a question. That, and the apparently-contradicting direction of increasing fixed-point precision (e.g. bug 152079). Point taken about library compatibility though.

This is done, more or less now. We keep glyph coordinates as floating point inside VCL as much as we can and round only at API boundary, so API users that use map mode (a glorified scale factor) get less rounding as possiple (earlier we were rounding very early, so by the time the scale factor gets applied, we are already working with full pixels, which is was rather unfortunate for hipdi displays).

It improves things on hipdi displays, but not so much on lodpi ones. More to investigate, but that should be tracked separately.

(In reply to ⁨خالد حسني⁩ from comment #56)
> This is done, more or less now. We keep glyph coordinates as floating point
> inside VCL as much as we can and round only at API boundary, so API users
> that use map mode (a glorified scale factor) get less rounding as possiple
> (earlier we were rounding very early, so by the time the scale factor gets
> applied, we are already working with full pixels, which is was rather
> unfortunate for hipdi displays).
> 
> It improves things on hipdi displays, but not so much on lodpi ones. More to
> investigate, but that should be tracked separately.

Thanks, Khaled :-)

Still... is every API function/property which was integer-only before also available now with floating point? Or available now _only_ as floating point? If not, then will the dependent bugs be able to make use of the floating point coordinates?