Import bookmark - Can't go to page destination

[Loki@99]

Hi,

There's an issue with the import bookmark feature.

Steps to reproduce
1. Export all bookmarks from this file

File_Bookmark source.pdf

2. Import the exported bookmark into this other file

File_Sample.pdf

3. Select a bookmark "Preface, Introduction..."

Issue
Go to destination action not working

issue_bkm.gif

Additional info
No issue with Foxit PDF

Thanks for investigating,

[rakunavi]

Hello Loki@99,

The "Export Selected/All Bookmarks" command in the Options menu of the Bookmarks pane exports bookmarks exactly as they are if a named destination is specified for the bookmark target. Therefore, if only a bookmark is imported and there is no named destination corresponding to the bookmark target, the page will not be displayed even if the bookmark is selected.

In Foxit PDF Editor, if the bookmark target is a named destination, the bookmark will be converted to a page number when the bookmark is exported. To do the same thing in PDF-XChange Editor, you need to combine the "Export Bookmark(s) to Text File" feature with the "Generate Bookmarks From Text File" feature. Note that the "Resolve named destinations to page number" option must be enabled in the "Export Bookmark(s) to Text File" dialog.

• figure.png

You should get basically the same results with PDF-XChange Editor as you did when importing bookmarks with Foxit PDF Editor. However, if the dark theme UI is set up, it will not match perfectly because of the color issue reported earlier in this topic.

• PDFXCE.gif

I understand that the steps for exporting and importing bookmarks in Foxit PDF Editor are as follows. It is true that you can import, but as long as you use this method, the bookmark target does not seem to correspond to the content of the document. For your reference, I am attaching the verification video, the bookmark file generated in the video, and the file with it applied to the document.

• Animation.gif

• SampleFiles.zip

Additional info
No issue with Foxit PDF

If your export and import procedure differs from the procedure I have shown, and if the bookmark targets correspond correctly to the content of the document, I am interested to know how it operated.

Best regards,
rakunavi

[Loki@99]

Hi @rakunavi

Thanks for your input.

Exporting and importing bookmark from the Ribbon as a .txt file format doesn't reproduce the issue.

This issue should be addressed to the Export All Bookmarks... in Bookmarks panel as a .xcbkm file then.

image.png

[Daniel - PDF-XChange]

Hello, Loki@99

Thank you both for bringing this up. At this time, the issue is most certainly caused by the lack of named destinations present in the target file:

image.png

I have informed the Dev team of this, asking to either allow a "convert destinations to page number" or enable the full controls much like export to text files offers for this button through the pane.

Which options we see will depend on the Dev team, but they are aware of this and should be looking into it shortly.

RT#7011: FR: "Bkm pane > options > export all bookmarks", convert N.Dest to page number.

Kind regards,

[rakunavi]

Hello Tracker Support,

According to the version history, build 388 has made the following changes to the feature discussed in this topic.

• Build 10.4.0.388 Bugfixes and Improvements
  Added a 'Convert Named Destination Data to Page Number Data' option in the 'Go To Page' action when exporting bookmarks. (T# 7011) (43121)

I can't find the option anywhere, can you tell me where to set it?

If this option does not exist, then exporting and importing bookmarks where the named destination is set as the destination for the Go To Page action would be converted to Page Number Data without asking the user what to do with it, which would be very inconvenient.

In that case, it is probably the developer's intention that if you want to specify details in the export or import, please do so in text file format. In that regard, build 388 solves the color problem when importing in text file format, which may be a workaround, but I have not had enough time to test it yet, so I do not know if I can put full confidence in exporting or importing in text file format.

[EDIT: 26 Sep 2024] In my first post, I mistakenly thought that build 388 solved the color problem, and I stand corrected.

Best regards,
rakunavi

- PDF-XChange Editor Plus Version: 10.4.0 build 388
- OS Version: Windows 11 Home 23H2 Build 22631.4037
- PC Model: Lenovo IdeaPad C340-15IWL, HP All-in-One 22-c0xx

[Daniel - PDF-XChange]

Hello, rakunavi

Thank you for the report, It does appear that this was added without an "option" but simply as the default, with that said, I see from the ticket notes that it was intended to export both the page number and destination. The following import should only apply the page number when the target document that does not contain a destination matching a given bookmarks name. As I can see, even just coppy/paste of a bookmark inside the same document (which should contain the destination in question), also converts it to page number.

This appears to be a bug, so I will be following up with the Dev team for a resolution.

Kind regards,

[rakunavi]

Hello Daniel, thank you for your reply. Welcome back from your two-week summer vacation.

As I can see, even just coppy/paste of a bookmark inside the same document (which should contain the destination in question), also converts it to page number.

I just noticed that build 388 now converts bookmarks as soon as they are copied, just as you said. This is extremely annoying, not only when copying the same document, but also when pasting them into another document. This is the most damaging change in build 388 for me personally. I will have to redo all the work I have done for the past two weeks because of this change, and frankly, it's a bit daunting. I highly doubt that any user will be happy with this change in behavior.

I am probably one of the most prolific users of named destinations on this forum, and I find this rash change very troubling. I had a bad feeling about this topic when it was created and commented on it beforehand, but I am appalled that it was disregarded and that the change affected copies that I did not expect.

If you had come back two weeks earlier, I would not have had to perform the work in vain from now on.

Best regard,
rakunavi

[Daniel - PDF-XChange]

Hello, rakunavi

I am terribly sorry For the delay, I was out on my summer vacation, which happened to coincide with the release. I have only just returned today... Nonetheless, I have no clue why none of my colleagues attended to this while I was out, but you should have seen a proper investigation and response much sooner. This report took me no more than 10 minutes to dig into.

With that said, there were very clear notes in the ticket, specifically, this was originally created as a request for options during the import action. How it was misunderstood to be on export I beyond me.
It also includes a clarification from our UI lead, after he and I discussed the worries you raised. He stated this should be implemented in a way to avoid these issues entirely, and that is on record in our ticketing system as well. I know that does nothing to help mitigate the issues you have seen until now, but I am doing my best to ensure the team is aware this needs a swift resolution. If nothing else, I will be asking our UI lead to revert this change in build 389 if this cannot be fixed immediately.

I hope that you are able to recover from the trouble that this change caused, In the meantime, you may wish to roll back to build 387, just to prevent any further errors.

Kind regards,

[Vasyl - PDF-XChange]

We have fixed this bug in an upcoming build. Sorry for the inconvenience...

[rakunavi]

Hello Daniel and Vasyl, thank you for your super fast response.

@Daniel
I think the rest of the staff knew about the existence of above post, as I had casually mentioned it at the end of this post. That must be how much they trusted your knowledge and experience and relied on you to do the work of replying. The future of PDF-XChange Editor rests on your shoulders.

Anyway, I am relieved that I am not the only one who likes the way build 387 works. I am sure that adding or changing features can have unforeseen consequences as in this case, but I support the developers' relentless challenge, because if we are concerned about the risk, we will not be able to move forward. I will continue to contribute in my own small way by reporting as accurately as possible.

I wish PDF-XChange Editor continued evolution.

Best regards,
rakunavi

[rakunavi]

=== UPDATE ===================================================================
The issue reported below has been resolved in Ver 10.4.3 build 391.
I appreciate all the hard work and efforts of the support and development team.
==============================================================================

Hello Daniel and Vasyl,

I installed build 389, which has just been released, and unfortunately found that it did not fix the problem at all. As I underlined in my earlier post, I was concerned that there might be a lack of attention to named destinations for external files, and that concern seems to have come true.

I suspect that you have no idea what the problem is in the first place. Please review the following brief verification scenario.

The following verification procedure uses three files DocumentA.pdf, DocumentB.pdf, and DocumentC.pdf with a named destination on each page. DocumentA.pdf has bookmarks to each page of the three files with GotoR action. In the video, for each of build 387 and build 389, the bookmarks in DocumentA.pdf are copied using Ctrl+C and pasted into DocumentB.pdf and DocumentC.pdf using Ctrl+V respectively. Then check that the links on each page work. That's all there is to it.

• SampleFiles.zip

Build 387

• Here is a video of the verification on build 387. Of course, all the bookmarks work fine.
  
  
  • Animation1.gif
  Exporting the bookmarks as text files also shows that all bookmark destinations are set as named destinations in DocumentB.pdf and DocumentC.pdf.
  
  
  • figure3.png

Build 389

• In contrast, here is a video of the verification in build 389 Unfortunately, bookmarks to DocumentC.pdf in DocumentB.pdf and to DocumentB.pdf in DocumentC.pdf do not work.
  
  
  • Animation2.gif
  The following is the result of exporting the bookmarks as a text file. Bookmarks with red markers are not working at all. The bookmarks in the yellow markers work, but the named destinations are replaced by page numbers on their own.
  
  
  • figure1.png
    
    
    figure2.png

I sincerely hope that my concerns are accurately conveyed to you.

As soon as I said in yesterday's post that I wanted to catch a big fish, I seem to have immediately caught a huge fish. The thought of having to wait another few months for build 390 to appear is daunting. But that may still be short compared to waiting two and a half years, or even four and a half years.

Best regards,
rakunavi

- PDF-XChange Editor Plus Version: 10.4.1 build 389
- OS Version: Windows 11 Home 23H2 Build 22631.4169
- PC Model: Lenovo IdeaPad C340-15IWL, HP All-in-One 22-c0xx

[Daniel - PDF-XChange]

Hello, rakunavi

Indeed, This looks to be exactly how I feared it would come out... My apologies, as it was likely a miscommunication on my end. It was a very last minute change, and not one which had time for an extended breakdown.

I had tried to request that the team revert the change back to the 387 handling, so we can go back to the drawing board on this feature, but it seems that the team wanted to try and fix the issues I touched on in passing (I should have continued listing more of them).

I have already followed up with the team, leading them directly to your post here. Hopefully they will have some better solutions for the next release, as you said though, this could be some time away.

[Update]: A further discussion and we have a new bug ticket for the handling of external files specifically:
RT#7120: Bug: Bookmark w/ Name-Dest, external file handling error

Kind regards,

[Vasyl - PDF-XChange]

As a temporary solution, you can use DnD instead of Copy/Paste, especially for copying bookmarks between different documents.
It seems to work as you want...

[rakunavi]

Hello Daniel and Vasyl,

@Daniel
Thank you for creating the ticket and communicating between your departments to resolve the issue.

@Vasyl
Thank you for sharing the workaround. For the time being, I will get by with drag-and-drop.

Best regards,
rakunavi

[Daniel - PDF-XChange]

[Loki@99]

Hi,

I noticed that there is still an issue with the feature

Steps to reproduce
1. Export all bookmarks as .xcbkm from this file

Source BK.pdf

2. Import the exported bookmark into this other file

Target BK.pdf

3. Select bookmark "Table des matières or Auteurs"

Unfortunately I can't provide the original files as they are pretty large (200MB). I hope that you will still understand the issue by looking at the Page navigation numbers value on bottom bar.

Issue
Go to destination action not working. See page navigation numbers value not changing

Additional info
- Some bookmarks like "Abréviations" works
- No issue when exporting as TXT
- Those files have custom pages number so it's likely what's causing the issue

Thanks for investigating,

[Daniel - PDF-XChange]

Hello, Loki@99

thank you for that, I see the same here, and have passed this along to the Dev team for review.

Kind regards,

[Vasyl - PDF-XChange]

It occurs in the latest 389 build, correct?

[Daniel - PDF-XChange]

Hello, Vasyl-Tracker Dev Team

Yes, I can reproduce it locally as well when running 389.

Kind regards,

[rakunavi]

Hello Vasyl,

I checked the bookmark object corresponding to "Table des matières" in "Source BK.pdf" provided by Loki@99 and found the following.

Code: Select all

14 0 obj 
<<
/Title (Table des matières)
/Parent 3 0 R
/Dest (toc_1)
/Next 15 0 R
>>
endobj 

On the other hand, when I specify a named destination as a GoTo action for a bookmark in the PDF-XChange Editor, I get the following.

Code: Select all

15 0 obj 
<<
/Title (Table des matières)
/Parent 3 0 R
/A 
<<
/D (toc_1)
/S /GoTo
>>
/Prev 14 0 R
>>
endobj 

In the former case, as Loki@99 and Daniel say, the named destination is not converted to a page number, but in the latter case, as Vasyl says, the named destination is converted to a page number. In other words, it may be that if a named destination is specified using the /Dest tag without an action, it is not converted to a page number, but if specified with an action using the /D tag, it is.

I commented because I was a little concerned about the difference of opinion. I am sorry if my comment was out of point.

Best regards,
rakunavi

[Daniel - PDF-XChange]

Hello, rakunavi

No worries, the difference in the export format there could well be related. I will make sure Vasyl sees that.

Kind regards,

[rakunavi]

Hello Daniel, thank you for your comment.

I did not report the result by examining the Bookmarks Export File (*.xcbkm), but by examining the PDF file itself. I try to analyze and report issues by eliminating other factors as much as possible.

A minor detail, but I value accuracy in posting as much as you do.

Best regards,
rakunavi

[Daniel - PDF-XChange]

Hello, rakunavi

Thank you for that correction, I spend very little time digging into the internals of the files themselves, and am most often stuck on surface level testing, once it reaches a certain depth, I call in the big guns. I have followed up to my previous message mentioning there was an error in my assumptions there.

Kind regards,

[rakunavi]

=== UPDATE ===================================================================
The issue reported below has been resolved in Ver 10.4.3 build 391.
I appreciate all the hard work and efforts of the support and development team.
==============================================================================

Hello Daniel, thank you for your comment.

I have created a table that gives an overview of the problems with the GoTo/GoToR action list from build 388 to build 390.

For all builds 387 through 390, bookmarks were created and exported in text format for the three files (Document A.pdf, Document B.pdf, and Document C.pdf) in the root directory of the attachment according to the following procedure.

• SampleFiles.zip

Document A has bookmarks with GoTo/GoToR actions destined to page numbers and named destinations; Document B has pre-set named destinations; Document C has no named destinations. The purpose of this report is to export the bookmarks from Document A, import them into the three documents using the exported file, and compare the results.

• Document A
  1. "Export All bookmarks" from the options menu in the Bookmarks pane to make a Bookmarks Export File (Document A.xcbkm).
  2. Delete all bookmarks.
  3. From the File tab, run the "Save as" command to save the file as "Document A.pdf" under the same folder name as the build number.
  4. From the Bookmarks tab, open the "Export Bookmarks(s) to Text File" dialog and save the file as "Document A.txt" under the folder name of the build number according to the following settings
     
     
     • dialog.png
  Document B
  1. Import the Bookmarks Export File (Document A.xcbkm) created above by selecting "Import bookmarks" from the options menu in the Bookmarks pane.
  2. From the File tab, use the "Save as" command to save the file as "Document B.pdf" under the same folder name as the build number.
  3. From the Bookmarks tab, open the "Export Bookmarks(s) to Text File" dialog and save the file as "Document B.txt" under the same folder name as the build number.
  Document C
  1. Import the Bookmarks Export File (Document A.xcbkm) created above by selecting "Import bookmarks" from the options menu in the bookmarks pane.
  2. From the File tab, use the "Save as" command to save the file as "Document C.pdf" under the same folder name as the build number.
  3. From the Bookmarks tab, open the "Export Bookmarks(s) to Text File" dialog and save the file as "Document C.txt" under the same folder name as the build number.

• Animation.gif
  
  
  figure.png

In the table, areas highlighted in yellow are bookmarks that have been changed as a result of requests made on this topic (this change is extremely annoying to me personally). Areas highlighted in red are bookmarks that do not work at all. Incidentally, the problem with build 390 is so serious that I have reported it in the following new topic.

• [build 390] GoToR action "Go to a Page in Another Document" to a named destination does not work at all
  viewtopic.php?t=44143

Hoping that the above information will be of some help to you.
Thank you so much for your continued support.

Best regards,
rakunavi

- PDF-XChange Editor Plus Version: 10.4.2 build 390
- OS Version: Windows 11 Home 23H2 Build 22631.4317
- PC Model: Lenovo IdeaPad C340-15IWL, HP All-in-One 22-c0xx

[Daniel - PDF-XChange]

Hello, rakunavi

I am sorry for the delay, the team has been quite busy with tasks relating to this release. I know there are a handful of known issues in relation to these features that are ongoing right now, including a few we discovered internally. I have just forwarded this to our Dev team for review and confirmation if this is one of those known issues that is seeing a fix soon, or if this is another one which will need further testing to address.

Kind regards,

[rakunavi]

=== UPDATE ===================================================================
The issue reported below has been resolved in Ver 10.4.3 build 391.
I appreciate all the hard work and efforts of the support and development team.
==============================================================================

Hello Daniel, thank you for contacting developers and taking time out of your busy schedule.

I am very concerned that the changes triggered by this topic have resulted in a series of bugs in multiple builds, eventually leading to a complete loss of functionality for bookmarks with named destinations as GoToR actions in build 390.

To begin with, the recent change seems to be proceeding on the assumption that many users want to convert to page numbers when the GoTo/GoToR action in the bookmark file to be exported contains a named destination. Is this really the case?　If you blindly change the destination to a page number just because the named destination does not exist at the time in the file that is the destination of the named destination, it will not reflect the intent of the author who had the named destination as the destination. This is also related to the problem I reported in the following topic regarding named destinations.

• Deleting a page when a named destination is set as target of a bookmark will also delete GoTo action for the bookmark
  viewtopic.php?t=43140

Even if the named destination does not exist at the time, a named destination can be set up later, and the action for the named destination will work again. However, once the named destination is converted to a page number, it will no longer have any relation if pages are moved, added, or deleted in the file.

It is my sincere wish that when an action specifies a named destination, the author's intent should be respected to the greatest extent possible, and that the destination should be kept intact. Named destinations should be set separately by the user, either before or after the fact. If there is room for improvement, it would be to add new export and import functions for named destinations.

For reference, I used the Foxit PDF Editor to export and import bookmarks for three documents using exactly the same procedure as I did for the PDF-XChange Editor. Each of the resulting PDF files was opened in PDF-XChange Editor build 387, the bookmarks were exported to a text file, and a table summarizing them is shown below.

• chart_foxit.png
  
  
  FOXIT.gif

• SampleFiles-Foxit.zip

As in the previous table, the yellow markers are areas where the named destinations have been converted to page numbers, and the red markers are areas where the bookmarks no longer function at all. Compared to the results imported with build 387, which I consider ideal, the results imported with Foxit PDF Editor, which Loki@99 probably considers ideal, seem disastrous in terms of respecting the raison d'etre of named destinations. What are your thoughts on this?

The PDF-XChange Editor provides three functions related to this topic.

1. Export Bookmarks to Text File
   https://help.pdf-xchange.com/pdfxe10/in ... le_ed.html
2. Commands present in the Options menu of the Bookmarks pane
   (Import Bookmarks / Export Selected Bookmarks / Export All Bookmarks)
   https://help.pdf-xchange.com/pdfxe10/in ... ks_ed.html
3. Convert Named Destinations to Regular Destinations
   https://help.pdf-xchange.com/pdfxe10/in ... ns_ed.html

To Loki@99's first question I suggested using the first "Export Bookmarks to Text File" dialog, but you can also do the third "Convert Named Destinations to Regular Destinations" and then apply the second "Export All Bookmarks" and "Import Bookmarks". The PDF-XChange Editor offers a rich set of features which, at least up to build 387, could be used to achieve any goal the user wishes. And there was a deep understanding and love of named destinations.

• pane.png

In contrast, the Foxit PDF Editor offers only the equivalent of the second feature (confirmed in Version 13.1.2.22442). Since it is not possible to specify details in the options, the second function is forced to include a mechanism to convert GoTo actions with named destinations to page numbers. As you can see from the above test results, bookmarks are lost for GoToR actions, regardless of whether the destination is a page number or a named destination, and compared to PDF-XChange Editor, there is no love for named destinations at all.

I don't know if this is a good analogy, but PDF-XChange Editor is like coffee from an long-established coffee shop and Foxit PDF Editor is like ready-made bottled coffee. The PDF-XChange Editor allows customers to add sugar and milk later, according to their own preferences. Foxit PDF Editor, on the other hand, is pre-mixed with sugar and milk, so it cannot accommodate the customer's precise preferences. Once the sugar and milk are mixed, they cannot be undone.

Once the named destination is converted to a page number, the information is lost and cannot be restored. In this sense, the build 387 behavior is like coffee from an long-established coffee shop. The Loki@99 proposal has turned some of them into ready-made bottled coffees.

As the saying goes, "when in Rome, do as the Romans do." Every application has its own culture. In this case, it seems to me that PDF-XChange Editor, which offers three features, loses the greatness of PDF-XChange Editor by forcing it to conform to the behavior of Foxit PDF Editor, which covers everything with just one feature. Loki@99 also requests in this topic to reduce PDF-XChange Editor's functionality by using Foxit PDF Editor's implementation as an example, but it's not a good idea to adapt everything to Foxit PDF Editor.

As with this topic, why should existing users spend so much time and effort to prevent the great features of PDF-XChange Editor from being destroyed suddenly one day? Can't we be allowed to enjoy a nice cup of coffee on the terrace of the coffee shop with a little more peace of mind? I can only hope that the taste of the long-established coffee shop's build 387 recipe will be restored before it is scattered.

We are not beta testers.

Best regards,
rakunavi

[Daniel - PDF-XChange]

Hello, rakunavi

Thank you for the eloquent summary, This is not something we are planning to just "leave as is" in the current state. Yes, you are correct the recent releases trying to tweak this have been problematic, but the simple truth is every application has days where a feature does not work as the Developers intended, or a miscommunication results in a feature being implemented in not quite the right way. While we have tried out best to resolve these items in a timely manner, they are exceedingly complex, and while I dislike making excuses, the team members most familiar with many of these areas are located in Ukraine, Fighting for their lives, and worrying about their friends and families.

We are in a way reverting back to the 387 handling as the default, for the next release, with an optional toggle to enable a new iteration of the current handling, I just finished helping with a grammar check on the text for that toggle, which should be present in build 391:

Option Title:
Resolve unknown named Dest. on Import/Paste

Tooltip:
When Enabled - On import or paste of bookmarks, the application checks any pointing to a named destination and replaces all invalid destinations (Which do not exist in the target document) with page target equivalents.
When Disabled - such invalid actions are preserved as they are.

As you can surmise, when disabled this will go back to the previous handling, and when enabled, this will allow for the new handling, with some additional refinements, to be accessible.

In summary, you will have the option to order your choice of either the Classic cup of coffee you know and love, or a cup with the new brew, from a more reliable supplier.

I sincerely apologize that you feel you have had to act as beta testers in this endeavor, that was not our intent, but I cannot deny the past 3 releases have been a bit of a roller coaster for this feature.

Kind regards,

[rakunavi]

Hello Daniel, thank you for your heartfelt reply.

I have confirmed that all the issues I reported have been fixed in build 391 released today. Also, thank you for providing an option that works as well as build 387.

I am very pleased, as at one time I feared that build 387 would be the last build for me. Given the very short time interval between releases, I can imagine that you worked very hard on this release. I would like to thank everyone involved and wish the Tracker staff all the best in getting back to their peaceful days.

Best regards,
rakunavi

[Paul - PDF-XChange]