Bug 342003 - Trim margins confuses ordering of zoom steps while zooming out
Summary: Trim margins confuses ordering of zoom steps while zooming out
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 1.3.1
Platform: Debian unstable Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords: investigated, triaged
: 366449 368598 391352 403178 412002 416229 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-12-18 15:46 UTC by Jonas
Modified: 2021-04-09 01:19 UTC (History)
16 users (show)

See Also:
Latest Commit: https://invent.kde.org/graphics/okular/-/commit/0a23d4a0019aacd9ba71d38896d6b7c05f25b2c9
Version Fixed In: 21.04
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Jonas 2014-12-18 15:46:25 UTC 
While trim margins is active it is no longer possible to Zoom Out past the Fit Width state. Instead pressing Zoom Out (or Strg- -) repeatedly alternates between the next smaller zoom level and the Fit Width zoom level. This regression appeared recently, when Fit Width zoom level was sorted into the list of zoom states one reaches with Zoom In and Zoom Out. 

Reproducible: Always

Steps to Reproduce:
1. Activate Trim margins
2. Zoom to Fit Width
3. Zoom Out (Strg - -) repeatedly

Actual Results:  
Zoom level alternates between Fit Width and the next smaller one (f.ex. 75%).

Expected Results:  
Zoom out continuously.

I quite like the behaviour without Trim Margins.
Comment 1 Daniel Pastushchak 2014-12-24 16:57:07 UTC 
Comment from GCI student:
I use Kubuntu 14.10 and Okular 0.20.2, I faced the same problem and I think that this bug https://bugs.kde.org/show_bug.cgi?id=319637 is quite similar
Comment 2 stefan 2015-01-14 16:38:06 UTC 
Exactly same problem on Gentoo with Okular 0.20.3 (KDE Version 4.14.3). Problem did not exist for 0.17.x Version used before.
Comment 3 Angelos Skembris 2015-03-01 20:17:21 UTC 
I have exactly the same problem on OpenSUSE 13.2, KDE 4.14.4 and Okular 0.21.1. Disabling trim margins allows zooming out beyond the "Fit width" level.
Comment 4 nyanpasu64 2018-10-05 08:12:14 UTC 
STEPS TO REPRODUCE
1. open pdf
2. enable "trim margins"
3. zoom in until (page-width > window-width)
4. zoom out repeatedly

I've been able to reproduce bug regardless of window size.

OBSERVED RESULT
- When zooming in OR out, PDF snaps to "Fit Width" when the *untrimmed* margins cross 100% of screen width.
- When zooming in, this sometimes causes PDF to skip a zoom level (eg. 100%).
- When zooming out, this causes PDF to zoom *in* when snapping to "Fit Width".

EXPECTED RESULT
PDF snaps to "Fit Width" when the *trimmed* margins cross 100% of screen width.

SOFTWARE VERSIONS
(available in About System)
KDE Plasma Version: 5.12.6
KDE Frameworks Version: 5.44.0
Qt Version: 5.9.5

Also bugged in Flatpak Okular 1.5.1.

-----------

How do I submit a patch to fix this bug?
Comment 5 nyanpasu64 2018-10-05 23:42:19 UTC 
I'm not a maintainer, but I've done some digging and I think this is the issue.

void PageView::updateItemSize( PageViewItem * item, int colWidth, int rowHeight )
- defines Okular::Page *page
- okularPage->width() and okularPage->height()
    reflect the "uncropped unzoomed" dimensions of the page (in some units, IDK).

- finds the unzoomed dimensions
- if cropping enabled, crops them (multiplying by Okular::NormalizedRect[0,1] coordinates) (cropped unzoomed dimensions)
- multiplies by the zoom factor
- calls PageViewItem::setWHZC(cropped_w, cropped_h) with cropped w,h.

- PageViewItem::setWHZC sets m_croppedGeometry.
- PageViewItem::setWHZC divides by crop boundaries and sets m_uncroppedGeometry

-----------

// compute the zoom factor value for FitWidth and FitPage mode
double PageView::zoomFactorFitMode( ZoomMode mode )
- const double width = okularPage->width(), height = okularPage->height();

This is the bug. width()/height() are uncropped, but FitWidth and FitPage end up zooming the cropped page region.

We need to use the cropped unzoomed dimensions. But they are not exposed by the code, instead buried as local variables within PageView::updateItemSize(), and overwritten by the cropped zoomed versions when calling PageViewItem::setWHZC.

Consequently, currentItem->croppedWidth()/croppedHeight() is not a proper workaround. How should this bug be fixed?

-----------

Sidenote: Why is Okular written in Qt-flavored C++03 without std::?
Comment 6 Laura David Hurka 2018-10-06 18:49:35 UTC 
Small hint if difficult to reproduce:
The trimmed margins must be large enough. If this is not the case in your PDF, try to use "trim to selection" instead of "trim margins"
Comment 7 Magnus Aagaard Sørensen 2018-11-17 12:41:02 UTC 
Steps taken to reproduce:
* Open pdf file.
* Select trim to margins (View -> Trim View -> Trim Margins).
* Zoom in past the "Fit Width" label.
* Zooming out with GUI/mousewheel/keyboard shortcuts shifts between the "Fit Width" and the next zoom step.
* Normal, expected zoom behaviour returns after deselecting trim margins.

I'm not the developer, updating as part of the Okular Bug Day for the Bugsquad.

Application Version: 1.5.3
KDE Plasma Version: 5.14.3
KDE Frameworks Version: 5.52.0
Qt Version: 5.11.2
Comment 8 Magnus Aagaard Sørensen 2018-11-17 13:40:39 UTC 
*** Bug 366449 has been marked as a duplicate of this bug. ***
Comment 9 Albert Astals Cid 2019-01-15 21:56:29 UTC 
*** Bug 403178 has been marked as a duplicate of this bug. ***
Comment 10 Laura David Hurka 2019-06-09 17:03:29 UTC 
*** Bug 368598 has been marked as a duplicate of this bug. ***
Comment 11 Laura David Hurka 2019-06-09 17:11:42 UTC 
*** Bug 391352 has been marked as a duplicate of this bug. ***
Comment 12 Laura David Hurka 2019-06-09 17:27:24 UTC 
Also reproducible with Trim to Selection, supporting the investigation of jimbo1qaz.
Comment 13 Albert Astals Cid 2019-09-18 22:03:06 UTC 
*** Bug 412002 has been marked as a duplicate of this bug. ***
Comment 14 Albert Astals Cid 2020-01-15 21:42:28 UTC 
*** Bug 416229 has been marked as a duplicate of this bug. ***
Comment 15 exprosic 2020-05-31 09:55:23 UTC 
Reproduced on Okular 1.10.0
Comment 16 Martin Sandsmark 2020-07-01 15:12:24 UTC 
I think it was introduced by this commit:
2b971b07b2314479c59bc6ee3c382d8a869c9440
Comment 17 Luca Weiss 2020-09-09 13:42:04 UTC 
Still an issue in Okular v1.11.1 (KDE Applications 20.08.1)
Comment 18 Nate Graham 2021-04-09 01:19:40 UTC 
Fixed by Gerd Wachsmuth with https://invent.kde.org/graphics/okular/-/commit/0a23d4a0019aacd9ba71d38896d6b7c05f25b2c9 in Okular 21.04!