PostScript-在PDF中保留内部超链接 [英] PostScript - Preserve internal hyperlinks in PDF
问题描述
我的原始问题 ps2pdf-无法打开初始设备通过@KenS，我遇到了另一个问题，当使用gswin64转换我的PDF时，我的内部超链接(例如见图1")丢失了.这是我的命令:
gswin64 -dPDFSETTINGS=/ebook -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -o output.pdf input.pdf
我上传了原始PDF的最小示例(将在2周后删除)，并且此处已转换的版本.我也从@KenS找到了此答案，关于潜在的可能性来吸引或保留链接，但这只是说一些PostScript编程".是否有另一种或简单的"方式来实现这一目标?我找到了能够做到这一点的在线PDF转换器，因此必须有一种方法.
一些PostScript编程"是指提取链接信息，因为答案说PDF解释器已经这样做是为了pdfwrite设备的好处. >
您的问题是链接注释使用命名目的地:
30 0 obj
<<
/Type /Annot
/Subtype /Link
/Border [ 0 0 1 ]
/H /I
/C [ 1 0 0 ]
/Rect [ 387.470001 700.413025 394.916992 713.314026 ]
/A <<
/S /GoTo
/D (figure.caption.1)
>>
>>
endobj
名称"树包含:
52 0 obj
<<
/Names [ (Doc-Start) 34 0 R (figure.caption.1) 36 0 R (page.1)
33 0 R ]
/Limits [ (Doc-Start) (page.1) ]
>>
endobj
命名的目标fig.caption.1指向对象36:
36 0 obj
<<
/D [ 29 0 R /XYZ 117.828003 696.228027 null ]
>>
endobj
现在，可以通过将对象36的内容放在原始Destination中的fig.caption.1位置上来简化编写，例如:
30 0 obj
<<
/Type /Annot
/Subtype /Link
/Border [ 0 0 1 ]
/H /I
/C [ 1 0 0 ]
/Rect [ 387.470001 700.413025 394.916992 713.314026 ]
/A <<
/S /GoTo
/D [ 29 0 R /XYZ 117.828003 696.228027 null ]
>>
>>
endobj
我认为，后者，更简单的构造将起作用，但是通过名称树的间接作用不起作用.我认为这是因为pdfwrite设备没有保留名称树，因此它不能保留任何依赖名称树的链接.
实际上，我不认为当前代码完全保留了链接注解，而应该这样做，所以我现在来看一下.当我知道更多信息时，我将编辑此答案.
好，这是我忘了的皱纹....
PDF解释器必须以两种不同的方式来处理批注，具体取决于是否打印PDF.参见PDF 1.7参考，第8.4.2节注释标志，位位置3".
如果文件正在打印"，则保留链接注释没有任何意义(到底如何单击打印输出上的链接?).
因此，当Printed为true(这是默认值)时，PDF解释器将不会保留某些类型的注释.您可以通过在命令行上设置-dPrinted=false来轻松更改此设置.
注意某些注释已设置了打印"标志，这就是所有有关的内容.如果将打印"设置为假"，则不会保留设置了打印"标志的注释.如果将Printed设置为true，则将保留那些注释，但不会保留将Print标志设置为0的注释.当前无法让PDF解释器同时保留带有True的注释和带有Print false的注释.在将来的发行版中，可能会对此进行更改，因为人们确实要求这样做.
如果设置-dPrinted=false，则将保留链接注释.我应该注意，它不会与原始PDF文件中的结构相同.它将使用一种更简单的构造，即在Link批注本身中明确声明了目的地，而不是通过名称"树进行间接构造.
效果是相同的，但是它是ps2pdf - Unable to open initial device thankfully answered by @KenS, I ran into another problem, where my internal hyperlinks (e.g. "see Figure 1") are lost when converting my PDF using gswin64. This is my command:
gswin64 -dPDFSETTINGS=/ebook -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -o output.pdf input.pdf
I uploaded a minimum example of the original PDF here (will be deleted after 2 weeks) and the converted version here. I found this answer, also from @KenS, on the potential possibility to exctract or preserve the links, but it just says "some PostScript programming". Is there another or "simple" way of achieving this? I found online PDF converters which are able to do so, so there must be a way.
The 'some PostScript programming' refers to extracting the Link information, as the answer says the PDF interpreter already does this for the benefit of the pdfwrite device.
Your problem is that the Link annotation uses a Named Destination:
30 0 obj
<<
/Type /Annot
/Subtype /Link
/Border [ 0 0 1 ]
/H /I
/C [ 1 0 0 ]
/Rect [ 387.470001 700.413025 394.916992 713.314026 ]
/A <<
/S /GoTo
/D (figure.caption.1)
>>
>>
endobj
The Names tree contains :
52 0 obj
<<
/Names [ (Doc-Start) 34 0 R (figure.caption.1) 36 0 R (page.1)
33 0 R ]
/Limits [ (Doc-Start) (page.1) ]
>>
endobj
The named destination figure.caption.1 points to object 36:
36 0 obj
<<
/D [ 29 0 R /XYZ 117.828003 696.228027 null ]
>>
endobj
Now that could instead have been written much more simply by putting the content of object 36 in place of the figure.caption.1 in the original Destination, eg:
30 0 obj
<<
/Type /Annot
/Subtype /Link
/Border [ 0 0 1 ]
/H /I
/C [ 1 0 0 ]
/Rect [ 387.470001 700.413025 394.916992 713.314026 ]
/A <<
/S /GoTo
/D [ 29 0 R /XYZ 117.828003 696.228027 null ]
>>
>>
endobj
I think that the latter, simpler construct would work, but indirection through the names tree does not. I think this is because the pdfwrite devcie doesn't preserve the Names tree, so it can't preserve any links which rely on the Names tree.
In fact, I'm not convinced the current code preserves Link annotations at all, which it should, so I'm looking at that now. I'll edit this answer when I know more.
[EDIT]
OK so this is a wrinkle I had forgotten....
The PDF interpreter has to treat annotations in two different ways, depending on whether the PDF is being printed or not. See the PDF 1.7 Reference, section 8.4.2 Annotation Flags, bit position 3.
If the file is being 'Printed' then there is no point in preserving Link annotations (how on earth would you click a link on the printed output ?).
So when Printed is true, which is the default value, then the PDF interpreter doesn't preserve certain kinds of annotations. You can alter this quite easily by setting -dPrinted=false on the command line.
NOTE Some annotations have the 'Print' flag set, which is what this is all about. If you set Printed to 'false' then annotations which have the 'Print' flag set will not be preserved. If you set Printed to true then those annotations will be preserved, but annotations which have the Print flag set to 0 will not be preserved. There is currently no way to have the PDF interpreter preserve both annotations with Print true and ones with Print false. This is likely to be changed in a future release because people do ask for it.
If you set -dPrinted=false, your Link annotation will be preserved. I should note that it will not be the same construction as was in your original PDF file. It will use the simpler construction where the destination is explicitly stated in the Link annotation itself, rather than indirecting through the Names tree.
The effect is the same, but its an example of the kind of thing which is described in the documentation. I presume this won't be a problem for you though.
Given the way the original file is constructed, I'm not surprised that the pdfwrite output is smaller! For some reason this file contains eight Forms, eight shadings and two colour spaces (one of which is empty) none of which appear to actually be used....
这篇关于PostScript-在PDF中保留内部超链接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
