Bug 699830

Please attach a file to reproduce the problem (links tend to disappear), and give a command line to reproduce it - without that, we cannot help.

Please attach example files here, URLs often go stale before anyone has a chance to investigate the problem. Smaller files will be highly appreciated, sending a multiple hundred page file simply means someone has to spend a lot of time to reduce the file to the point where it can be debugged.

You haven't supplied an example command line, you'll need to let us know how you are using Ghostscript.

Ok so I don't know how to do this because I can only replicate for the entire PDF. If I extract one page with links then it may work with ghostscript. But the file is too big to attach. The link is from my dropbox. Let me know what you suggest I do and I will.

I use this command line: gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.7 -dPDFSETTINGS=/prepress -dColorImageDownsampleType=/Bicubic  -dColorImageResolution=150 -sOutputFile=output.pdf input.pdf

I tried with this: gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.7 -dPDFSETTINGS=/prepress -dColorImageDownsampleType=/Bicubic  -dColorImageResolution=150 -sPageList=123 -sOutputFile=output.pdf input.pdf

If I extract one single page that has errors when converting the entire PDF, then it won't show those errors. So I can't extract one page to show you unfortunately. I think it has to do with big PDF files.

(In reply to Tio from comment #4)
> I tried with this: gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite
> -dCompatibilityLevel=1.7 -dPDFSETTINGS=/prepress
> -dColorImageDownsampleType=/Bicubic  -dColorImageResolution=150
> -sPageList=123 -sOutputFile=output.pdf input.pdf
> 
> If I extract one single page that has errors when converting the entire PDF,
> then it won't show those errors. So I can't extract one page to show you
> unfortunately. I think it has to do with big PDF files.

Well, this is a 700+ page file, 160MB in size more or less, and I cna't even find any links in it (I got bored looking at page 35).

The very least you can do is point out a page number which shows a problem. If you absolutely can't find a smaller file I'll look at this one, as time permits. Don't count on a quick resolution.

Created attachment 15704 [details]
ghostscript hyperlinks not working

Created attachment 15705 [details]
ghostscript hyperlinks working

converted with GS 9.23

Ok sorry about this. Of course it exported right since I had gs 9.23. So I am attaching 2 files: output gs923 (is the one that works converted with GS 9.23) and output gs9246 (the one that does not work and it is converted with GS 9.24-6).

Code i used: gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.7 -dPDFSETTINGS=/prepress -dColorImageDownsampleType=/Bicubic  -dColorImageResolution=150 -sPageList=123 -sOutputFile=output.pdf input.pdf

(In reply to Tio from comment #8)
> Ok sorry about this. Of course it exported right since I had gs 9.23. So I
> am attaching 2 files: output gs923 (is the one that works converted with GS
> 9.23) and output gs9246 (the one that does not work and it is converted with
> GS 9.24-6).

No please don't do that, it doesn't help at all.

(In reply to Ken Sharp from comment #9)
> (In reply to Tio from comment #8)
> > Ok sorry about this. Of course it exported right since I had gs 9.23. So I
> > am attaching 2 files: output gs923 (is the one that works converted with GS
> > 9.23) and output gs9246 (the one that does not work and it is converted with
> > GS 9.24-6).
> 
> No please don't do that, it doesn't help at all.

I attached what you asked for: one single page with the error instead of the entire PDF file. I attached 2 actually. 1 PDF file (containing 1 page) that does not work and it was converted with GS 9.24-6, and another similar PDF (same, 1 page) that works as it was converted with GS 9.23. Isn't this what you need?

(In reply to Tio from comment #10)
> (In reply to Ken Sharp from comment #9)
> > (In reply to Tio from comment #8)
> > > Ok sorry about this. Of course it exported right since I had gs 9.23. So I
> > > am attaching 2 files: output gs923 (is the one that works converted with GS
> > > 9.23) and output gs9246 (the one that does not work and it is converted with
> > > GS 9.24-6).
> > 
> > No please don't do that, it doesn't help at all.
> 
> I attached what you asked for: one single page with the error instead of the
> entire PDF file. I attached 2 actually. 1 PDF file (containing 1 page) that
> does not work and it was converted with GS 9.24-6, and another similar PDF
> (same, 1 page) that works as it was converted with GS 9.23. Isn't this what
> you need?

You said you were attaching two files created by Ghostscript. Those don't help, looking at the output isn't helpful.

If you've supplied a file which will cause a problem when run through Ghostscript, then that is helpful. I'm currently in a meeting and will look after it finishes.

Note that there was no Ghostscript release labelled 9.24-6, that must be something produced by the package maintainer for your version of Linux, not us. This does tell me that you aren't using *our* code though. Your using code modified by the package maintainer, which may make it impossible to reproduce your problem.

Created attachment 15706 [details]
Ok I get it now. I attached a PDF file called input.pdf

This file is not converted through GS. You can use it to test it. For me I can replicate if I convert this file using this code: gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.7 -dPDFSETTINGS=/prepress -dColorImageDownsampleType=/Bicubic  -dColorImageResolution=150 -sOutputFile=output.pdf input.pdf

In regards to the version, it is Manjaro's latest version. But people complain about version 9.25 as well https://tex.stackexchange.com/questions/453016/ghostscript-destroys-hyperlinks

Cheers and I am here if you need anything else from me! Thanks

This was a bug fix, the behaviour previously was incorrect, now it is as intended. The Annotations in your PDF file have no /Flags entry, in the absence of that, the default value (0) is used.

This means that bit 3 of the Flags value is 0, from the PDF Reference:

3
Print
(PDF 1.2) If set, print the annotation when the page is printed. If clear, never print the annotation, regardless of whether it is displayed on the screen. This can be useful, for example, for annotations representing interactive pushbuttons, which would serve no meaningful purpose on the printed page. (See implementation note 83 in Appendix H.)

The default behaviour of the Ghostscript PDF interpreter is to be a printer. Since these annotations do not have any effect on a printer, they are dropped.

If you add to the command line -dPrinted=false then the PDF interpreter behaves as a display device instead. Because these annotations don't have NoView set, the PDF interpreter will process them, which means they will end up in the PDF file, when using pdffwrite.

I don't get it though. I simply make these books into LibreOffice Draw and export as PDF, then optimize with Ghostscript and some links work some don't, and I can't figure out why some work some don't. There is nothing special from my perspective about the links that work and those that do not. Can you make it more clear please?

it works with  -dPrinted=false though - thanks for that. I am still baffled as to why some links work and some don't when I add them in the same program and in the same way.

(In reply to Tio from comment #15)
> it works with  -dPrinted=false though - thanks for that. I am still baffled
> as to why some links work and some don't when I add them in the same program
> and in the same way.

If a /Link Annotation has the 'Print' bit of the annotations /Flags value set, then the PDF interpreter will (by default) not process the annotation. If the PDF *interpreter* skips the annotation then the pdfwrite device doesn't ever see it.

If the Annotation (of whatever kind) does set the Print bit, then (again in default setup) the PDF interpreter will process the annotation and pass it to the pdfwrite device.

You can change the behaviour of the interpreter. If you set -dPrinted=false, then the interpreter no longer cares about the Print bit of the annotation flag. In this mode it instead checks the NoView bit, if that isn't set, thenit processes the annotation.

In this case, *if* the NoView bit was set, then the annotation would be skipped.

So you need to know something about the way the annotation has been created, currently.

The reason this is important is that the control (-dPrinted) which was supposed to control whether or not the annotation is processed was being ignored. Obviously that's not the way it was supposed to work, and has been fixed. Its unfortunate that this causes you a problem, and I may well extend the operation of this control in future, but as of now this is behaving as intended.

I wish I knew how to translate that into LO Draw so that I can add the links properly. Right now I have no idea since I add all the links the same way, yet some (as you said) lack something.

*** Bug 699874 has been marked as a duplicate of this bug. ***

*** Bug 699874 has been marked as a duplicate of this bug. ***

*** Bug 699896 has been marked as a duplicate of this bug. ***

*** Bug 701474 has been marked as a duplicate of this bug. ***