GNOME Bugzilla – Bug 467249
Resize window when zoom is changed
Last modified: 2018-05-22 13:17:24 UTC
A window that fits the content exactly is usually preferable one too small to view the whole content or a one so large that it wastes screen space by displaying non-content. A window without scroll bars is also more esthetically pleasing, and allows navigation to the next page using Spacebar, which is simpler than "Next page" (Control+PageDown). Currently the right window size can be achieved by manually resizing the window, which is laborious. Instead, there should be a new mode that keeps the window in the optimal size as the content is zoomed (until the window becomes too large to fit on screen). Then user can concentrate on the content instead of resizing the window. Alternatively, there can be an action to resize the window to the optimal size; but requires more work for the user. The mode or action can be invoked under the View menu. The causation here is the opposite direction from the one in "best fit" or "fit width" view. If it is implemented as a mode, then "best fit" and "fit width" should also be modes (alternatives to "custom window size"), so that "best width" with "resize window" both resizes the window if the content is zoomed, and re-zooms the content if the window size is changed.
I forgot to link the last paragraph to bug 328910.
Here's a succinct pseudocode for what I think the OP is saying (and I agree): if (zoom-level not in [best-fit, fit-width]): paper-height *= zoom-level set-window-height((paper-height < usable-screen-height) ? paper-height : usable-screen-height) set-window-width((paper-width < usable-screen-width) ? paper-width : usable-screen-width) `usable' means not counting things like gnome-panel, the Windows taskbar, or the Mac titlebar and dock.
Yep, that's what I meant. I'm not sure which is better - a new view mode or an action to be invoked. GV has that functionality as a mode. Also, this idea can be combined with "fit visible", so that the window is resized to fit only the visible part of a document, not the margins (if there is one).
Sorry, I don't get it. Probably you could attach a screenshot.
Alright, attaching screenshots for clarity. Figure 1 represents a PDF I have opened for the first time. Note that my default view mode is Best Fit and the window, sans window manager, measures 812x812. There is no particular reason for Evince to choose this size. Figure 2 represents how this PDF should have opened. Since the page is actually too tall to fit on the screen, it resizes the window to use all the height available. It also changes the window width to be wide enough to fit a page whose height is constrained to a window this high. I got the formula wrong above; there'd be no point resizing the window width to paper-width because window-height is less than paper-height. The math should be easy, but it would only serve to make this bug more confusing so I won't post it now.
Created attachment 128110 [details] Figure 1: How it looks
Created attachment 128111 [details] Figure 2: How it should look
Ok, got you. Thanks.
This looks like a duplicate of bug 168450. In that bug, Nickolay, before this bug was even posted, you said you had submitted a patch that fixed the problem somehow, but it still seems to be a problem two years later. Did your patch get rejected or does it not do what I expect? I don't know what it's like for other people, but every new PDF I open (usually US Letter size) is too small to read until I enlarge the window. Would anyone like to describe how readable the average document is for them when they open it for the first time?
Well, in that bug we were trying to keep the same ratio between document page size and window size, here I suspect more intelligent algorithm is proposed.
My Evince windows default to a small square. Is there really an algorithm setting the ratio between page size and window size? My comment #5 above describes an idea for sizing the window, BTW. I'm not sure it's precise enough to be helpful.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/42.