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
Created attachment 175448 [details] Example file
Created attachment 175449 [details] Screencast
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
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
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.
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
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
with sidebar off I can reproduce this in earliest Windows 4.3 bibisect version
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..]
@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..
(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.
(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.
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]
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
(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)
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.
(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
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
(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
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
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.
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
(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..
yeah, quite possibly.
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.
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.
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.
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
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
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
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.
ok, lets call this one fixed and work through the similar to see what more might need to be done
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?
*** Bug 108484 has been marked as a duplicate of this bug. ***
(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
(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
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!
*** Bug 132705 has been marked as a duplicate of this bug. ***
*** Bug 128987 has been marked as a duplicate of this bug. ***
*** Bug 88991 has been marked as a duplicate of this bug. ***
*** Bug 89558 has been marked as a duplicate of this bug. ***
*** Bug 115939 has been marked as a duplicate of this bug. ***
*** Bug 116710 has been marked as a duplicate of this bug. ***
*** Bug 133273 has been marked as a duplicate of this bug. ***
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.
(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.
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.
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.
> 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)
(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.
(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.
(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.
https://bugs.documentfoundation.org/show_bug.cgi?id=150462 for what I see in impress
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.
*** Bug 123182 has been marked as a duplicate of this bug. ***
*** Bug 122626 has been marked as a duplicate of this bug. ***
*** Bug 126216 has been marked as a duplicate of this bug. ***
So, does this patch involve a change to the internal precision of coordinates in LO modules, or is this only about font rendering?
(In reply to Eyal Rozenberg from comment #58) > So, does this patch involve a change to the internal precision of > coordinates in LO modules, or is this only about font rendering? What has been changed here: https://www.youtube.com/watch?v=mPYYsnGEkY0 or in slides: https://events.documentfoundation.org/media/libreoffice-conference-2022/submissions/B87ZBP/resources/LibreOfficeCon-2022-ResolutionI_2TieDK1.odp
In short, an app like Writer has always operated in units of twips (twenty in point, with 72 points in an inch, so 1440 units per inch) and draw/impress in a different but also fine grained unit. So the precision within modules was already fairly high and unchanged by the changes here. There are are issues around representing that on-screen, which is a target device of lower density than the ideal device that layout is done with. The font size used to render on screen is basically a different size than the one that would be used to render to paper/ideal-device. Usually at the small sizes used for screen rendering there is hinting applied which produces glyphs which are proportionally wider than if the large ideal glyphs were scaled down to screen sizes. So if you measure at the ideal size, and request to draw at those ideal positions, and scale everything down to render to screen then the smaller font used to render at those positions will render glyphs too wide to fit in the scaled down positions. Writer, uniquely, used to have a heuristic to try and overcome this for WYSIWYG on-screen rendering. That is gone now and writer doesn't try and second guess on-screen rendering. To compensate, the lower "final" vcl layer retains the scaled down glyph positioning internally as double now, instead of pixel snapped integers, and depending on platform will try various (unavailable at the time of the introduction of the heuristic) techniques to make that look ok when drawing to a screen device. Typically disabling hinting that affects glyph width and enabling subpixel positioning. Some other places here and there (like comment #52) prematurely converted "high" precision twip-unit coordinates to pixel-level units, disabling the possibility of transporting accurate positions to the final rendering stage.