Bug 144862 - Wiggling letter with window size of 1920 pixel width (72dpi) and zoom 140% (RSID?)
Summary: Wiggling letter with window size of 1920 pixel width (72dpi) and zoom 140% (R...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.0.1 rc
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.4.0
Keywords: bibisected, bisected, regression
: 88991 89558 108484 115939 116710 122626 123182 126216 128987 132705 133273 (view as bug list)
Depends on:
Blocks: Font-Rendering Kerning
  Show dependency treegraph
 
Reported: 2021-10-01 20:48 UTC by Telesto
Modified: 2022-08-21 21:49 UTC (History)
16 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Example file (8.64 KB, application/vnd.oasis.opendocument.text)
2021-10-01 20:48 UTC, Telesto
Details
Screencast (140.64 KB, video/mp4)
2021-10-01 20:49 UTC, Telesto
Details
Bibisect log (3.23 KB, text/plain)
2021-10-02 08:07 UTC, Telesto
Details
Kerning when enabling and disabling the Spellchecker (43.84 KB, video/mp4)
2021-12-01 17:16 UTC, Rafael Lima
Details
Sample ODS file to test with/without the spellchecker (14.56 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-12-01 19:50 UTC, Rafael Lima
Details
Screencast (157.64 KB, video/mp4)
2021-12-16 09:06 UTC, Telesto
Details
Video showing before/after patch (2.38 MB, video/mp4)
2022-01-17 18:07 UTC, Rafael Lima
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2021-10-01 20:48:28 UTC
Description:
Wiggling letter with window size of 1920 pixel width (72dpi) and zoom 140%

Steps to Reproduce:
1. Open the attached file 
2. Window size should be 1920 pixels width (possibly also at 72 dpi?)
3. Press "." after 'Bouw'
4. The 'w' spacing changes

Actual Results:
Spacing changes

Expected Results:
Same as prior to the point (.)


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: b60b6bfaafa1315e07108dba50f016975b619c59
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: en-US (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2021-10-01 20:48:41 UTC
Created attachment 175448 [details]
Example file
Comment 2 Telesto 2021-10-01 20:49:17 UTC
Created attachment 175449 [details]
Screencast
Comment 3 Telesto 2021-10-01 21:05:51 UTC
Also in 7.3 with safe-mode

Also in
Version: 7.0.0.0.alpha1+ (x64) (oldest bibisect 7.1 repro)
Build ID: 574c57090642347980d2395e1e183cc7b5c171ad
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: nl-NL
Calc: CL

but not in
Version: 7.0.0.0.beta1+ (x64) (bibisect 7.0 repro)
Build ID: 2891e91a513520d68ea2b8c59c14335861a15253
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 4 Telesto 2021-10-02 08:07:48 UTC
Created attachment 175453 [details]
Bibisect log

Bisected to
author	Caolán McNamara <caolanm@redhat.com>	2020-11-12 20:48:50 +0000
committer	Caolán McNamara <caolanm@redhat.com>	2020-11-20 21:07:56 +0100
commit 75b9109a2da35cf0f0914504145d84cf918c6af2 (patch)
tree ce444db75d6f2282e86d86c89c0cce66ab937c8d
parent 94ea1c89e959069aa7c735317470712012df2362 (diff)
weld TabBar

https://cgit.freedesktop.org/libreoffice/core/commit/?id=75b9109a2da35cf0f0914504145d84cf918c6af2
Comment 5 Telesto 2021-10-02 08:11:58 UTC
Well before someone things: the bibisect doesn't make sense. I think it does. However it's not showing the origin of the problem. Only uncovering an underlying issue (being present for a long time)

Inner border dropping out relative is also affected by the presence of the sidebar (also report by me, 5.0 range?)

So somehow the sidebar affecting the document canvas.
Comment 6 Telesto 2021-10-03 12:53:48 UTC
I'm would guessing some kind of rounding, as window size & zoomlevel matters..
https://opengrok.libreoffice.org/xref/core/vcl/source/outdev/text.cxx?r=7183b3ba#1356

Maybe also involving device coordinates? Else why would welding matter?
https://opengrok.libreoffice.org/xref/core/vcl/inc/ImplLayoutArgs.hxx?r=8381242c#38
Comment 7 Dieter 2021-11-02 13:46:56 UTC
I confirm it with

Version: 7.2.2.2 (x64) / LibreOffice Community
Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL
Comment 8 Caolán McNamara 2021-11-03 16:41:38 UTC
with sidebar off I can reproduce this in earliest Windows 4.3 bibisect version
Comment 9 Telesto 2021-11-14 14:15:42 UTC
The shifting letters while typing is apparently caused by screen DPI & zoomlevel.
Cases causing a shift on Linux Ubuntu:
96DPi * 85%
135DPi * 65%
188DPi * 65%
228DPi * 80%

Aside of the sidebar apparently being of influence.

Typing: WetenschapL + Space does trigger the same effect (L will move) [on Linux, and Mac but apparently not Windows..]
Comment 10 Telesto 2021-11-14 14:26:45 UTC
@Buovjaga
Would you mind to confirm/unconfirmed my hypothesis that shifting letters caused by combination of zoomfactor x screen DPI [and influenced by the sidebar].
Especially interesting is the the part of a higher DPI not solve the issue, only moving the problem to a different zoom factor.

The screen resolution doesn't seem to matter..

FWIW: I changed the screen DPI in appearance dialog of XFCE (but well probably every DE can do that or else commandline)

Another interesting fact: the issue is limited to the main document. No shifting in the comment box (bug 145648). I the wiggling & kerning issues are related in my perception..
Comment 11 Rafael Lima 2021-11-14 16:34:14 UTC
(In reply to Caolán McNamara from comment #8)
> with sidebar off I can reproduce this in earliest Windows 4.3 bibisect
> version

I can reproduce this using a 1920 x 1080 display and zoom at 140% when the sidebar is off.

With the sidebar on the issue does not happen. However, if the sidebar is on and you start resizing it, you'll notice the space between "u" and "w" alternating. Simply try resizing the sidebar and keep an eye on the text and you'll notice this weird behavior.
Comment 12 Telesto 2021-11-14 18:53:43 UTC
(In reply to Rafael Lima from comment #11)
> I can reproduce this using a 1920 x 1080 display and zoom at 140% when the
> sidebar is off.
> 
> With the sidebar on the issue does not happen. 

For me on Windows with 7.3
Sidebar expanded (decks visible) -> No movement
Sidebar collapsed -> Wiggle
Sidebar off -> wiggle

If you put a bullet (bulleted list) before the 'sentence' it doesn't wiggle. However if you copy the full sentence (incl. .) and past it again.. wiggle will start again at the end when adding a .

However looking GTK3 it wiggles always (in depend of sidebar) at 140% zoom and 135 DPI 

On my Macbook Air 11 inch inch 1366x768 screen at 135 it's dancing by on every key stroke. 

The comment box is free of wiggling madness| it doesn't appear to happen in a Textbox either.
Comment 13 Telesto 2021-11-15 09:02:04 UTC
FWIW
This is unrelated to:
* Page size (Letter/A4/A3)
* Page orientation (Portrait)

It is apparently affected by:
* Page margin. Change Left with -0,10 moves the issue.
* By going to Windowed mode (so not being in maximized mode) 

[Tested with Sidebar disabled]
Comment 14 Rafael Lima 2021-12-01 17:16:41 UTC
Created attachment 176633 [details]
Kerning when enabling and disabling the Spellchecker

Another interesting finding is that enabling/disabling the Spellchecker also affects kerning.

I attached a video showing the problem: note the spacing between "b" and "s" and also between "a", "ç" and "õ" in the word pointed at by the red arrow.

The text is using Arial.

Version: 7.2.3.2 / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Ubuntu package version: 1:7.2.3~rc2-0ubuntu0.21.10.1~lo1
Calc: threaded
Comment 15 Telesto 2021-12-01 18:02:41 UTC
(In reply to Rafael Lima from comment #14)
Any change to attach the file (or excerpt). As number of those issue can be bibisected; even though those bibisects mostly point to commits exposing the issue (instead being the true cause)
Comment 16 Rafael Lima 2021-12-01 19:50:44 UTC
Created attachment 176637 [details]
Sample ODS file to test with/without the spellchecker

(In reply to Telesto from comment #15)
> Any chance to attach the file (or excerpt).

Here is the ODS file I used in the video. I was using Zoom at 130%. My screen size is 1920 x 1080.
Comment 17 Telesto 2021-12-01 20:30:10 UTC
(In reply to Rafael Lima from comment #16)
> Created attachment 176637 [details]
> Sample ODS file to test with/without the spellchecker
> 
> (In reply to Telesto from comment #15)
> > Any chance to attach the file (or excerpt).
> 
> Here is the ODS file I used in the video. I was using Zoom at 130%. My
> screen size is 1920 x 1080.

Thanks, would you mind to create new report. The bug report here is about Writer. Initial I assumed it would be bug 145934. However this is occurring long long before that. Seen already in LibreOffice 3.5.0rc3
Comment 18 Caolán McNamara 2021-12-15 09:24:06 UTC
I can reproduce this before my commit of

https://git.libreoffice.org/core/commit/3769508f4952ca54cad7e9d33f4113b0d18066c9

tdf#145934 workaround rounding causing 'dancing characters'

but afterwards this example seems to be fixed.

verification of that would be nice
Comment 19 Buovjaga 2021-12-15 14:46:32 UTC
(In reply to Telesto from comment #1)
> Created attachment 175448 [details]
> Example file

Curiously, I can't repro with 1920 window width, but I *do* repro with half width.

Arch Linux 64-bit
Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 3769508f4952ca54cad7e9d33f4113b0d18066c9
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 15 December 2021
Comment 20 Telesto 2021-12-16 09:06:22 UTC
Created attachment 176957 [details]
Screencast

> > Created attachment 175448 [details]
> > Example file
> 
> Curiously, I can't repro with 1920 window width, but I *do* repro with half
> width.

See screencast (used the sample of bug 146233). The window is 838 pixels width. Happens at 86% 96% 99% 100%, 102% 200%, 220% zoom

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: deea3b7471c3dab0220eca6146c225a2d47681a2
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 21 Caolán McNamara 2021-12-18 20:14:17 UTC
There is this odd code in sw/source/core/txtnode/fntcache.cxx SwFntObj::DrawText at "In case of Pair Kerning the printer influence on the positioning grows" which overwrites the glyph positions for some reason that I can't quite fathom. I don't see what we want to do any of that of that block.
Comment 22 Caolán McNamara 2021-12-20 20:24:06 UTC
something like https://gerrit.libreoffice.org/c/core/+/127089 would/should make this not happen anymore though maybe there are then undesirable sideeffects I'm unaware of
Comment 23 Telesto 2021-12-20 21:04:11 UTC
(In reply to Caolán McNamara from comment #22)
> something like https://gerrit.libreoffice.org/c/core/+/127089 would/should
> make this not happen anymore though maybe there are then undesirable
> sideeffects I'm unaware of

Well maybe push it into master and lets see what happens? It's early in the 7.4 branch.. so enough time - +/- 6 months - to check/ inventorize the (possible) problems...  and decide if we're moving through or opt for a revert..
Comment 24 Caolán McNamara 2021-12-21 09:31:43 UTC
yeah, quite possibly.
Comment 25 Commit Notification 2021-12-22 09:13:17 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/39a57fa8c047227060915534e64c4e90affa4b1a

tdf#144862 explore alternatives to writer's on-screen glyph positioning

It will be available in 7.4.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.
Comment 26 Commit Notification 2021-12-22 12:04:11 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f22751cac9b81e5d7c5ad6b2e0a2eff21b683cad

Related tdf#144862 add some notes on various compromises

It will be available in 7.4.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.
Comment 27 Commit Notification 2022-01-13 19:26:44 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/935761709fb7629c8d23aa5dc8bfcbd2988f5bbf

tdf#144862 adjust positioning experimental options

It will be available in 7.4.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.
Comment 28 Caolán McNamara 2022-01-13 20:15:00 UTC
When this is included in the next daily there will be: tools, options, writer, view with "Classic", "Layout" and "Layout & Match Render" to explore.

Classic is the original heuristic described as https://wiki.openoffice.org/wiki/Writer/WYSIWYG where the example document here probably shifts position at 140%/120% when . is typed after Bouw

Layout is basically that heuristic turned off. At 90% the o and w in Bouw will probably appear to have too much space between them

and

Layout & Match Render is the new option to play with
Comment 29 Rafael Lima 2022-01-14 20:55:22 UTC
Thanks Caolan for the patches.

With the new option "Layout & Match render" this bug seems now FIXED.

Adding a "." after "bouw" no longer changes spacing. Also enabling/disabling the sidebar or changing its size does not affect char spacing.

I also tested other zoom factors and all was OK. Can someone else confirm this?

System info:
Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 45dee329c30f5548b0ba57cc1457c73f2fc870a3
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: threaded
Comment 30 Telesto 2022-01-17 15:49:58 UTC
Would call this one FIXED
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 52443996eff721e612ac4afc1eb1a53bb8a3e06f
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 31 Commit Notification 2022-01-17 16:24:13 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/bb495c6a2f00346698a041bce69a5a97effc79d7

tdf#144862 set default render mode to LayoutAndMatchRender

It will be available in 7.4.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.
Comment 32 Caolán McNamara 2022-01-17 16:34:57 UTC
ok, lets call this one fixed and work through the similar to see what more might need to be done
Comment 33 Rafael Lima 2022-01-17 18:07:09 UTC
Created attachment 177618 [details]
Video showing before/after patch

Here is a screencast showing before (Classic) and after (Layout & Match Render).

Notice that with the "Classic" option, when I drag the sidebar left/right, the horizontal spacing between characters change all the time.

Now with the "Layout & Match Render" option the horizontal spacing remains unchanged when the sidebar is resized.

This is a huge improvement in text rendering.

There's only one weird thing. I made this video using the daily build and all worked ok. However, when I compiled from source today, setting Layout & Match Render did not prevent horizontal spacing from changing. What might be causing this?
Comment 34 Buovjaga 2022-01-18 07:55:33 UTC
*** Bug 108484 has been marked as a duplicate of this bug. ***
Comment 35 Caolán McNamara 2022-01-18 20:54:15 UTC
(In reply to Rafael Lima from comment #33)
> There's only one weird thing. I made this video using the daily build and
> all worked ok. However, when I compiled from source today, setting Layout &
> Match Render did not prevent horizontal spacing from changing. What might be
> causing this?

What is the version info of your self build? use the clipboard thing in help, about and paste it in
Comment 36 Rafael Lima 2022-01-18 22:09:57 UTC
(In reply to Caolán McNamara from comment #35)
> What is the version info of your self build? use the clipboard thing in
> help, about and paste it in

Here is my self build info:

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: f1f4a2636dccfcc46a2c8c34457fe52e8729bbe8
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: CL
Comment 37 Dieter 2022-01-30 07:14:19 UTC
VERIFIED with

Version: 7.3.0.3 (x64) / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

Caolán, thanks for fixing it!
Comment 38 Aron Budea 2022-08-05 06:47:26 UTC
*** Bug 132705 has been marked as a duplicate of this bug. ***
Comment 39 Aron Budea 2022-08-05 07:00:13 UTC
*** Bug 128987 has been marked as a duplicate of this bug. ***
Comment 40 Aron Budea 2022-08-05 07:21:09 UTC
*** Bug 88991 has been marked as a duplicate of this bug. ***
Comment 41 Aron Budea 2022-08-05 23:53:34 UTC
*** Bug 89558 has been marked as a duplicate of this bug. ***
Comment 42 Aron Budea 2022-08-05 23:53:58 UTC
*** Bug 115939 has been marked as a duplicate of this bug. ***
Comment 43 Aron Budea 2022-08-05 23:54:19 UTC
*** Bug 116710 has been marked as a duplicate of this bug. ***
Comment 44 Aron Budea 2022-08-05 23:56:34 UTC
*** Bug 133273 has been marked as a duplicate of this bug. ***
Comment 45 V Stuart Foote 2022-08-11 19:32:47 UTC
Hey, what happened to the "GlyphPositioning" mode work? Not seeing it in the Tools -> Options -> LO Writer -> View panel on recent TB Windows builds of master against 7.5 -- and can't find in source cgit/gerrit/grok where it resides or got pared out.
Comment 46 Telesto 2022-08-12 09:00:17 UTC
(In reply to V Stuart Foote from comment #45)
> Hey, what happened to the "GlyphPositioning" mode work? Not seeing it in the
> Tools -> Options -> LO Writer -> View panel on recent TB Windows builds of
> master against 7.5 -- and can't find in source cgit/gerrit/grok where it
> resides or got pared out.

Those settings where temporal thing for testing purposes. The default got 'hardcoded' if I recall correctly. Most /all options you could pick suffered from the same problem.
Comment 47 Caolán McNamara 2022-08-12 09:57:14 UTC
yeah, dropped the ui and the options back in https://cgit.freedesktop.org/libreoffice/core/commit/?id=4ed26badfd6fd9190cb6e54078b41eb38cb37dca when concluding that "Classic" or any variant of heuristically (https://wiki.openoffice.org/wiki/Writer/WYSIWYG) mixing the high resolution paper glyph positions with screen resolution glyph positions is going to have some weirdness and not be stable as letters are added/removed to the line.

Better these days to try and retain the higher resolution positions all the way down to the final text render level and use the contemporary options typically available at that level (which weren't around when the writer scheme was originally implemented) to make that not look awful.
Comment 48 Gibtnix 2022-08-15 12:34:19 UTC
I noticed this fix from its link to bug 103322.
I tested this fix and it seems to significantly improve the font rendering. However, I think it only improves Writer while the other modules remain unchanged. Is this correct and if so, is the transfer to the other modules planned as well? In my opinion, bringing this improvement to Impress is really important.
Comment 49 Caolán McNamara 2022-08-15 14:33:53 UTC
> I tested this fix and it seems to significantly improve the font rendering.
> However, I think it only improves Writer while the other modules remain
> unchanged. Is this correct and if so, is the transfer to the other modules
> planned as well? In my opinion, bringing this improvement to Impress is
> really important.

Yeah, right now this is only for writer. That was because writer was the only module with the special hack to adjust the positions, so there was two things, the removal of the hack and then the extra adjustments to the rendering. As far as I know there isn't such a hack in the other modules, but it is possibly that making the associated rendering changes either universal or used by some of the other modules might be an improvement.

But I'd like to be sure that the problem in impress is something that is affected by this sort of stuff. Is it possible to file a bug with something reproducible for what you see in impress so I could see if I'm able to perceive a difference if we attempt that. (put me on cc on the new issue)
Comment 50 Telesto 2022-08-15 15:39:12 UTC
(In reply to Caolán McNamara from comment #49)
> > I tested this fix and it seems to significantly improve the font rendering.
> > However, I think it only improves Writer while the other modules remain
> > unchanged. Is this correct and if so, is the transfer to the other modules
> > planned as well? In my opinion, bringing this improvement to Impress is
> > really important.
> 
> Yeah, right now this is only for writer. That was because writer was the
> only module with the special hack to adjust the positions, so there was two
> things, the removal of the hack and then the extra adjustments to the
> rendering. As far as I know there isn't such a hack in the other modules,
> but it is possibly that making the associated rendering changes either
> universal or used by some of the other modules might be an improvement.

For the record: the rendering is significantly improved, but there are glitches when alignment is set to 'Justified'. It's covered by bug 61444 (in my interpretation; or I hijacked it.
Comment 51 Gibtnix 2022-08-16 15:15:43 UTC
(In reply to Caolán McNamara from comment #49)
> > I tested this fix and it seems to significantly improve the font rendering.
> > However, I think it only improves Writer while the other modules remain
> > unchanged. Is this correct and if so, is the transfer to the other modules
> > planned as well? In my opinion, bringing this improvement to Impress is
> > really important.
> 
> Yeah, right now this is only for writer. That was because writer was the
> only module with the special hack to adjust the positions, so there was two
> things, the removal of the hack and then the extra adjustments to the
> rendering. As far as I know there isn't such a hack in the other modules,
> but it is possibly that making the associated rendering changes either
> universal or used by some of the other modules might be an improvement.
> 
> But I'd like to be sure that the problem in impress is something that is
> affected by this sort of stuff. Is it possible to file a bug with something
> reproducible for what you see in impress so I could see if I'm able to
> perceive a difference if we attempt that. (put me on cc on the new issue)

For me the font rendering issues were pretty much the same across all LO programs. The best way to reproduce it is just to insert some dummy text (lorem ipsum), select a font and size (personally I prefer Arial 12 pt because it is most easily recognizable here, still the issue is the same with all fonts) and adjust the zoom level a bit. Zooming in and out will easily show neighbored 'wide' characters smearing into each other (e.g. 'm' and 'p') while smaller ones ('l' or 'i') show asymmetric/ugly spacings. Also, exporting the file to PDF and open it with a PDF viewer or alternatively in parallel do the same with MS Office easily shows the "untidy" font rendering of LO.

Thanks to you, these issues seems to be (mostly or completely?) fixed in Writer now. Still, in the other apps I still noticed them. In my opinion, fixing them in Impress is most important because here, the untidy rendering is not only shown to the user but also to the whole audience.

The reason is definitely not HarfBuzz (there are rumors about that coming from switching to HarfBuzz on macOS some time ago), I tested this by rendering some text with HarfBuzz using OpenCV. I supposed that it might have something to do with either the missing floating point glyph positioning (as discussed in the linked bug) or that LO places all characters instead of the whole string (e.g. a whole line of text). But the code is rather complex to analyze this further.

As your fix seems to resolve this in Writer, I would highly appreciate bringing it to the other LO programs as well. I hope this is possible.
Comment 52 Caolán McNamara 2022-08-16 19:29:39 UTC
(In reply to Gibtnix from comment #51)
> For me the font rendering issues were pretty much the same across all LO
> programs. The best way to reproduce it is just to insert some dummy text
> (lorem ipsum), select a font and size (personally I prefer Arial 12 pt
> because it is most easily recognizable here, still the issue is the same
> with all fonts) and adjust the zoom level a bit. Zooming in and out will
> easily show neighbored 'wide' characters smearing into each other (e.g. 'm'
> and 'p') while smaller ones ('l' or 'i') show asymmetric/ugly spacings.
> Also, exporting the file to PDF and open it with a PDF viewer or
> alternatively in parallel do the same with MS Office easily shows the
> "untidy" font rendering of LO.

Hmm, debugging a little in impress I think there might be a separate problem with VclProcessor2D::RenderTextSimpleOrDecoratedPortionPrimitive2D and the text positioning scaling done there before it even gets to the usual text rendering stuff so things are probably already gone wrong before it even gets as far as the underlying stuff touched under this bug. I think we need a new separate impress bug, my thinking is that we should pass the dx positions to vcl untouched and instead set up vcl to scale them rather than scale them in advance in drawinglayer, which would at least give vcl a chance to do something nice.
Comment 53 Caolán McNamara 2022-08-17 16:14:58 UTC
https://bugs.documentfoundation.org/show_bug.cgi?id=150462 for what I see in impress
Comment 54 Gibtnix 2022-08-17 18:05:59 UTC
Thanks for your analysis! Still besides Impress, the same rendering issues are also present in Draw and Calc (maybe Base as well?). Does the things you analyzed recently only relate to Impress or to Draw and Calc as well?
I will also add a comment to the new bug that it is *not* a duplicate of 103322.
Comment 55 Aron Budea 2022-08-20 20:53:30 UTC
*** Bug 123182 has been marked as a duplicate of this bug. ***
Comment 56 Aron Budea 2022-08-20 23:56:51 UTC
*** Bug 122626 has been marked as a duplicate of this bug. ***
Comment 57 Aron Budea 2022-08-20 23:57:39 UTC
*** Bug 126216 has been marked as a duplicate of this bug. ***