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 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
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.
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.
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?
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::?
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"
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
*** Bug 366449 has been marked as a duplicate of this bug. ***
*** Bug 403178 has been marked as a duplicate of this bug. ***
*** Bug 368598 has been marked as a duplicate of this bug. ***
*** Bug 391352 has been marked as a duplicate of this bug. ***
Also reproducible with Trim to Selection, supporting the investigation of jimbo1qaz.
*** Bug 412002 has been marked as a duplicate of this bug. ***
*** Bug 416229 has been marked as a duplicate of this bug. ***
Reproduced on Okular 1.10.0
I think it was introduced by this commit: 2b971b07b2314479c59bc6ee3c382d8a869c9440
Still an issue in Okular v1.11.1 (KDE Applications 20.08.1)
Fixed by Gerd Wachsmuth with https://invent.kde.org/graphics/okular/-/commit/0a23d4a0019aacd9ba71d38896d6b7c05f25b2c9 in Okular 21.04!