| Summary: | GS pdfwrite seems to discard PDF destination names | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Masamichi Hosoda <trueroad> |
| Component: | PDF Interpreter | Assignee: | Ken Sharp <ken.sharp> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | P4 | ||
| Version: | 9.19 | ||
| Hardware: | PC | ||
| OS: | Windows 8 | ||
| Customer: | Word Size: | --- | |
| Attachments: |
foo.pdf
-
This contains PDF destination names.
-
foo.gs.pdf - This does not contain PDF destination names. - bar.pdf bar.gs.pdf |
||
|
Description
Masamichi Hosoda
2016-07-22 10:12:58 UTC
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. |