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.
Hi, 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
repro Version: 4.5.0.0.alpha0+
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 http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=18c661f715a0b6850d30b374e5556dc14a377d2b..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
as per comment this was introduced with libreoffice 3.6 latest.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170901
Problem still present on 5.4.1.2 under Linux (64 bits)
Same range of commits as in bug 99332. Adding to see also
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Problem still present in 6.1.1.2
Dear RGB, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Problem still present in 6.3.1.2
(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 https://cgit.freedesktop.org/libreoffice/core/commit/?id=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.
Created attachment 173532 [details] 99928_patch.diff: my hack that works except when horizontal bar is added
repro 7.5+ My question is, why would you go into print preview mode to zoom? Why not just zoom normally?
I tested in: Version: 24.2.0.3 (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 like: - 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. But... - - - - - - - - - - - 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". - - - NOTE ON ZOOM COORDINATES: 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. :)