PDF XChange Forum

About "Previous View" and "Next View".

This is, at times, a very painstaking and cumbersome affair.

For instance, after having consulted the footnotes of a document, I want to go back to the text, jumping within a book, say, from page 450 to page 65. Yet, with your understanding of this particular function, "previous view" does not mean going back to the previous page. Instead, "previous view" literally means going back to all the previous focuses of all the previous pages. Thus, most of the time, I have to press a dozen of times and more on "previous view" to get back to the page I came from, crossing on my way the same footnote page repeatedly and also other PDFs that I have opened in-between for reference.

Why is that? Well, for you, previous view means taking into account every little movement on the page: enlargement, reduction, movement to the left, movement to the right, srcolling downwards, scrolling upwards. It even includes other PDFs as well (as well as the change of focus on their pages). In theory, this might be helpful. However, I very much doubt its practicality.

Anyhow, if you want to maintain your rather peculiar conception of this function, I'd say you had better add a switch in the settings that allows for every one of your users to choose between the options "Previous Page"/"Next Page" and "Previous View"/"Next View". To my mind, such a choice might come in very handy for most. It might be a next step after having added the option to uncheck the standard setting of having to navigate back (and forward) through all open documents.

Hello wonderose2,
You are able to force views to only migrate through the current document, by unchecking the highlighted box below: As for jumping to specific pages, I would suggest using bookmarks for this functionality, section 2 of this article details how to create bookmarks:
https://www.pdf-xchange.com/knowle ... the-Editor

Have you tried split view? This would allow you to view multiple locations in the document at the same time, therefore reducing the amount of jumping around you need to do.
Admittedly, as this function is working as intended, and it is unlikely to change. This is because there is no catch all algorithm for which views to save and which not to, it may seem arbitrary, but there are good reasons behind each of our decisions in this regard.

Thanks for your answer!

1) I already mentioned this particular function (your highlighted box) in the last sentence of my post: "the option to uncheck the standard setting of having to navigate back (and forward) through all open documents".

2) Bookmarks, yes, I do have them, and I do use them abundantly. However, they can't replace a good previous page button, especially in cases when there are many pages with footnotes (and I imagine, in another, yet similar scenario, namely when there are many pages with solutions to the assignments of a textbook). Then, you first use the bookmark to jump to the notes (or the solutions section) before scrolling down to the particular footnote (or the particular solution) you are looking for. Yet, you still have to go back at some point, and then the misadventure starts (see my previous post), as the footnotes in the text are not always there where the bookmarks are. Unfortunately, bookmarks tend to be at the beginning of chapters (and not at the sentence with the footnote 127).

3) Do you read many large PDF files on a screen in laptop size? And have you already used for more than a few hours a split screen in laptop size to read large PDF files? It is a daunting experience. That said, I also don't always need an eye on the footnotes (or the solutions). I only want to verify something from time to time. And anyway, why should the split function (that you seem to recommend to all users with problems similar to mine) replace the "previous page" function? Shouldn't rather both of them be part of a good and solid PDF reader?

4) Unfortunately, I can't say I am always completely convinced of the rationale of your decisions. May I, as a layman (and avid user), venture to recommend you a little piece of software that managed to implement the feature I am looking for in a lean and straightforward way? It is the Android app Foxit PDF. So why not give your users more of a choice in one of the core fields of your software: quickly navigating within a document?

More about navigate backward and forward:
viewtopic.php?f=62&t=23719

Hi all,

I've been speaking about this internally, and have come to the conclusion that while the current handling likely wont change, a new feature may be necessary to accommodate this use. As such I've created a feature request to implement a "Previous viewed page" function, essentially a combination of the previous view, and the previous page functions, allowing you to jump to the last page viewed, without going through all the views along the route.
#4370: FR: Previous Viewed Page
Have a great day everyone!

Thank you!

TrackerSupp-Daniel wrote:I've been speaking about this internally, and have come to the conclusion that while the current handling likely wont change, a new feature may be necessary to accommodate this use. As such I've created a feature request to implement a "Previous viewed page" function, essentially a combination of the previous view, and the previous page functions, allowing you to jump to the last page viewed, without going through all the views along the route.
#4370: FR: Previous Viewed Page

Hi Daniel and @all,

I appreciate very much that there shall be improvements to the "Back" and "Forward" functions. I would like to add two suggestions for when this feature is being worked on.

(A) Firstly, currently there is a fixed one second delay when recording previous views, in order not to have too many steps recorded, which is understandable.

On the other hand, this one second delay is often too long, particularly when in single page, full page view mode:

...i.e. when not scrolling continuously but instead jumping between different pages of the document.

In this case, if you want to take a quick look at another page in the document (say, you are on page 4 and want to quickly look at page 12, e.g. by clicking on the thumbnail of page 12), and then quickly try to return to your previously displayed page 4, it often happens that the one second delay is not yet over and your visit on page 12 is not recorded.

This means when hitting ALT+LEFT (or the "Back" Toolbar Button ) when you still are on page 12, you don't end up where you came from (i.e. on page 4) but instead at some other, older point in your view history. This has already been described in 2016 here, and a solution would be to not activate the one second delay in recording history when the user clicks on links, bookmarks, thumbnails, next/previous page buttons and the like (in other words, record any new view instantly, as soon as the corresponding aforementioned item is clicked). Rather, the one second delay really only should be used when the pages are scrolled continuously, for example by the scrollbars or using the hand tool, and as described by wonderose2 in the original posting of the present thread.

(B) Secondly, and on a related issue, I would like to ask the Dev team to consider correcting the behavior of the shared view history between several windows of the same document. This feature is practically not usable in its current form, as described over here.

As always, thank you for listening to your users
and keep up the great work
David.P

Hi David,

Many thanks for the feedback and bringing all those discussions and links in this same thread.
I will include all of this in the ticket now, and make sure it is considered as well!

Regards,
Stefan

Hi Stefan,

many thanks for taking action on this overall "view history" issue with its two manifestations as discussed, i.e. Back/Forward recording timeout handling, and dealing with multiple document windows.

Looking forward to any news or progress on this!

Best regards
David

David.P wrote: ↑Sat Jul 21, 2018 5:45 pmI appreciate very much that there shall be improvements to the "Back" and "Forward" functions. I would like to add two suggestions for when this feature is being worked on.

(A) Firstly, currently there is a fixed one second delay when recording previous views, in order not to have too many steps recorded, which is understandable.

On the other hand, this one second delay is often too long, particularly when in single page, full page view mode:

...i.e. when not scrolling continuously but instead jumping between different pages of the document.

In this case, if you want to take a quick look at another page in the document (say, you are on page 4 and want to quickly look at page 12, e.g. by clicking on the thumbnail of page 12), and then quickly try to return to your previously displayed page 4, it often happens that the one second delay is not yet over and your visit on page 12 is not recorded.

This means when hitting ALT+LEFT (or the "Back" Toolbar Button ) when you still are on page 12, you don't end up where you came from (i.e. on page 4) but instead at some other, older point in your view history. This has already been described in 2016 here, and a solution would be to not activate the one second delay in recording history when the user clicks on links, bookmarks, thumbnails, next/previous page buttons and the like (in other words, record any new view instantly, as soon as the corresponding aforementioned item is clicked). Rather, the one second delay really only should be used when the pages are scrolled continuously, for example by the scrollbars or using the hand tool, and as described by wonderose2 in the original posting of the present thread.

(B) Secondly and on a related issue, I would like to ask the Dev team to consider correcting the behavior of the shared view history between several windows of the same document. This feature is practically not usable in its current form, as described over here.

Hi forum and Tracker team,

I was just going to ask whether improvements on this are already worked on? It would be great if the above two problems (A: fixed one second delay in recording view history, and B: shared view history between document windows) could be fixed.

Thank you!

David.P wrote: ↑Sat Jul 21, 2018 5:45 pmI appreciate very much that there shall be improvements to the "Back" and "Forward" functions. I would like to add two suggestions for when this feature is being worked on.

(A) Firstly, currently there is a fixed one second delay when recording previous views, in order not to have too many steps recorded, which is understandable.

On the other hand, this one second delay is often too long, particularly when in single page, full page view mode:

...i.e. when not scrolling continuously but instead jumping between different pages of the document.

In this case, if you want to take a quick look at another page in the document (say, you are on page 4 and want to quickly look at page 12, e.g. by clicking on the thumbnail of page 12), and then quickly try to return to your previously displayed page 4, it often happens that the one second delay is not yet over and your visit on page 12 is not recorded.

This means when hitting ALT+LEFT (or the "Back" Toolbar Button ) when you still are on page 12, you don't end up where you came from (i.e. on page 4) but instead at some other, older point in your view history. This has already been described in 2016 here, and a solution would be to not activate the one second delay in recording history when the user clicks on links, bookmarks, thumbnails, next/previous page buttons and the like (in other words, record any new view instantly, as soon as the corresponding aforementioned item is clicked).

Rather, the one second delay really only should be used when the pages are scrolled continuously, for example by the scrollbars or using the hand tool, and as described by wonderose2 in the original posting of the present thread.

(B) Secondly [...].

Hi forum and Tracker team,

I believe it would be very helpful and useful if at least issue (A) could be addressed.

A doable workaround for me would be already if the (currently fixed) 1 second delay before an entry is recorded in the Editor's view history could be shortened, e.g. by modifying a respective entry in the registry.

It happens to me in the hundreds of times a day that when I try and quickly jump back to a previous view, I end up at the one before my actual previous view, because I clicked the "back" button (or keyboard shortcut) after less than 1 second.

So if there should be a registry key for the 'view history recording delay time', I would be very grateful for corresponding information.

Thank you
David

Hello David,

Item B from your posts we are look at seriously to considering in depth, and while it may become an option in the future, it will not likely be available any time soon.

On point A however, it is unlikely that we will be changing or allowing manual changes for the time interval of a view being recorded. if we make it much shorter than it already is, users who are not lightning quick when scrolling will find that there are more "previous views" than they would expect, simply because of the time it takes them to move their finger during repeated scroll actions, if we made it longer, it would miss even more users previous views. Something like this, while potentially possible, is simply not something viable enough for further consideration at this time.

Kind regards,

Hello Daniel,

thank you for your answer. Excuse my late reply.

TrackerSupp-Daniel wrote: ↑Thu Dec 05, 2019 8:23 pm [...] On point A however [change the fixed one second delay when recording previous views], it is unlikely that we will be changing or allowing manual changes for the time interval of a view being recorded. If we make it much shorter than it already is, users who are not lightning quick when scrolling will find that there are more "previous views" than they would expect, simply because of the time it takes them to move their finger during repeated scroll actions, if we made it longer, it would miss even more users previous views. Something like this, while potentially possible, is simply not something viable enough for further consideration at this time.

I was going to briefly clarify that my above feature request is not about reducing the time interval of the view history recording to less than 1 second. Rather, I concur with you that this interval already is well suited, particularly also better than the interval used by Adobe, which is much shorter.

The only thing I was concerned with here was that the one second time interval really should only be triggered when scrolling through the document. In contrast however, if you move through the document by clicking on things (like thumbnails, bookmarks, search occurrences, links etc.), then the respective target view should be recorded in the view history instantly, and not with a one-second delay (as it is at present).

The same feature request was already discussed in detail back in 2016, and Patrick had already agreed to the feature request and opened a ticket for it.

Since this was several years ago, I replied in the thread over there asking what the current status is.

Thank you again
David

Hi, David.P

Indeed, I apologize for misunderstanding at the time, re-reading the history now and seeing the ticket I can understand what you were describing. As I mentioned in the other thread there have been no updates on these tickets in a while, and I have requested that we look into them once again when time allows.

Kind regards,

Thanks very much Daniel,

let's keep the updates on this over there in order to have an optimal overview about the status of the two tickets.

Cheers & best regards
David

Hi, David.P

Sounds good, Keeping it all in one place is an excellent plan.

Kind regards,