Bug 99928 - VIEWING Zooming during Print Preview on Writer should be centred on present view point
Summary: VIEWING Zooming during Print Preview on Writer should be centred on present v...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.6 all versions
Hardware: All All
: low minor
Assignee: Not Assigned
Keywords: bibisected, regression
Depends on:
Blocks: Zoom
  Show dependency treegraph
Reported: 2016-05-18 09:21 UTC by RGB
Modified: 2024-02-06 12:27 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

Quick example to follow the steps comented on the report (17.11 KB, application/vnd.oasis.opendocument.text)
2016-05-18 09:21 UTC, RGB
99928_patch.diff: my hack that works except when horizontal bar is added (1.93 KB, patch)
2021-07-13 15:39 UTC, Justin L

Note You need to log in before you can comment on or make changes to this bug.
Description RGB 2016-05-18 09:21:20 UTC
Created attachment 125141 [details]
Quick example to follow the steps comented on the report

1- Open the attached document and activate the page preview: the full page is presented

2- Zoom it to, say, 200% and centre the view on the →focus on← bold text

3- Zoom even more, like up to 400%

Result: the zoomed part of the page is the top left one, not the part chosen on the first zoom.

This is quite uncomfortable on many situations. For example, let's say I inserted a small image anchored "as character" and I want to see if it is well aligned with the paragraph baseline. If I start to zoom in on page preview the view is always centred on the top-left of the page so each time I need to increase the zoom I also need to scroll the page to find again the particular point of interest, something that becomes more and more difficult with bigger zooming factors.

Proposal: on page preview, the zoom should always be centred on the current viewpoint.
Comment 1 Cor Nouws 2016-05-18 10:52:14 UTC

thanks for filing I confirm this on a recent master build.
LO 3.3.0 behaves as you describe. So got wrecked somewhere in between.

Ciao - Cor
Comment 2 raal 2016-05-19 07:14:21 UTC
repro  Version:
Comment 3 raal 2016-05-25 20:57:19 UTC
 git bisect log
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327
# good: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4
git bisect good 369369915d3582924b3d01c9b01167268ed38f3b
# bad: [6fce03a944bf50e90cd31e2d559fe8705ccc993e] source-hash-47e4a33a6405eb1b5186027f55bd9cb99b0c1fe7
git bisect bad 6fce03a944bf50e90cd31e2d559fe8705ccc993e
# bad: [8a39227e344637eb7154a10ac825d211e64d584c] source-hash-f5080ebb7022c9f5d7d7fdca4fe9d19f9bb8cabf
git bisect bad 8a39227e344637eb7154a10ac825d211e64d584c
# bad: [e8bc60acad752e284db73fc4d8ad383ac055361c] source-hash-7e6e16ba6de2d3ef2b130d1ad5ffeabfdb37918e
git bisect bad e8bc60acad752e284db73fc4d8ad383ac055361c
# bad: [19b8950109d519c0dba847f94d5d166044c1db15] source-hash-ff9cca69744b54ca84d98476a9a969d1aa0ff2d3
git bisect bad 19b8950109d519c0dba847f94d5d166044c1db15
# good: [f23b0ac1f569b0e043ebc0d0fe08ec76ea23d656] source-hash-552ba413bc95b1a14638558d9436141825100c52
git bisect good f23b0ac1f569b0e043ebc0d0fe08ec76ea23d656
# bad: [f3986117cf91f1976749922e435915354389c4f1] source-hash-eab7e131ecebe4cdefcdcb1ad176bbdce83cb467
git bisect bad f3986117cf91f1976749922e435915354389c4f1
# good: [cef0750df9186e2523a1a2d1ddb4c1ddbb85c19d] source-hash-18c661f715a0b6850d30b374e5556dc14a377d2b
git bisect good cef0750df9186e2523a1a2d1ddb4c1ddbb85c19d
# first bad commit: [f3986117cf91f1976749922e435915354389c4f1] source-hash-eab7e131ecebe4cdefcdcb1ad176bbdce83cb467


Commits with "preview" in name. Noel, can this commits be relevant? Thanks
2012-04-03	Hori/Vert scrollbars in calc preview should be shown only when necessary	Noel Power	commit f194d18dfeceff104f9c5e500ea4dd94fa1b5b06 
2012-04-03	Revert "Hori scroll fix in Writer and Calc Print Preview" & add new patch	Noel Power commit d7b06ba7ec2c988e80c8ef14e2d9bfc2c29e2d24
Comment 4 Björn Michaelsen 2016-08-12 18:54:36 UTC
as per comment this was introduced with libreoffice 3.6 latest.
Comment 5 QA Administrators 2017-09-01 11:15:44 UTC Comment hidden (obsolete)
Comment 6 RGB 2017-09-01 12:37:37 UTC Comment hidden (obsolete)
Comment 7 Xisco Faulí 2017-09-13 16:52:45 UTC
Same range of commits as in bug 99332. Adding to see also
Comment 8 QA Administrators 2018-09-14 02:47:16 UTC Comment hidden (obsolete)
Comment 9 RGB 2018-09-14 07:31:08 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2019-09-15 02:47:31 UTC Comment hidden (obsolete)
Comment 11 RGB 2019-09-15 15:06:58 UTC
Problem still present in
Comment 12 Justin L 2021-07-13 15:38:27 UTC
(In reply to raal from comment #3)
> 2012-04-03  Revert "Hori scroll fix in Writer and Calc Print Preview" & add
> new patch   Noel Power commit d7b06ba7ec2c988e80c8ef14e2d9bfc2c29e2d24

Yup, this is the one.  Particularly calls to ShowVScrollbar and
-            pHScrollbar->Show( sal_True );
+            ShowHScrollbar( sal_True );

which start some recursive calls because it calls InvalidateBorder(), loses the rDocRect, and get everything reset to 0,0 perhaps because !m_nAdjustPosPixelLock.

Unfortunately, it isn't possible to just revert to Scrollbar->Show() any more. This is too convoluted for a mere mortal.
Comment 13 Justin L 2021-07-13 15:39:36 UTC
Created attachment 173532 [details]
99928_patch.diff: my hack that works except when horizontal bar is added
Comment 14 Justin L 2022-08-18 00:38:26 UTC
repro 7.5+
My question is, why would you go into print preview mode to zoom? Why not just zoom normally?
Comment 15 Tex2002ans 2024-02-06 12:27:12 UTC
I tested in:

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

and there is definitely funky stuff going on with "jumping to the top left / 0,0" of the pages in Print Preview.

I just did a:

- Ctrl+A
- Ctrl+C
- Ctrl+V a few times

in the test document to create ~12 pages to test.

> My question is, why would you go into print preview mode to zoom? Why not just zoom normally?

I typically use this "feature" all the time in PDF readers (like SumatraPDF):

1. Click/Highlight/Hover where I want to zoom.
2. Ctrl+Mouse+Scroll to zoom in far.

It lets you quickly zoom in/out, pan/scan, exactly for the reasons RGB first stated:

- focusing on extremely minor details


- Lines lining up
- Checking spacing between letters/equations / images/captions
- "Dumb" vs. “Smart quotes”

- - - - - - - - -

Of course, as a temp workaround:

- Do your zooming inside the ODT itself... heh.
   - Here, the zoom tries to "keep the cursor/highlight on screen", so it will never go "zooming off to top left / 0,0".
   - (It's not the greatest, it's a little jerky your highlight touches edges, but it does the job.)
- Export as PDF.
   - Smoothly click+zoom in any PDF reader!

There isn't a need to really use Print Preview for this.


- - - - - - - - - - -

While testing this, it seems like after:

1. File > Print Preview

- - -

The default(/2nd) setting:

- Two Pages Preview

when you zoom in using Ctrl+Mouse, the page:

- "Moves up and to the left (0,0)" until it touches.
- Then begins expanding to the right.

Even if you Left-Click/"Select" the Left or Right page, it treats both the same:

- Clicking the Right page won't focus on it, it'll just awkwardly "zoom on Left page / 0,0" same as above.

- - -

The 1st setting:

- Single Page Preview

is a little better, because the page:

- "Stays in the center" until it touches edges.
- Then begins "sticking up and to the left (0,0)".

- - -

The 3rd setting:

- Multiple Pages Preview

is the same as Two Pages, but even worse:

- Any page you click on doesn't matter, it will always zoom into top left (0,0).

For example, I made a 4x4 grid, and:

- Clicking on the 4th page
- Ctrl+Mouse Zoom

you completely lose the 4th page as LO "jumps to + zooms into the top left corner of page 1".

- - -


Another oddity I spotted is:

1. If I zoomed in on a location and manually dragged the vertical/horizontal scrollbars.
2. Zoomed in or out one tick.

LO instantly jumped to 0,0.

This was exacerbated so much worse in Two/Multiple.

- - -

If anything, I'd expect something like:

- If Page 2 selected
   - Zoom into Page 2's upper left corner.
- If Page 3 selected
   - Zoom into Page 3's upper left corner.

or a little closer to:

- LO Writer itself.

But ultimately it would be awesome:

- If Page 2 selected + mouse was hovered on a spot.
   - Center in and zoom on that mouse location.

(Similar to SumatraPDF + other PDF readers, or image editors like GIMP or Inkscape.)

- - - - - - - - - - -

Anyway, sounds like:

- The Print Preview code is a giant spaghetti mess.
- \+ This seems like a REAL obscure "feature". :P

But this "resetting/jumping to 0,0" is definitely not ideal, so I think ANYTHING could at least be a nudge in the right direction. :)