I have pdf file with bookmarks/outlines which points to other pdf files specific pages. I'm able to open them in Adobe, edit destination targets resave them and everything seems to work correctly. But when I process any of those files with GS, target file information is lost and bookmark points to same file. Tested it with GS 9.05 and 9.06 GS command is: gswin32c.exe -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH "-sOUTPUTFILE=out.pdf" -c "64000000 setvmthreshold" -f input.pdf Included the files. Regards Jacek Bator
Created attachment 9051 [details] Input file
Created attachment 9052 [details] Output file
(In reply to comment #0) > them and everything seems to work correctly. But when I process any of those > files with GS, target file information is lost and bookmark points to same > file. The pdfwrite device does not 'process' PDF files, it completely interprets them, creates a series of graphical operations, then rewrites those operations as a brand new PDF file. The only relationship between the original and created PDF file is that they should have the same visual appearance. Since GoToR (and other metadata) has no visual appearance, the metadata is not normally carried forward. Certain kinds of information are converted by the PDF interpreter into pdfmark operations which allows them to be preserved, the GoToR annotation is not one of these. Altering to an enhancement, up to Alex whether we try to preserve these or not.
> Certain kinds of information are converted by the PDF interpreter into pdfmark > operations which allows them to be preserved, the GoToR annotation is not one > of these. > > Altering to an enhancement, up to Alex whether we try to preserve these or not. Thank you for the information. I though it was an error because URI action is preserved and GS version 5.21 was fixing something about GoToR (change log states that) Regards Jacek Bator
(In reply to comment #4) > Thank you for the information. I though it was an error because URI action is > preserved and GS version 5.21 was fixing something about GoToR (change log > states that) The URI action is easier to handle, because when we process a page, the target URI of the link does not change. For GotoR, that is not the case; suppose we have a 10 page document with a link on page 1 pointing to page 10. At the time at which we process page 1, we have no way of knowing that page 10 will be the 10th page we process (or indeed that page 10 will ever be processed) - we might be reordering or subsetting the file. To preserve GotoR you really need to be using a tool that operates at a higher level.
I'm little bit lost here. My understanding was different. Ex. You have two Pdf files. first.pdf and second.pdf. In first.pdf you have link that leads to 5ft page in second.pdf. 5ft page reference is only page index (not object id) and you are not processing second.pdf file at all so no point to worry about second.pdf file content. I don't see a point to create GoToR actione for same/single file only. Regards Jacek Bator
(In reply to comment #6) > I'm little bit lost here. My understanding was different. > > Ex. You have two Pdf files. first.pdf and second.pdf. > > In first.pdf you have link that leads to 5ft page in second.pdf. > 5ft page reference is only page index (not object id) and you are not > processing second.pdf file at all so no point to worry about second.pdf file > content. > > I don't see a point to create GoToR actione for same/single file only. > > Regards > Jacek Bator So basically GoToR for me is same as URI but "uri" part must point to pdf file and additionaly you have page index to be presserved.
GoToR has a corresponding pdfmark parameter and can be exported by the PDF interpreter. However, conversion to pdfmark and back is a long and convolved path for the simple data. Perhaps, we can extend the syntax to pass the data directly.
commit 8425cde6e55dfaa26e64e81f54e044187fb98384 should fix this one.