Created attachment 10123 [details] example input PDF which triggers issue I use Ghostscript to cat together PDFs, and every now and then I run into a file which does the "*** File has unbalanced q/Q" infinite printing loop which seems to have been run into before (e.g. #694353) but in this case I'm pretty sure the input file is valid, I haven't found any other tools which complain. The command I am running is: $ gs -sDEVICE=pdfwrite -dMaxSubsetPct=100 -dEmbedAllFonts=true -dSubsetFonts=true -dPDFSETTINGS=/ebook -dMaxInlineImageSize=0 -dDetectDuplicateImages -sOutputFile='[output.pdf]' -dNOPAUSE -dBATCH [input.pdf] If I remove -sDEVICE=pdfwrite, and get it to display to the screen instead, it displays fine, so I'm guessing the problem is in the pdfwrite device. Equally, if I add -dNOTRANSPARENCY, the bug also goes away (but produces a PDF without transparency, obviously.) I have attached an example PDF which triggers this issue.
I should also say that removing all unnecessary options, i.e $ gs -sDEVICE=pdfwrite -sOutputFile='output.pdf' input.pdf also reproduces the issue.
To try and match Adobe Acrobat's tolerance for broken PDF files, the PDF interpreter is configured by default to ignore errors. If it encounters an error in a content stream it flushes that stream and carries on. This can result in a q being executed, and the matching Q being flushed, and causes this warning. You can instead set -dPDFSTOPONERROR which will, well, stop when it encounters an error. When the device (eg pdfwrite) is capable of accepting and acting upon PDF data which does not make marks on the page (Outlines, article threads, etc), then the PDF interpreter will attempt to recreate that data in the output PDF file. Taken together these explain your experience. When the device is not pdfwrite you don't get the error, because the PDF Interpreter is not trying to recreate extra data in the output PDF file. [slightly later] Oh dear, I see this is another horrible file created by Cairo. It looks like the problem is simply that the deeply nested forms are exceeding the saved gstate stack. You can convert these to a form which will work with pdfwrite by first converting them to PostScript (using ps2write), but I don't recommend it. Really Cairo should stop creating such ridiculous files.
*** This bug has been marked as a duplicate of bug 693591 ***