Created attachment 12753 [details] PDFs and sources If I understand correctly, GS pdfwrite seems to rewrite /GoToR's destination names /D. I'd like GS does not break them. `dest.pdf' has the following destinations. Due to bug 694943 etc., I do not use GS for this file. <</Names[<feff00300031>13 0 R<feff00300032>14 0 R<feff006600fc0072>15 0 R]>> `link.pdf' has the following /GoToR links. All links work fine with Adobe Acrobat Reader DC. <</S/GoToR/F(dest.pdf)/D<feff00300031>>> <</S/GoToR/F(dest.pdf)/D<feff00300032>>> <</S/GoToR/F(dest.pdf)/D<feff006600fc0072>>> On the other hand, `link.gs.pdf' is generated by the following command. $ gs -q -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=link.gs.pdf link.pdf `link.gs.pdf' has the following /GoToR links. <</S/GoToR /D/\376\377\0000\0001 /F(dest.pdf)>> <</S/GoToR /D/\376\377\0000\0002 /F(dest.pdf)>> <</S/GoToR /D/\376\377\000f\000\374\000r /F(dest.pdf)>> All links do not work fine. I suspect this cause is GS rewrite /GoToR's destination names /D from `/D<feff00300031>' to `/D/\376\377\0000\0001'. So I've tried to rewrite `link.gs.pdf' by hand. `link.gs.paren.pdf' has the following /GoToR links. <</S/GoToR /D(\376\377\0000\0001)/F(dest.pdf)>> <</S/GoToR /D(\376\377\0000\0002)/F(dest.pdf)>> <</S/GoToR /D(\376\377\000f\000\374\000r)/F(dest.pdf)>> All links work fine. Moreover, `link.gs.hex.pdf' has the following /GoToR links. <</S/GoToR /D <FEFF00300031> /F(dest.pdf)>> <</S/GoToR /D <FEFF00300032> /F(dest.pdf)>> <</S/GoToR /D <FEFF006600FC0072> /F(dest.pdf)>> Also, all links work fine. I'd like GS uses `/D(\376\377\0000\0001)' or `/D <FEFF00300031>' instead of `/D/\376\377\0000\0001'.
(In reply to Masamichi Hosoda from comment #0) > If I understand correctly, GS pdfwrite seems to rewrite /GoToR's destination > names /D. pdfwrite does not exactly 'rewrite' anything. However, the output of pdfwrite bears no relation to the input to Ghostscript, this is discussed in the Overview in VectorDevices.htm > `dest.pdf' has the following destinations. > Due to bug 694943 etc., I do not use GS for this file. I'm unsure what relevance valgrind reports in the OpenJPEG jpeg2000 decoder have to your point here. > I'd like GS uses `/D(\376\377\0000\0001)' or `/D <FEFF00300031>' > instead of `/D/\376\377\0000\0001'. Well until recently we didn't preserve GoTo or GoToR at all. Looks like we are trying to write the output as a name object but using string escapes, which clearly isn't going to work.
The reason we were converting Dests into names is because PDF versions prior to 1.2 do not support string Dests. Commit 1e214a7382f35f52ae1efe2b53169704913e4df5 only converts Dests to names when producing versions below 1.2 and checks the string to see if it can be so represented, if not it throws an error and ignores the Dest.
(In reply to Ken Sharp from comment #1) > > `dest.pdf' has the following destinations. > > Due to bug 694943 etc., I do not use GS for this file. > > I'm unsure what relevance valgrind reports in the OpenJPEG jpeg2000 decoder > have to your point here. Sorry, it's bug 696943. (In reply to Ken Sharp from comment #2) > The reason we were converting Dests into names is because PDF versions prior > to 1.2 do not support string Dests. > > Commit 1e214a7382f35f52ae1efe2b53169704913e4df5 only converts Dests to names > when producing versions below 1.2 and checks the string to see if it can be > so represented, if not it throws an error and ignores the Dest. It seems to work fine for me. Thank you very much.