Bug 696943 - GS pdfwrite seems to discard PDF destination names
GS pdfwrite seems to discard PDF destination names
Status: RESOLVED DUPLICATE of bug 695760
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter
9.19
PC Windows 8
: P4 normal
Assigned To: Ken Sharp
Bug traffic
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-07-22 10:12 PDT by Masamichi Hosoda
Modified: 2016-07-23 01:15 PDT (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
foo.pdf - This contains PDF destination names. - (12.02 KB, application/pdf)
2016-07-22 10:12 PDT, Masamichi Hosoda
Details
foo.gs.pdf - This does not contain PDF destination names. - (4.77 KB, application/pdf)
2016-07-22 10:13 PDT, Masamichi Hosoda
Details
bar.pdf (14.85 KB, application/pdf)
2016-07-22 21:58 PDT, Masamichi Hosoda
Details
bar.gs.pdf (6.15 KB, application/pdf)
2016-07-22 21:58 PDT, Masamichi Hosoda
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Masamichi Hosoda 2016-07-22 10:12:58 PDT
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 %%%
Comment 1 Masamichi Hosoda 2016-07-22 10:13:45 PDT
Created attachment 12713 [details]
foo.gs.pdf 
- 
This does not contain PDF destination names. 
-
Comment 2 Ken Sharp 2016-07-22 13:14:05 PDT
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 ***
Comment 3 Ken Sharp 2016-07-22 13:14:24 PDT
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.
Comment 4 Ken Sharp 2016-07-22 13:15:37 PDT

*** This bug has been marked as a duplicate of bug 695760 ***
Comment 5 Masamichi Hosoda 2016-07-22 21:56:34 PDT
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
Comment 6 Masamichi Hosoda 2016-07-22 21:58:03 PDT
Created attachment 12714 [details]
bar.pdf
Comment 7 Masamichi Hosoda 2016-07-22 21:58:26 PDT
Created attachment 12715 [details]
bar.gs.pdf
Comment 8 Ken Sharp 2016-07-23 01:15:29 PDT
(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.