Description: If there are multiple pages when previewing in the print dialog, standard scrolling down (to the next page) will not work. When a user sees the print preview, they expect to navigate through pages using standard scrolling: upwards for the previous page and downwards for the next page. However, at this point, the direction of page switching is reversed: scrolling upwards takes you to the next page, while scrolling down takes you to the previous page. The path to the required file is: **vcl/source/window/printdlg.cxx** The necessary place in the code: bool PrintDialog::PrintPreviewWindow::Command( const CommandEvent& rEvt ) { const CommandWheelData* pWheelData = [rEvt.GetWheelData()](rEvt.GetWheelData()); if(pWheelData->GetDelta() > 0) mpDialog->previewForward(); else if (pWheelData->GetDelta() < 0) mpDialog->previewBackward(); return true; } To make the scrolling behavior familiar, we need to swap the calls to Forward() and Backward(). Steps to Reproduce: 1. Open any Libreoffice module (eg calc) 2. Create a document with more than 1 page 2. Open the print dialog 3. Try scrolling the print preview Actual Results: if scroll the mouse down, it shows the previous page, if scroll up, it shows the next page Expected Results: if scroll the mouse down, it shows the next page, if scroll up, it shows the previous page Reproducible: Always User Profile Reset: No Additional Info:
Confirming the issue with Version: 25.2.1.2 (X86_64) / LibreOffice Community Build ID: 520(Build:2) CPU threads: 32; OS: Linux 6.13; UI render: default; VCL: kf6 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US 25.2.1-2 Calc: threaded Scrolling down does nothing on page 1, up goes to the next page. The direction responds to the scroll direction. The direction is hard-coded in PrintDialog::PrintPreviewWindow::Command(). Easy to change, and the proposal has my +1.
Sent related patch: https://gerrit.libreoffice.org/c/core/+/183174
We discussed the topic in the design meeting. There is intuition for both, similar to spinedit controls wheeling away means to spin up. Alternatively, pages are stacked and the next one is below, which would be wheeling the other way. Balancing the two options we recommend to follow the proposal.
Irgaliev Amin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/13575ca0fb914dbdc075ca6c3a8d7fce370b4807 tdf#165371 Reverse page switching direction using mouse in print dialog preview It will be available in 25.8.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.
Irgaliev, I did not notice this bug. I was always using the arrows, not the scrollbar. You can mark the bug as resolved. Thanks for solving this one. Tested in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4503abd1a6788a5c3cb2168f23b63559a6cabebf CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded It is not good (for comparison reason) in Version: 25.2.1.1 (X86_64) / LibreOffice Community Build ID: e538fb6403facdfd3db0250c3b3278236c675c2a CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded