Created attachment 12712 [details] foo.pdf - This contains PDF destination names. - If I understand correctly, GS pdfwrite seems to discard PDF destination names. I'd like to let GS keeps them. `foo.pdf' contains PDF destination names. Web browser with something like the following URL can show the second page of the PDF. http://example.com/foo.pdf#two Then, I've tried GS pdfwrite as following command. $ gs -q -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=foo.gs.pdf foo.pdf It can reduce the file size. However, the following URL can not show the second page of the PDF. http://example.com/foo.gs.pdf#two In other words, `foo.gs.pdf' does not contain PDF destination names. I'd like to let `foo.gs.pdf' contains them. How can I achieve it? Here is the source of `foo.pdf'. %%% foo.tex %%% % The following command generates `foo.pdf'. % $ pdftex foo.tex \pdfobjcompresslevel=0 \pdfdest name{one} xyz page 1 \vfill \eject \pdfdest name{two} xyz page 2 \vfill \end %%% foo.tex %%%
Created attachment 12713 [details] foo.gs.pdf - This does not contain PDF destination names. -
The file contains named Destinations, but does not use them (nothing seems to reference them at all). Please read the Overview in ghostpdl/doc/VectorDevices.htm for a description of how pdfwrite works. At present, because nothing uses these Destinations, the PDF interpreter does not need to process them and so the Dests are not turned into pdfmarks and passed to the pdfwrite device. If you file actually referenced any of the named Destinations, then the ones which were used would be preserved. There is already an enhancement bug open (#695750) to make more effort to preserve named Destinations. *** This bug has been marked as a duplicate of bug 695750 ***
The file contains named Destinations, but does not use them (nothing seems to reference them at all). Please read the Overview in ghostpdl/doc/VectorDevices.htm for a description of how pdfwrite works. At present, because nothing uses these Destinations, the PDF interpreter does not need to process them and so the Dests are not turned into pdfmarks and passed to the pdfwrite device. If you file actually referenced any of the named Destinations, then the ones which were used would be preserved. There is already an enhancement bug open (#695750) to make more effort to preserve named Destinations.
*** This bug has been marked as a duplicate of bug 695760 ***
Thank you for your answer. But, even if a PDF uses names, GS seems to discard the destination names. `bar.pdf' contains PDF destination names and uses them. The following URL works fine. http://example.com/bar.pdf#two The following URL does not work fine. http://example.com/bar.gs.pdf#two `bar.gs.pdf' does not contain PDF destination names. Here is the source of `bar.pdf'. %%% bar.tex %%% % The following command generates `bar.pdf'. % $ pdftex bar.tex \pdfobjcompresslevel=0 \pdfdest name{one} xyz page 1 link \pdfstartlink goto name{two} Jump to two \pdfendlink \vfill \eject \pdfdest name{two} xyz page 2 link \pdfstartlink goto name{one} Jump to one \pdfendlink \vfill \end %%% bar.tex %%% The following command generates `bar.gs.pdf'. $ gs -q -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=bar.gs.pdf bar.pdf
Created attachment 12714 [details] bar.pdf
Created attachment 12715 [details] bar.gs.pdf
(In reply to Masamichi Hosoda from comment #5) > Thank you for your answer. > > But, even if a PDF uses names, GS seems to discard the destination names. > `bar.pdf' contains PDF destination names and uses them. It uses the named destinations in annotations, the pdfwrite device 'dereferences' the names and includes specific destination information in the final annotation. The result PDF file works exactly the same as the original, the difference is merely in how the information is represented in the PDF file. As is described in the OverView in VectorDevices.htm. As I also stated, this is a duplicate of 695760, where I point out that a GotoR from one PDF to another will not work because the named destinations are not preserved. A URL is exactly the same.