Current page displayed after deleting pages is different from common PDF software

[rakunavi]

Hello all,

The current page displayed immediately after deleting a page in PDF-XChange Editor seems different from typical PDF software.

For example, the sample file has 100 pages and all pages are numbered. If you follow the steps below to delete page 1 through page 27, PDF-XChange Editor will show page 54 of the original document.

• sample.pdf

1. Click on page 1 in the Thumbnails pane.
2. Shift+click on page 27 in the Thumbnails pane.
3. Delete the selected pages with the Delete command.

In contrast, most PDF software, such as Acrobat and Foxit PDF Editor, will show page 28 of the original document as the current page.

• Animation.gif

Software other than PDF-XChange Editor does not behave the same in all situations, and its behavior varies slightly depending on which page range is being deleted. However, the uniqueness of PDF-XChange Editor's current page selection stands out among PDF softwares. If there is some benefit to that uniqueness, then so be it, but unfortunately, I personally do not see much benefit.

Thank you for taking the time to read this message.

Best regards,
rakunavi

- PDF-XChange Editor PRO Version: 10.6.0 build 396
- Adobe Acrobat X Standard Version 10.1.16
- Foxit PDF Editor Pro 13.1.2.22442
- OS Version: Windows 11 Pro / Home 24H2 Build 26100.4061
- PC Model: GMKtec Nucbox M7 Pro with HUION Kamvas Pro 19 / Lenovo IdeaPad C340-15IWL

[Jordan - PDF XChange]

Hello rakunavi,

I do think I will disagree with you here from what I can see when pages are selected the current one is displayed and in our case as page 27 was selected the 27th page of the new document is displayed, to confirm this I have selected the pages in reverse:

2025-05-29_17-02-10.gif

[mCHSNUg5Pz8cPap]

Hello rakunavi,

I do think I will disagree with you here from what I can see when pages are selected the current one is displayed and in our case as page 27 was selected the 27th page of the new document is displayed, to confirm this I have selected the pages in reverse:

Can you explain this a little more, particularly how this is a good thing? As I understand it, you are saying that because Rakunavi selected pages 1-27 beginning with page 1 and ending at page 27, the last page selected was 27 so that when they are deleted, the page that will be shown is original page 54 because it is not page 27 in the document. In what scenario is this useful? I imagine that almost everyone who deletes pages 1-27 expects to be shown original page 28 after the pages are deleted, not the page that happens to coincide with the number of the last deleted page

Your example makes it even worse in my opinion because now the software behaves seemingly randomly depending on how the user selects the pages to be deleted. From a user perspective, it appears that sometimes PDF-XChange meets expectations (e.g., when the pages are selected beginning with the last page) and sometimes it does not (e.g., when the pages are selected beginning with the first page). It appears random and confusing even though apparently there is some criteria behind why one method produces one result and the other produces a different result.

[Willy Van Nuffel]

Hello all,

Remember a similar thread, a few months ago:
viewtopic.php?t=44113

Kind regards.

[Daniel - PDF-XChange]

Hello, Willy Van Nuffel

Thank you for linking that thread.

As I mentioned over there, while the process many people take will often coincidentally result in the one of the two selected page numbers being visible, this is not random, and is by design.
The "selection" actually has no impact here, we are only retaining the "viewed" page-number.
EG: If you are looking at page 28 when you push delete, whatever content is now on the new "page 28" will remain visible. The viewed page number does not change, unless you delete so many pages, the current viewed page would no longer be inside the bounds of the document. If you did the same looking at page 13 or 33, the same would be true, and you would see the respective "new" page 13 or 33 after pages 1-28 had been deleted.

Kind regards,

[rakunavi]

Hello all, thank you all for your valuable comments.

I have read all the posts on the topic introduced by @Willy and understood that the current behavior is entirely what PDF-XChange intends and has no intention of changing. If that is the case, it may be pointless to comment further on this matter, but just to be sure, I would like to offer my own perspective on the question raised by @Daniel at the end of that topic.

Say theoretically, you have selected 3 different page ranges to delete at once (page 2-5, 10-20, and 320-370) in a 500 page document. Currently you are looking at the glossary at the end of the document, which of these 3 separate ranges would we choose to navigate to?

Of course, if the current page is the page 500, then I believe that the original page 500 should still be displayed after deletion.

In the following verification, I will use two documents, one with a total of 500 pages according to Daniel's example, and the other with a slightly larger total of 1000 pages. For each document, in PDF-XChange Editor and Acrobat, select pages 2-5, 10-20, and 320-370 in the thumbnail pane and batch delete them, keeping the current page at page 500.

If you use a document with a total of 500 pages (sample500.pdf), both PDF-XChange Editor and Acrobat will keep the current page as page 500 after the deletion.

• figure1.png
  
  
  Animation1.gif

• sample500.pdf

In contrast, if you use a document with a total of 1000 pages (sample1000.pdf), after deleting, PDF-XChange Editor will show the old page 566 as the current page, while Acrobat will keep the old page 500.

• figure2.png
  
  
  Animation2.gif

• sample1000.pdf

The old page 566 displayed in PDF-XChange Editor is calculated according to the following formula.

• 500+(5-2+1)+(20-10+1)+(370-320+1)=566

I understand that this is a difference in thinking about what should be maintained, but with the PDF-XChange Editor's method, the Comments pane and Bookmarks pane also change the display range to show the old page 566 information that exists on the new page 500 after the deletion.

• Page view of the new page 500 corresponding to the old page 566
• Bookmark for the new page 500 corresponding to the old page 566
• Comment on the new page 500 corresponding to the old page 566

It does not seem to me that showing these information would benefit the user. Deletion of pages is done because that page is unnecessary for the user. If that is the case, then the 66 derived from the total number of pages of that unwanted item should have no meaning, nor should the page 566, which is page 500 plus that 66, have any meaning. In other words, there is no rationale for keeping page 500 as current page after the deletion just because page 500 was the current page before the deletion.

It seems counterintuitive to me personally that the result after deletion would change just because the total number of pages changed between 500 and 1000, even though the page is currently looking at page 500 and the page target to be deleted is the same.

These differences in behavior naturally also appear when using JavaScript. In the file below, the link on page 500 has JavaScript set to delete pages 101 through 200.

Code: Select all

this.deletePages(100, 199);

In Acrobat, the current page remains at the old page 500 after clicking the link, but in PDF-XChange Editor it changes to the old page 600. Is there really an overwhelming majority of users who sincerely want the current page to change to the old page 600 in this situation?

• Animation3.gif

• sampleJavaScript.pdf

Personally, it was meaningful to see that there are users who think like I do.

Thank you for taking the time to read this message.

Best regards,
rakunavi

[mCHSNUg5Pz8cPap]

Personally, it was meaningful to see that there are users who think like I do.

I noticed this behavior in the past, but didn't know why it was happening. I thought there was a bug somewhere but never had time to figure out how to reproduce it. Come to find out it is a deliberate design choice ... a strange and counterintuitive design choice.

I'm curious to know who prefers the current behavior to the alternative Acrobat behavior as shown by the examples provided by Rakunavi? The resistance we are being met with when advocating for the behavior to change suggests there must be many people who prefer the current behavior. If so, why?

[Willy Van Nuffel]

I agree with @rakunavi and @mCHSNUg5Pz8cPap

Myself, I would prefer the following behavior:

If the page that is currently displayed (in case of multiple pages being displayed => always the page number at the bottom of the window):
1) is NOT in the selection for deleting, then this same page should be shown after the delete has happened.
2) is IN the selection for deleting, then the page just after the selection should be shown or - in case the selection was at the very end of the document - the page just before the selection.

I hope I explained this clear enough and wonder @pdf-xchange-support if the discussion will be re-opened ?

Kind regards.

[Daniel - PDF-XChange]

Hello, all

I am always happy to see discussion and speculation surrounding our features, one thing I need to comment on here.

calculated according to the following formula.

500+(5-2+1)+(20-10+1)+(370-320+1)=566

There is no secret formula, or any math at all involved to "calculate" the target page, infact, there are no calculations that happen at all. It is just the visible page number being retained at it is.

Here is an example of the logic, but I need to impress that I am heavily overcomplicating this by giving it 3 whole steps. In reality, it is just "the viewed page number does not change":

• In this example, I have a 90 page document to start...
  1. What is the actual "page number" (not page label, or physical page content, just the number) you are looking at?
  EG: (58)
  image.png
  2. After deleting XX (20) pages, retain view on that page number, if possible:
  EG: (still 58)
  image(1).png
  3. If that page number is no longer available due to the delete action (I will remove another 40 pages), display the last page in the document.
  (EG: the last page in the document, now = 30)
  image(2).png

Technically speaking, #3 doesn't even happen as part of the delete process, it happens natively anytime you try to navigate to a nonexistent page number in a document.

As per your 500 page example, you are not looking at page 500, but at page 434 because that is now the last page in the document and "page 500" does not exist:

image(3).png

In your 1000 page file, you are not looking at page 566, but have remained on page 500:

image(4).png

A the moment, like I mentioned before, there are no current plans to change this function.

Kind regards,

[mCHSNUg5Pz8cPap]

There is no secret formula, or any math at all involved to "calculate" the target page, infact, there are no calculations that happen at all. It is just the visible page number being retained at it is.

This is the part that doesn't make sense. Why are you retaining the page number instead of the page itself (or if the page is deleted the next following page)?

In other words, who thinks to themselves "I always want to view page number 58 regardless what content is on it?" This seems to be the flawed assumption underlying the current behavior.

The guiding assumption should be that people want to keep viewing the page they are already viewing (or if they deleted it, then the next succeeding page), not the page number.

I'm surprised that such an obviously useful and beneficial change is being met with such resistance.

[Daniel - PDF-XChange]

Hello, mCHSNUg5Pz8cPap

The "resistance" comes from having been given a relatively final statement from the dev team on it only a short few months ago. Generally we try to not ask again for things which have been explicitly rejected so recently, unless there is considerable demand for it (opposed to the small but vocal group we see here today).

In such cases, the most I can readily offer is an explanation on the current handling of a given function, and reiterate the decision that was made (please remember, the support team members you interact with here, myself included, are not decision makers within the company).
Despite the poor timing for it, I have once again raised this topic with the dev team, to see if they might have changed their mind on it yet. I cannot make any promises, but I will let you know if there is good news.

Kind regards,

[mCHSNUg5Pz8cPap]

Hello, mCHSNUg5Pz8cPap

The "resistance" comes from having been given a relatively final statement from the dev team on it only a short few months ago. Generally we try to not ask again for things which have been explicitly rejected so recently, unless there is considerable demand for it (opposed to the small but vocal group we see here today).

In such cases, the most I can readily offer is an explanation on the current handling of a given function, and reiterate the decision that was made (please remember, the support team members you interact with here, myself included, are not decision makers within the company).
Despite the poor timing for it, I have once again raised this topic with the dev team, to see if they might have changed their mind on it yet. I cannot make any promises, but I will let you know if there is good news.

Kind regards,

Thanks Dan. We appreciate all that you and the devs do. Ultimately, if the devs don't want to do it, then it is what it is.

[Daniel - PDF-XChange]

[rakunavi]

Hello all, thank you for your comments.

There is no secret formula, or any math at all involved to "calculate" the target page, infact, there are no calculations that happen at all. It is just the visible page number being retained at it is.

This is the part that doesn't make sense. Why are you retaining the page number instead of the page itself (or if the page is deleted the next following page)?

I totally agree with @mCHSNUg5Pz8cPap's thoughts. I know, of course, that the formula is not being used to find the target page. I also understand everything that @Daniel has explained repeatedly. However, I gave an example of the formula to illustrate that if there is no special meaning to retaining the page number, then it is "consequently" equal to finding significance in the number of pages deleted.

We are not asking about the content of the current behavior itself, but how it benefits the user. The only reason I can think of is that it would be easier for developers to implement.

Hopefully one day the developers will change their mind.

Best regards,
rakunavi

[Daniel - PDF-XChange]

Hello, rakunavi

For now, all we can do is wait.


RT#7516: FR: retain visible page after delete

Kind regards,