Bug 43959 - Horizontal ruler moves into wrong direction and out of screen when changing zoom level
Summary: Horizontal ruler moves into wrong direction and out of screen when changing z...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
Keywords: needsDevEval
Depends on:
Blocks: Zoom Rulers
  Show dependency treegraph
Reported: 2011-12-19 12:50 UTC by OfficeUser
Modified: 2024-02-29 19:11 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:

bug (1.23 MB, video/x-msvideo)
2011-12-19 12:53 UTC, OfficeUser
ONLYOFFICE_ruler.webm (331.17 KB, application/octet-stream)
2024-02-29 18:11 UTC, OfficeUser

Note You need to log in before you can comment on or make changes to this bug.
Description OfficeUser 2011-12-19 12:50:03 UTC
OOo bug report: https://issues.apache.org/ooo/show_bug.cgi?id=92060

It would be nice to have this one fixed for LibreOffice.
Comment 1 OfficeUser 2011-12-19 12:53:11 UTC
Created attachment 54579 [details]
Comment 2 OfficeUser 2011-12-19 12:54:13 UTC Comment hidden (obsolete)
Comment 3 sasha.libreoffice 2012-04-30 05:31:07 UTC
Thanks for bugreport
Reproducible in 3.5.2 only on Windows (used 7 32 bit) 

Steps to reproduce:
0. Start Writer
1. Press Ctrl (and not release)
2. Scroll mouse wheel
Expected: page rule (on top of document, where page margins, paragraph indents, tabstops shown) placed in correct place
Actually: page moves in one direction and ruler in another and remains there.

On Windows: after releasing Ctrl ruler placed in correct place
On Linux: ruler placed in correct place automatically
Comment 4 OfficeUser 2012-08-13 17:42:54 UTC Comment hidden (no-value)
Comment 5 OfficeUser 2012-08-13 17:44:52 UTC
All platforms are affected.
Comment 6 OfficeUser 2014-03-12 19:06:15 UTC Comment hidden (no-value)
Comment 7 Joel Madero 2015-05-02 15:42:44 UTC Comment hidden (obsolete)
Comment 8 OfficeUser 2015-05-02 15:58:17 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2016-09-20 10:22:02 UTC Comment hidden (obsolete)
Comment 10 OfficeUser 2016-09-24 19:56:48 UTC Comment hidden (obsolete)
Comment 11 OfficeUser 2016-09-24 20:06:08 UTC
I'm rather sure that this bug has been introduced with the centered page view in OpenOffice.org.
Comment 12 Xisco Faulí 2016-09-28 15:53:47 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2018-06-20 02:48:26 UTC Comment hidden (obsolete)
Comment 14 OfficeUser 2018-06-26 18:30:15 UTC
Still reproducible with:

Build-ID: 8f48d515416608e3a835360314dac7e47fd0b821
CPU-Threads: 8; BS: Linux 4.4; UI-Render: Standard; VCL: gtk2; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
Comment 15 Aron Budea 2018-10-03 23:32:06 UTC
(In reply to Xisco Faulí from comment #12)
> Have you checked that this bug is already reproducible in Libreoffice 3.3?
It is indeed.
Comment 16 Telesto 2018-11-06 22:03:42 UTC
Pro forma.. still reproducible
Build ID: 6896f39ffd8a6c4b32b8f601a6a93678247456bd
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-11-05_22:40:18
Locale: nl-NL (nl_NL); Calc: CL
Comment 17 QA Administrators 2021-07-11 03:40:03 UTC Comment hidden (obsolete)
Comment 18 Aron Budea 2021-07-18 22:44:34 UTC
Still in LO Version: (4450137924eb8626a57283e1ab4f4ad62dd2d595) / Windows.
Comment 19 Tex2002ans 2023-10-24 06:10:39 UTC
Still reproduce this in:

Version: (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 20 Tex2002ans 2024-02-18 00:23:07 UTC
Still an issue on:

Version: (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

- - -

1. Hold CTRL.
2. Scroll mouse-wheel DOWN or UP.
   - Zooms document in or out.
3. Let go of CTRL.

Ruler now jerks into correct place.

- - -

If might feel a little better if ruler:

- updated every zoom level (Step 2)

instead of waiting for you to:

- release the CTRL button (Step 3).

(I just tested latest Word 365 (Version 2401, Build 17231.20236), and Step 2 is the way it works too.)

(Seems like Sasha in comment 3 says Linux works this way too, but not Windows?)

- - -

Side Note: Now that I recently upgraded to a 4K monitor, I'm zooming in+out more often.

And this is one of those tiny little visual bugs that, to me, just *feels* like a "lack of polish".
Comment 21 OfficeUser 2024-02-24 21:18:27 UTC
Added regression keyword because this behaviour has been introduced with multi-page view in Writer
Comment 22 Stéphane Guillou (stragu) 2024-02-29 14:28:35 UTC
Hossein, could this be an interesting easyHack?

Some pointers from Oliver Specht back in 2010, from https://bz.apache.org/ooo/show_bug.cgi?id=92060#c10:


gang65: IIRC the first step is the setting of the zoom value. Called in
The second step is the update of the position values of the rulers(left/right
margins, indents, tabs etc.). This is asynchronously called. Once the status of
these values is invalidated - at the time of the zoom change - the framework
calls the status update method - in SwView::StateTabWin() in
sw/source/ui/uiview/viewtab.cxx and then transports the new status to the ruler
in svx/source/dialog/svxruler.cxx in the methods SvxRuler::Update...( ... )

>This bug only appears when the whole ruler is visible.
This is because of the way the page is moved in the window. If the full page is
visible and the zoom is increased then the left margin moves to the left while
the ruler zoom change moves the ruler to the right. 
At higher zoom levels the left page margin moves to the right like the ruler does.
Comment 23 V Stuart Foote 2024-02-29 14:51:22 UTC
Affects both <Ctl>+<mouseWheel> zoom, and the <Ctrl>+<Shift>+<PgUp | PgDn> stepped zoom as implemented for bug 45705

Calculation and positioning of the menu bar is done after document canvas zoom completes. Seems timer based (following pause in zoom step) in that multiple zoom steps can be made, and at pause the horizontal ruler will recalculate and reposition.

Would there be a performance impact, or visual lag, to recalculate ruler scale and placement with each zoom step?
Comment 24 OfficeUser 2024-02-29 18:11:53 UTC
Created attachment 192873 [details]
Comment 25 OfficeUser 2024-02-29 18:13:21 UTC
> Would there be a performance impact, or visual lag, to recalculate ruler scale and placement with each zoom step?

This is what other ("polished") office software does while maintaining good performance. I have attached "ONLYOFFICE_ruler.webm".
Comment 26 V Stuart Foote 2024-02-29 19:11:50 UTC
(In reply to V Stuart Foote from comment #23)
> ...
> Calculation and positioning of the menu bar is done ...

s/menu bar/ruler bar/