GNOME Bugzilla – Bug 684005
Whenever I click on something in the Side Pane it always forces "Best Fit" viewing mode
Last modified: 2014-09-03 17:51:54 UTC
Regardless of whether I'm clicking on a Page Thumbnail or something in the Index of the side bar when Evince takes me to that page or section it always displays it in "Best Fit" mode. Usually I am reading in "Fit Page Width" mode but whatever mode I'm in whenever I click on anything in the Side Pane I'm forced into "Best Fit" mode when it's shown. On other PDF viewers such as Okular this is not a problem. Whenever I click something in the Side Pane I still remain in whatever viewing mode I'm in when I'm shown the section I want. Hell even in Evince if I enter the page number where I want to go to in that little box I still get to keep the viewing mode I'm in. This thing with the sidebar is inconsistent with the behaviour of other PDF viewers as well as the rest of Evince. Granted this isn't a big deal but is still really annoying to both me and I imagine other users.
Which Evince version is this about?
Well right now I'm on an Ubuntu box running Evince 3.4.0 as is evidenced by: georgiy@PANTHER:~$ evince --version GNOME Document Viewer 3.4.0 georgiy@PANTHER:~$ However I hop distros the way hobos hop freight trains and have worked with all sorts of versions of Evince both old and new in various distros. All of them had that bug and that's why I left the version unspecified in the initial report because this problem is version agnostic and goes as far back as I can remember.
Gerogiy, Could you be more specific on how to reproduce the bug? Does it happen with every file? I can't reproduce this. Of course, clicking on the sidepanel should not change the viewing mode, and if that happens, then it is a bug, but right now I cannot reproduce this in evince 3.4
@Jose: Interesting. I've actually done some more testing on various types of PDF files and some actually appear to be unaffected by this bug. But in others this bug is present. Apparently this only effects some files but not others. Why this is I don't know. Here is a file which behaves correctly: http://superb-dca2.dl.sourceforge.net/project/linuxcommand/TLCL/09.12/TLCL-09.12.pdf Here is a file which behaves incorrectly: http://openstorage.gunadarma.ac.id/pub/journal/Teach%20Yourself%20C++%20in%2021%20Days%205th%20Edition.pdf
furthermore this appears to affect the Index and not the Thumbnails in the problem files
mmm. I am not clear on whether this is a bug or not. The outline links in the pdf that behaves incorrectly have the property "fit", which from the PDF 1.7 Reference book means: "Display the page designated by page, with its contents magnified just enough to fit the entire page within the window both horizontally and vertically. If the required horizontal and vertical magnification factors are different, use the smaller of the two, centering the page within the window in the other dimension." So, while I agree that changing from Best With to Best Fit is unconvenient, I am not sure we should just ignore the fit property on the outline link.
Wait. So in the PDF files that are effected by the issue I bugreported you're saying this is specified by the PDF Standard??? Wow. Just wow. That would be shocking if true. I just hope it's not and that this was a miscommunication of the bug on my part or misunderstanding of something on yours. Okular and other PDF viewers don't behave like this. Try the problem file with Okular and you'll see what I mean. On one hand standards compliance is very important. On the other hand if the standard says something stupid or the deviation in question is harmless why not. Ultimately it's your call as to whether or not this is a bug and whether or not to fix it. If things remain as they are and I'm forced into best fit mode I can fix it faster than thought. Alt-v then w boom problem solved. However not all users are as fanatical about keyboard shortcuts as I and being made to point and click through the toolbar or menu bar dialogs to return things to whatever mode they were previously in is slow and will annoy them over time. Anyway just check that you have your facts right and if you feel I described anything wrongly or ambiguously let me know because my bug reports are oftentimes rather poorly written. Just wonder what's going on here and what end of the earth things are on?
(In reply to comment #7) > Wait. > > So in the PDF files that are effected by the issue I bugreported you're saying > this is specified by the PDF Standard??? > > Wow. Just wow. That would be shocking if true. I just hope it's not and that > this was a miscommunication of the bug on my part or misunderstanding of > something on yours. I think José is right. You can check it by yourself in the section 8.2 (page 581) of http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference_1-7.pdf It describes two forms of global overview of a document: a hierarchical outline (Index) and a collection of thumbnail images. From that, you can navigate to destinations, which consists of: "* The page of document to be displayed" "* The location of the document window on that page" "* The magnification (zoom) factor to use when displaying that page" The property "fit" than José mentions corresponds to the last bullet (that is explained in the next page of the same document). > Okular and other PDF viewers don't behave like this. Try the problem file with > Okular and you'll see what I mean. On one hand standards compliance is very > important. On the other hand if the standard says something stupid or the > deviation in question is harmless why not. Right, Okular does not behave like this. At least the version shipped in Ubuntu. FWIW, Acroread behaves as the standard says. > Ultimately it's your call as to whether or not this is a bug and whether or not > to fix it. If things remain as they are and I'm forced into best fit mode I can > fix it faster than thought. Alt-v then w boom problem solved. However not all > users are as fanatical about keyboard shortcuts as I and being made to point > and click through the toolbar or menu bar dialogs to return things to whatever > mode they were previously in is slow and will annoy them over time. I have been thinking why the standard would define the magnification level to show a destination, and why some editors would use it. My conclusion is that by using the outline (Index), you can navigate quickly to look and see if that is what you are looking for (think on textual index -> big thumbnail). Once you found your starting point, you can switch to a reading mode (thumbnail -> fit to page). Do not take my words in my previous paragraph for granted. It is the use cases the standard might have tried to address (if the editor/writer wanted to use it). > Anyway just check that you have your facts right and if you feel I described > anything wrongly or ambiguously let me know because my bug reports are > oftentimes rather poorly written. I think you have been very clear in your report.
*** Bug 665291 has been marked as a duplicate of this bug. ***
What you are saying is that the document/page is set to display at that magnification level. That is fine if we are just opening a new document. Or for documents where the user do not a have/set a preference. But here we are talking about situations when the user specifically/manually set a zoom level and evince is not respecting it. User setting always should have a higher preference than the default settings. Or more precisely, we are talking about situations when evince is not respecting the user settings in some specific cases. The user set zoom level is respected in normal scrolling. The same documents/pages when scrolled to do not change the zoom level and do not respect the default settings you mentioned. It changes the zoom level only when using bookmarks for traversing. This is definitely a fault from evince. I don't think respecting the defaults in case of scrolling make any sense. How silly it will be If you change the zoom level and scroll to a different page, and evince changes the page zoom level. This is the same case with bookmark traversal.
(In reply to comment #10) > What you are saying is that the document/page is set to display at that > magnification level. That is fine if we are just opening a new document. Or for > documents where the user do not a have/set a preference. > No, I am saying that Links in PDF can have a property that says: when following this link, please set the magnification level so the whole page will be visible. This also is the case for links in the outline of the file. Thus, if your file has this property set for ALL links in the outline, then you will see the ackward behaviour described in the bug.
*** Bug 660916 has been marked as a duplicate of this bug. ***
Can someone please comment on this bug? This is driving me crazy. The software should respect my setting not the setting in some obscure property within the pdf which no other readers respect/uses. (I find it quite surprising that none of the developers found it to be frustrating. No developers ever used a pdf that whenever clicks on a page link goes back to 'best fit' and have to change the page width to continue reading. Are you guys using evince or something else for reading?) At least can you add it as an option to always have pages load in 'fit page width' irrespective of what the so called 'pdf property' says? (Why do we even have this 'best fit'? No one can read the pages with best fit. That setting itself is just stupid/waste. If I were you I would remove that setting completely.)
Evince is only honouring the specification. The one to blame here is the publisher.
FWIW, I would close this bug as NOTGNOME.
>>At least can you add it as an option to always have pages load in 'fit page >>width' irrespective of what the so called 'pdf property' says? Do you have any comments about the above qn? An option to overwrite the doc zoom setting?
(In reply to comment #16) > >>At least can you add it as an option to always have pages load in 'fit page > >>width' irrespective of what the so called 'pdf property' says? > > Do you have any comments about the above qn? An option to overwrite the doc > zoom setting? Ask the publisher to do so or use an editor to do it. Acrobat Reader also behaves as Evince.
(In reply to comment #17) > (In reply to comment #16) > > >>At least can you add it as an option to always have pages load in 'fit page > > >>width' irrespective of what the so called 'pdf property' says? > > > > Do you have any comments about the above qn? An option to overwrite the doc > > zoom setting? > > Ask the publisher to do so or use an editor to do it. > > Acrobat Reader also behaves as Evince. How do you suggest a publisher to add an option to evince? Join Gnome?
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > > >>At least can you add it as an option to always have pages load in 'fit page > > > >>width' irrespective of what the so called 'pdf property' says? > > > > > > Do you have any comments about the above qn? An option to overwrite the doc > > > zoom setting? > > > > Ask the publisher to do so or use an editor to do it. > > > > Acrobat Reader also behaves as Evince. > > How do you suggest a publisher to add an option to evince? Join Gnome? I am sorry, but I am fine with respecting the specification (standard). That is, I do not see the point of adding an option. If an evince developer thinks different, good for you. If not, it is not the end of the world.
Created attachment 234888 [details] Adobe reader option to override zoom setting (In reply to comment #19) > I am sorry, but I am fine with respecting the specification (standard). That > is, I do not see the point of adding an option. I am fine with respecting standards too. But I don't see how that has anything to do with adding an 'option'. Say for example, we have 'invert colours' option in evince, which is not a standard (I assume, since it is not in adobe reader). So we are adding awesome features to the reader without sacrificing on respecting standards. > > (In reply to comment #17) > > > Acrobat Reader also behaves as Evince. Since you keep on comparing to adobe reader, just letting you know that adobe reader has a feature to force the zoom level in the document. Screenshot attached.
(In reply to comment #20) > > > (In reply to comment #17) > > > > Acrobat Reader also behaves as Evince. > > Since you keep on comparing to adobe reader, just letting you know that adobe > reader has a feature to force the zoom level in the document. Screenshot > attached. Interesting. Even more interesting is the reason the option exists: for accessibility. That is fair point. Here is the documentation of that part: http://help.adobe.com/en_US/acrobat/X/pro/using/WS58a04a822e3e50102bd615109794195ff-7d23.w.html FWIW, when I meant by Acroread behaviour I meant the default behaviour and how it renders the documents. Its UI seems cluttered to me. This does not make your point less fair, though. Now the challenge would be how to make it work in Evince and still preserving the lack of a preferences dialog.
(In reply to comment #21) > Now the challenge would be how to make it work in Evince and still preserving > the lack of a preferences dialog. Thank you, for understanding. Can't we add it as a menu item under 'view' menu (Close to where other zoom settings are placed)? But obviously, you are the developer and would know better than me.
*** Bug 693584 has been marked as a duplicate of this bug. ***
*** Bug 653774 has been marked as a duplicate of this bug. ***
How about "Force my zoom level settings" check-box-option in View menu, persistent between Evince restarts, that will force Evince to ignore "zoom level" settings from PDF document?
As the reporter of this bug for a while I just haven't been sure how to comment. However now I know what to say. Tomas hit the nail on the head perfectly. His solution 1. solves the user's complaints and 2. is a very simple light minimalistic toggle in sync with the GNOME philosophy. I advise to go with Tomas's solution.
*** Bug 679997 has been marked as a duplicate of this bug. ***
*** Bug 655068 has been marked as a duplicate of this bug. ***
I can confirm this behaviour in version 3.8.3. I previously changed my default settings to "Fit Page". When I open a new document I get the entire first page as expected. If I scroll up or down with the mouse the page size remains constant. If, however I jump to a different page using the left index or right scroll bar, the page size changes back to "Best Fit". This requires constant correcting. I don't remember this behaviour in the previous release. BTW, I'm using the released version of Evince in Fedora 19 running Xfce.
The current behavior is what we want by default, because it is the behavior that follows the PDF spec more closely (Links with FIT* destinations are allowed to change the zoom option). HOWEVER; https://bugzilla.gnome.org/show_bug.cgi?id=729249 was just fixed. This means eans that people bothered by this default behavior can change "allow-links-change-zoom" to False in the Evince GSettings schema in order to prevent FIT* destination from changing the zoom. Thus, I am marking this as fixed.