Created attachment 15778 [details] uncompressed pdf Compressing a pdf with GS version 25 removes all the anchor links in the document. Versions prior work. The first page in my simplified example has a destination to link to, the second page has an anchor tag to the first page. Our raw pdf has been generated using ruby and PrawnPdf I've attached the raw, uncompressed pdf as a test. I could only add one attachment here. The compression level does not seem to be a factor here. Happens on the Linux and Mac versions for us. > gs -dBATCH -dNOPAUSE -o link_test_compressed.pdf -sDEVICE=pdfwrite -dQUIETlink_test.pdf
Created attachment 15779 [details] broken anchor tag example
*** This bug has been marked as a duplicate of bug 699830 ***
Thanks Ken for clearing that up. I've added the flag in. You said > This was a bug fix, the behaviour previously was incorrect, now it is as intended. Is it the best choice to assume that a pdf will be printed? Seems like the unusual choice these days.
(In reply to Rainer Kuhn from comment #3) > Thanks Ken for clearing that up. I've added the flag in. > > You said > > This was a bug fix, the behaviour previously was incorrect, now it is as intended. > > Is it the best choice to assume that a pdf will be printed? Seems like the > unusual choice these days. It depends to some extent on how you see 'printed' and 'viewed'. Ghostscript's primary purpose is rendering its input, ie 'printing' it. A 'viewer' implies some level of interaction (eg links you can click) and that is something which Ghostscript doesn't offer at all. So that's why the PDF interpreter defaults to treating PDF files as being 'printed'. As I indicated (I think) in the previous report, I'm inclined to do something with the flag so that it can be set to tell the PDF interpreter to process *all* annotations, regardless of the Print or NoView flags, so that they can make it to the pdfwrite device. I'll probably have to think up some way to pass the bitfield though.
Ah, from our side we only use the compression feature out of all that Ghostscript has to offer.
(In reply to Rainer Kuhn from comment #5) > Ah, from our side we only use the compression feature out of all that > Ghostscript has to offer. I also use Ghostscript only for its compression features. I think that the choice to assume printing by default will annoy most users, while I don't see any advantage (when printing a PDF file with annotations, these annotations are ignored automatically, so that keeping them do not hurt).
(In reply to Vincent Lefevre from comment #6) > I also use Ghostscript only for its compression features. I think that the > choice to assume printing by default will annoy most users, while I don't > see any advantage (when printing a PDF file with annotations, these > annotations are ignored automatically, so that keeping them do not hurt). *These* (Link) annotations don't mark the page, other types of annotation do. That's why the PDF specification allows for annotations which are only rendered when printed, and only rendered when 'viewed'. Which is why the previous behaviour was incorrect, and a bug, it *ignored* the Print flag. While this *bug* may have been useful to you in *your* use case, that doesn't help people for whom the ability to differentiate is important, which is why the switch is present in the PDF interpreter. Having the switch be ignored makes it pointless. As I said, I will consider doing something further for pdfwrite and annotations.
(In reply to Ken Sharp from comment #7) > *These* (Link) annotations don't mark the page, other types of annotation > do. That's why the PDF specification allows for annotations which are only > rendered when printed, and only rendered when 'viewed'. So, if I understand correctly, the suggested -dPrinted=false isn't even a workaround to keep link annotations, as it will drop "print" annotations as a consequence. > As I said, I will consider doing something further for pdfwrite and > annotations. OK, and I think that not having a way to keep all annotations is a valid bug (keeping all annotations is really what I wanted in bug 699874).
(In reply to Vincent Lefevre from comment #8) > So, if I understand correctly, the suggested -dPrinted=false isn't even a > workaround to keep link annotations, as it will drop "print" annotations as > a consequence. Yes, I thought I was clear about this previously. > > As I said, I will consider doing something further for pdfwrite and > > annotations. > > OK, and I think that not having a way to keep all annotations is a valid bug > (keeping all annotations is really what I wanted in bug 699874). It is not a bug, the code is working as expected. It may reasonably be described as a limitation of the combination of the PDF interpreter and pdfwrite. There are many such limitations, which is why the documentation on the vector devices is at pains to point out that this combination does *not* simply 'edit', 'modify' or 'merge' PDF files. This bug is closed, please stop appending to it.
*** Bug 700048 has been marked as a duplicate of this bug. ***