A large pdf is normally compressed by the following batch file: C:\"Program Files"\gs\gs9.20\bin\gswin64 -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dDownsampleColorImages=true -dColorImageResolution=400 -dDownsampleGrayImages=true -dGrayImageResolution=400 -dDownsampleMonoImages=true -dMonoImageResolution=400 -dNOPAUSE -dBATCH -sOutputFile=FalterinLenzkirchV2_Compressed.pdf FalterInLenzkirchV2.pdf In the version 9.20 the crossreferences were maintained. However, in the new versions (9.26/7) the crossreferences are lost while compression. Since the actual files I work with are very large, I can provide an example, if necessary.
(In reply to Bernhard Kleine from comment #0) > A large pdf is normally compressed by the following batch file: Well actually, no. What you mean is a new PDF is produce which is smaller than the original. You should read this: https://www.ghostscript.com/doc/9.27/VectorDevices.htm#Overview to understand the process. Ghostscript's pdfwrite device does *not* compress PDF files. > In the version 9.20 the crossreferences were maintained. PDF files don't have an 'cross refrence' object. There are Link annotations and the Outlines tree. I have no idea whaich of these you are referring to. > However, in the new > versions (9.26/7) the crossreferences are lost while compression. Since the > actual files I work with are very large, I can provide an example, if > necessary. Its completely impossible to investigate a problem without an example file, you should always provide teh simplest file and commadn line you can, which reprocues the problem.
Created attachment 18068 [details] The docbook testcase
(In reply to Bernhard Kleine from comment #2) > Created attachment 18068 [details] > The docbook testcase This is an XML file, Ghostscript doesn't handle XML.
I have a minimal testcase which shows all the elements to show. However, a pdf is not allowed to upload. <?xml version="1.0" encoding="UTF-8"?> <?xml-model href="http://docbook.org/xml/5.1/rng/docbookxi.rng" schematypens="http://relaxng.org/ns/structure/1.0"?> <?xml-model href="http://docbook.org/xml/5.1/sch/docbook.sch" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> <book xmlns="http://docbook.org/ns/docbook" xml:lang="de" xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:ns5="http://www.w3.org/2000/svg" xmlns:ns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.1" status="draft" > <chapter> <title>Chapter Test</title> <para>Here we test crossreferences<indexterm> <primary>test</primary> </indexterm></para> <para><indexterm> <primary>crossreferences</primary> </indexterm> in PDF<indexterm> <primary>PDF</primary> </indexterm></para> </chapter> <index> <title>Index</title> </index> </book> The batch file I have already provided. I could send the pdfs if you let me know where to.
Created attachment 18069 [details] example of attaching PDF file (In reply to Bernhard Kleine from comment #4) > I have a minimal testcase which shows all the elements to show. However, a > pdf is not allowed to upload. Its perfectly possible to add PDF files to our Bugzilla, a quick persue of the database would show *many* cases where PDF files have been attached. I'm not aware of this having changed, and I've attached a PDF file here as a test. Possibly your end is blocking the attachment, I can't help you with that. > The batch file I have already provided. > I could send the pdfs if you let me know where to. You need to attach the PDF file used as input to Ghostscript, I can't do anything with an XML file.
Without the benefit of a file to look at, its impossible to be sure, but I strongly suspect this is a duplicate of bug #699896 which was itself a duplictae of bug #699830. See especially comments 13 and 16 of bug #699830.
Created attachment 18070 [details] This is the original pdf.
Created attachment 18071 [details] this is the compressed file 9.20 with crossreferences intact.
Created attachment 18072 [details] the cpmpressed file vers 9.26 without crossreferences
sorry for the noise. now the minimal pdfs are uploaded.
See my comment #6. Once again, Link annotations with no /F (Flag) value specified, which means they have a default value of 0, and are therefore 'non printing'. In order to have the PDF interpreter process non-printing annotaions, you must set -dPrinted=false, by default the PDF interpreter is set to behave as a printer, so Printed is true. A more lengthy explanation can be found in bug #699830. The behaviour change was due to *fixing* a bug, which caused the Printed flag to be incorrectly ignored in some cases. *** This bug has been marked as a duplicate of bug 699830 ***