Lulu Feedback

Post your idea for improving Lulu! We use this data to direct future site development. You can also view other ideas, comment, and upvote existing ideas.

smarter back-end Lulu printer selection for production run

Recently, I tried to print a project that I've printed (successfully) *many* times before, only to have an email notifying me that there was an 'error', and the job couldn't be printed -- and summarily cancelled. When I followed up with tech support, they determined that the PDF properties for the file (which have not changed in some time) were not compatable with the printer. It turns out that Lulu has >1 physical printers (no suprise -- probably >>1), and that some printers could handle the particular PDF, while others could not (including, it seems, the printer that was selected to print my project). Apparently, which 'printer' the job gets sent to is a bit of a random draw (I suspect based on a queue volume allocation approach), and previous successful prints must have managed to use (i.e., been sent to) a printer that didn't choke on the PDF properties. 

So, there are at least 2 solutions. One, which tech support suggested, was to 'dumb down the PDF' so it would be compatible with *all* Lulu printers (meaning, reduce from PDF 1.7 -> 1.3, downsample various images, etc, etc). We tried this, and it worked but...required saving the PDF as a .PS file, and then using Adobe Distiller with the 'Lulu-friendly' settings, which can be downloaded from Lulu. 

While this worked, it is a royal pain for those of us who either (i) don't have Distiller, or (ii) who go directly from .PS -> .PDF (using GhostScript, in my case). The workaround requires me to create the original balky PDF, save as PS, then suck PS into Distiller to create a newer, 'dumber' PDF. [Current PDF standard is 2.x. Having to downgrade to 1.3 seems a bit much.]

A better solution (IMO) would be as follows: If a particular job won't print on a  given printer, then it should be flagged, and an attempt made to print on the other printer(s). Or, more pre-emptively, the PDF file contains most of the details likely to cause a printer conflict, so why not simply route the PDF file to the right printer in the first place? Alternatively (less robust),  see if the file has printed successfully in past, and if so, have the  file go to that printer. In fact, it would be easy to build 'print ID'  into a backend for a particular project, such that it always goes to  that printer, if it successfully printed in past. I think the more elegant approach would be to parse the PDF on submission, and pick the right printer that way, but other would work. 

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Apr 29 2019
  • Will not implement
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    May 03, 2019 20:48

    Thanks for the thoughtful and detailed reply, comlete with rationale for the decision;-(

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    July 16, 2019 15:00

    It is possible to fix failed files to work at all printers, but it is not possible to fix printers to work with all files. The file is the source of the problem not the printer. In these situations fixing the file is always the right solution.