0

Each week my company gets product labels printed. I have a PHP script which uses FPDI to generate a few PDFs to send to our print shop. Combined they are about 500 pages. Once opened in Acrobat, they take a long time to spool. Acrobat reports that each page is being "flattened" as the progress bar ticks away.

We are trying to streamline the process to not take so long to spool, so I have been trying to find a way to flatten the file programmatically, but have struggled to find relevant web results for the goal.

Most of what I find seems to pertain to single-page flattening. When I try to follow such methods, I wind up with a single-page file that has all the other pages smushed on top of each other.

convert -density 300x300 -colorspace RGB file.pdf -quality 100 -flatten fileFlat.pdf

If anyone can help point me in the right direction to emulate what Acrobat is doing, it would be greatly appreciated.

macheteYeti
  • 27
  • 6
  • I'm not familiar w/ this flattening process but my first thought would be to avoid trying to emulate how Acrobat does it and instead just create a bunch of smaller PDFs. I.e., create one PDF per label so that you have 500 one-page files. If the process is automated then it doesn't matter how many there are. – Alex Howansky Nov 10 '21 at 17:44
  • Hey @AlexHowansky - Thanks, but I'm not sure how we would automate the process at the print shop end. Do you have experience automating Acrobat printing? These are large format files (Tabloid 11"x17"), and we need to print them N-to-1, so I don't think it is possible to print any other way besides Acrobat – macheteYeti Nov 10 '21 at 18:02
  • _"Do you have experience automating Acrobat printing"_ Well, not with Acrobat, but with postscript. I think maybe you can use FPDI on your side, to pre-flatten either your input template or your resulting output. https://www.setasign.com/products/setapdf-core/demos/flatten-annotations/ – Alex Howansky Nov 10 '21 at 18:37
  • 1
    I'm assuming that this 'flattening' takes place when you print to a non-PDF capable printer. My guess would be that your input PDF file contains transparency and you (or your print shop?) are printing to a PostScript printer. PostScript doesn't support transparency. So Acrobat does the only thing it can and turns the pages into bitmaps. Yes that's slow and the result is large. It also explains why your file goes from 86MB to 737 MB with Ghostscript when it does the same thing (pfimage device). I'd suggest getting rid of the transparency in the input if you can. – KenS Nov 11 '21 at 10:06
  • As @KenS already guessed, I also guess that this is an issue related to transparency handling. By default FPDI adds a "Group" entry to the XObject dictionary to keep the transparency of the imported pages intact. If you know that you are using documents without transparency groups, you can try to pass _false_ to the $groupXObject parameter of [importPage()](https://github.com/Setasign/FPDI/blob/master/src/FpdiTrait.php#L236). Can you try this? – Jan Slabon Nov 12 '21 at 11:20
  • HI @JanSlabon - I was waiting for the designer to get back to me to answer this question as I am not sure how to tell since I don't have the InDesign files. Anyway, I tried your suggestion and got a fatal memory allocation error, which I assume confirms that I do have transparency in the mix? The line triggering the error is fpdi.php 148 protected function _put($s, $newLine = true) { if ($newLine) { $this->buffer .= $s . "\n"; } else { $this->buffer .= $s; } } – macheteYeti Nov 13 '21 at 12:28
  • This little change shouldn't change anything in view to memory usage - at the end the resulting file will be a little bit smaller. So there must be another change on your end. So revert back to the initial version and simply try the mentioned parameter. – Jan Slabon Nov 15 '21 at 06:54
  • Hi @JanSlabon - I did not make any other changes prior to incurring the error. I changed $tplIdx=$pdf->importPage(1); to $tplIdx=$pdf->importPage(1 ,PageBoundaries::CROP_BOX,false); - as this is what I gleaned as necessary from the docs to not have the second parameter null. Have I done something incorrectly? – macheteYeti Nov 16 '21 at 11:37
  • So you are saying that changing this parameter from true to false raises a memory allocation error? What is the exact error message you have? – Jan Slabon Nov 16 '21 at 13:16
  • @JanSlabon - this time when I ran it again, it did not error. perhaps when i was trying friday other processes were utilizing more of my RAM. anyway, unfortunately the resulting GS flattened files did not significantly vary on file size. They went from 3.408GB to 3.556GB. Although there were about 16 more pages included on this run. The initial FPDI files remained about the same size as well. Not sure where that leaves us – macheteYeti Nov 16 '21 at 15:05
  • Try to send the PDF (or some pages of it) generated by FPDI (created with _false_ in the $groupXObject parameter) to the printer. Leave the GS step temporarily. – Jan Slabon Nov 16 '21 at 15:28
  • @JanSlabon - what are we trying to see? if the flattening time is faster? Anecdotally it seems like not really. Definitely not significant improvement – macheteYeti Nov 16 '21 at 16:03
  • Yes, this way FPDI doesn't add exlplicit information in view to transparency handling which may had triggered the pre-rendering process. But if this doesn't change anything I've no other idea, sorry. – Jan Slabon Nov 17 '21 at 08:01
  • @JanSlabon Okay, thanks for trying! We'll live with the larger files – macheteYeti Nov 17 '21 at 12:15

1 Answers1

0

I was able to find this solution:

gs -q -dNOPAUSE -sDEVICE=pdfimage24 -r300 -sOutputFile=fileFlat.pdf file.pdf -c quit

It produces the desired outcome, however, the file goes from 86MB to 737MB... I did attempt to use a downscaling factor, however this results in a quality loss which is not usable.

Anyone know how to improve on this process' resulting filesize?

macheteYeti
  • 27
  • 6
  • Hi @KJ - If I'm being honest you've lost me on most of that. When I applied a downscaling factor, the text became pixelated and some of the colors got washed out. The files are originally RGB 300dpi, and so what I think I'm beginning to fear is that they have to remain that way and the aforementioned GS method is the way to get them print-ready in that quality and so I will have to live with the filesize. Would you agree? – macheteYeti Nov 10 '21 at 19:06
  • 1
    @KJ - pdfimage8 produced a grayscale image... this is not useful – macheteYeti Nov 12 '21 at 14:55
  • Hi @KJ - here is an example file. They are 11x17" and all look pretty similar to this: https://fitaf570.com/lab/Asian%20BBQ%20Glazed%20Wild%20Salmon/Asian%20BBQ%20Glazed%20Wild%20Salmon%201.pdf – macheteYeti Nov 13 '21 at 12:16
  • Hey @KJ - missed the email notification for your reply. Anyway, I thought your approach was how we were doing it. Our designer provides https://fitaf570.com/lab/Asian%20BBQ%20Glazed%20Wild%20Salmon/1.pdf - then the print shop owner generates the 5 up version you first saw. He uses InDesign as well, but since he is working from a PDF, I figured it would be flat already. As for the permutations of files being printed, we run a 200+ meal menu over an 8 week rotation, with about 35 meals per week, each of which are offered in 3 different sizes, so it is a very diversified print job all told – macheteYeti Nov 16 '21 at 11:35
  • @KJ - afraid you lost me again towards the end there. We are using a laser printer, but besides that I'm not sure what the guidance is – macheteYeti Nov 16 '21 at 14:13