[Bug 691130] Re: PDF workflow flawed, crashes printers
lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as Won't Fix. ** Changed in: ghostscript (Ubuntu Lucid) Status: Incomplete = Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/691130/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
3t0g0, thank for the hint, so I close the main task as this one is meant for Natty. ** Package changed: cups (Ubuntu) = ghostscript (Ubuntu) ** Changed in: ghostscript (Ubuntu) Status: Incomplete = Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
After I have installed ghostscript from 8.71 to 9.01, the print problem fixed. You could either download the source, compile and make from the source http://pages.cs.wisc.edu/~ghost/doc/GPL/gpl901.htm or to borrow the debs from natty, https://launchpad.net/ubuntu/+source/ghostscript/9.01~dfsg~svn12005-0ubuntu1/+buildjob/2152489 Pls let me know whether this method work for u. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
An PS expert from my group looked at the Postscript file (spoolprint.ps). There's a /PageSize [210 332] setpagedevice command, which set the Paper Size to 210x332 point, which is unknown to printer. Probably the original PDF brochure's size.is defined as 210x332, however, the pdf to ps conversion process (whatever filter it is) did not do it properly. It should tell printer to use the paper size user specified (Letter or A4), and print the original pdf (210x332) to a corner of the page or fit to page. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
George asked me to look at this spoolfile. Beyond the custom page size, here is a little more information: 1. This print job was prepared with a PPD file for a Panasonic printer and so contains PS code specific to that device - it will cause an error on other devices (such as a Ricoh or maybe even another Panasonic). Posters in this thread mentioned the DP-C265, searching for some of the ProcSet names online returned DP-C405, they seem to be in the same product line. It would be nice to know for sure that the printer and PPD were properly matched, in order to eliminate that possibility. 2. This print job appears to have different settings for the same parameter; now, that's ok in theory, because the last setting simply replaces the previous setting, but it does indicate a potentially confused workflow. line 461..Duplex set to false line 3239Duplex set to true line 598..PageSize set to 595 x 842 (that's A4) line 3239PageSize set to 210 x 332 (custom page size, a little bigger than A7) line 3245PageSize set to 210 x 332 (again! Indicates possible multiple upstream sources for page settings) 3. There is a ProcSet for XPDF at the beginning of the file - I guess this open-source code was used to convert PDF - PS - the procedure pdfSetup defined there is called on line 3239 and sets Duplex, ImagingBBox and PageSize after all other setup commands have executed, including separate commands for all three of those parameters. These parameters can have a significant effect on printer memory when changed, because a big chunk must be allocated for the frame buffer (raster memory) and the size depends on the page size and duplex setting (and resolution, and margins,...). In the case of this print file, the printer is forced to re-allocate memory several times before it even starts to draw anything. Some posts in this thread mentioned strange behavior, ghostly crashes and long print times, this all sounds a bit like a case of trashed memory, doesn't it? It was also mentioned that the duplex setting makes a difference in this case - and duplex is being set by this pdfSetup procedure - so it's all very suspicious. 4. When I remove all the Panasonic-specific feature settings and that dang pdfSetup call, this file prints very quickly (less than 30 sec.) on a Ricoh MP C2800, a relatively old and slow printer. So all of the trouble is in the setup process, which is basically an interaction between the driver and the PPD file. 5. Finally, about that PageSize setting of 210 x 332. When Acrobat is asked to print a custom page size like that, it makes that size a clipping path rectangle on a standard paper size the printer supports, such as A4 or Letter. This job is actually asking the hardware to set up a physical page size like that - something the paper path in the printer doesn't support, who knows what happens. -David -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
This file crashes a Panasonic DP-C265, when printed under Maverick with either Acroread, Evince or gtklp, print queue running on Lucid with modifications as described earlier, to avoid PDF workflow. Will try to fetch the PS file that is sent to the printer shortly. ** Attachment added: Crashes a Panasonic DP-C265 https://bugs.launchpad.net/ubuntu/+source/cups/+bug/691130/+attachment/1791012/+files/Printcheck_DenHaag_week03.pdf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Is there a way in which I can send a PS file (as made from the instructions at #18) to the printer, manually, through the IPP backend? To double check if this still crashes the printer? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Done as suggested in comment #18: added FileDevice True cp /etc/cups/ppd/kleurenkopieerapparaat.ppd /tmp/pana.ppd lpadmin -p printtofile -E -v file:/tmp/spoolfile.ps -P /tmp/pana.ppd lp -d printtofile /tmp/Printcheck_DenHaag_week03.pdf The resulting Postscript file is attached. ** Attachment added: resulting PS file from printing to file. https://bugs.launchpad.net/ubuntu/+source/cups/+bug/691130/+attachment/1791098/+files/spoolfile.ps -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Valentijn, in a terminal window run the command: lpr -P printer name -o raw PS file Then CUPS sends the file to the backend without any filtering. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Thanks. I verified, that printing https://bugs.launchpad.net/ubuntu/+source/cups/+bug/691130/+attachment/1791098/+files/spoolfile.ps on this Panasonic printer crashes the printer - although the printer does not restart, it says Machine Error - Call TEL. 0736402888 - which is the local service organisation; when I reset the printer remotely, it has a Remove Misfed Paper message on it's display. I also tried the other crashing PDF, and this one immediately restarts the printer (even while the remove misfed paper message is still there, so the printer apparently starts interpreting the PS even before the paper path is cleared). I'll send this postscript file by private mail. So far, I haven't been able to do anything to the Ricoh printing problem, because these printers are in a more secure environment, and unfortunately, I can't access them remotely as easy. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Printing the file does *not* work with these changes. That is: if you have these changes, and try to print non-duplex, the printer will freeze. Printing duplex does work. Regarding the printer model: I'll get back to you with the specific model, because, actually, it strikes me as a bit odd that this would be a 4510. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Ahem. I did not read your comment too well. I will check your changes, *then* get back. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
BTW, is there a possibility to intercept the final PS stream that is sent to the printer? Having an intermediate PDF that crashes in some situations, but prints in other, is helpful, but a bit complicated as well. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Yes, you can create a print-to-file queue using the same PPD file. Instead of sending the job to printer, the data stream will be saved to a file. To do so, you need to 1. From CUPS web admin page, under Administration, add FileDevice True to the configuration file. 2. Create the print queue using Device URI file:/tmp/myspoolfile.ps with your ppd file. It can also do through command line: /usr/sbin/lpadmin -p printtofile -E -v file:/tmp/myspoolfile.ps -P myppdfile.ppd 3. You can send job to the printtofile queue. PS file will be created at /tmp/myspoolfile.ps. Make sure to add read permission to the file. chmod a+r myspoolfile.ps In my previous posting (#14), I didn't want you to try anything new, I just want to know how to reproduce the problem. Do I need to do the following as specified in your original posting? change /usr/share/cups/mime/mime.convs to say: application/pdf application/vnd.cups-postscript 43 pdftops application/postscript application/vnd.cups-postscript 65 pstops -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 691130] Re: PDF workflow flawed, crashes printers
Hi, Op 07-01-11 20:47, georgeliu schreef: Yes, you can create a print-to-file queue using the same PPD file. I'll implement that next week. [...] In my previous posting (#14), I didn't want you to try anything new, I just want to know how to reproduce the problem. Do I need to do the following as specified in your original posting? Probably, yes. Because otherwise, as far as I understand, CUPS may use the new PDF workflow. So: - set mime.convs options as described - restart CUPS if necessary (if I understand correctly, it calculates the print routing only during it's startup, but I may be wrong) - easiest way is: have gtklp installed, please print the file with this, make sure you have duplex printing OFF. Please note, that the file you have is the file as found in the print queue, so it's meant to be printed with lp or gtklp. If you reopen it with Acrobat or Evince, I'm not sure what it will get you - probably just a dull print. Another new fact is, that the printer in question is a NRG MPC4500; we're only using the 4510 PS file, hence my confusion. Please note, that because of the duplex/non duplex sensitivity, I'm still not 100% confident that of the reproducability of this problem, i.e. there may still be parts missing. Ulrich Wehner from Ricoh USA was able to crash some older printer, but not his regular MPC3500. So I hope that the print-to-file option will get us a Postscript file that will crash the printer directly. Best regards, Valentijn -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
I now have a verifyable PDF, straight from the print queue, that crashes a certain Ricoh printer - a Ricoh Aficio AP4510 PS, which isn't exactly your entry-level small printer - it's rated 45K pages per month. The printer crash *only* happens when: - we print the original document (a PDF) from Evince - we have the printer output non-duplex (the default is to duplex) If we set the print options to the default (i.e. duplex), no crash occurs. I have now personally verified this (no stupid users telling random things in between). We verified the duplex or non duplex occurence with both Evince (from the original document) and gtklp (with the document that I grabbed from the queue). This gives me 4 new documents in the queue, all bit-by-bit the same; they will have the printer crash due to setting a non-duplex option. Let me repeat that in pseudo-code: Original.pdf - printed from Evince, duplex - CUPS queue: nocrash1.pdf - prints Original.pdf - printed from Evince, simplex - CUPS queue: crash1.pdf - crashes printer nocrash1.pdf - printed with gtklp, duplex - CUPS queue: nocrash2.pdf - prints nocrash1.pdf - printed with gtklp, simplex - CUPS queue: crash2.pdf - crashes printer As a check/double/triple-check: nocrash1.pdf, crash1.pdf, nocrash2.pdf and crash2.pdf are bit-by-bit the same, they all have the same md5sum, so the printing options are at stake here. Now the problem is: the document is not exactly for everyones eyes, i.e. I would not like it to be generally available (through Launchpad, for example). On the other hand, it's not exactly Top Secret, so sharing it privately with a couple of developers at Openprinting wouldn't hurt. So my question is: can I send Till . Kamppeter at his Gmail.com account a 546K PDF document that will crash a certain type of printer, when certain printing options are active? Or is there a better place to send such document? I realise that this may end up being a bug in either Evince or the Ricoh PS firmware, but I'd like at least to be able to know what that bug is. ** Attachment removed: PDF that will not print with the new PDF workflow https://bugs.launchpad.net/ubuntu/+source/cups/+bug/691130/+attachment/1774777/+files/strick.pdf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
(I removed the previous attachment; sorry for the fuzz; I simply couldn't reproduce the issue yesterday while I was at the customer's premises, so I suspect a luser reporting nonsense). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Valentijn Sessink, please send the file to me by e-mail. It is no problem. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Let me clarify: With the following change, the pdf file can be printed successfully? change /usr/share/cups/mime/mime.convs to say: application/pdf application/vnd.cups-postscript 43 pdftops application/postscript application/vnd.cups-postscript 65 pstops That is a smart change to bypass the new PDF workflow filter pdftopdf and cpdftops. Different printers deploys different Postscript interpreter in its firmware. Ricoh printers uses Postscript interpreter provided by Adobe, while HP and other vendors use their own in-house developed Postscript interpreters. Each interpreter has different strength and error handling schemes. That's why you experience different print result for the same PDF file. Ricoh-Aficio AP4510, is indeed a very old model (more than at least 6 years). I do not have access to that model, but I'll see whether the problem could reproduce on another Ricoh model. George -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Oh well. Please forget about this attachment. Never trust your end users to tell you if anything did or did not work; as far as I can see, the attached PDF just works (might have been a bit slower under 10.04, I'm not sure). I still do have a PDF that crashes the printer - only if printed from Evince, though. I'll send that shortly. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Unfortunately, with a Maverick installation, the long delay in printing persists. Please note that this is not a live CD, but an installed machine. On the other hand, the install is pretty basic and printing is done through the network, so there is nothing the local Cups is doing. Our *hacked* print path, on the central server: application/postscript application/pdf 2 pstopdf application/pdf application/vnd.cups-postscript 43 pdftops application/postscript application/vnd.cups-postscript 65 pstops On a server with Ubuntu 10.04 LTS, this will output a certain PDF within 4 minutes on a Panasonic DP-C265 with Postscript module. A regular print path (nothing changed), with the same PPD, on an installed Maverick machine, a print takes considerably more time (more than 15 minutes). I'm currently investigating if this PPD is public (i.e. can be attached to this bug report). One thing that puzzles me, is that I could not exactly see the differences in the print path between 10.04 and 10.10: 10.04 seems to use Poppler as well? Anyway, please tell me what I should test next. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
[...] will output a certain PDF [...] than 15 minutes). I'm currently investigating if this PPD is public That should read: if this PDF (the document I'm trying to print) is public. So, to summarize: a) printing from a Maverick machine to a Lucid server with hacked-up printing path: 4 minutes (prints to Panasonic printer through IPP). b) Printing on the Maverick machine itself, straight to the same IPP addressed Panasonic printer takes considerably more time (we stopped waiting after 18 minutes, printer still flashing, not sure if anything will come out today ;) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
The attached PDF (which is public) will not print or print very slowly (30 minutes) on the above printer with the Lucid/Maverick default print path. With a hacked workflow as described, all pages print within 4 minutes. ** Attachment added: PDF that will not print with the new PDF workflow https://bugs.launchpad.net/ubuntu/+source/cups/+bug/691130/+attachment/1774777/+files/strick.pdf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
I don't think I understand the Capturing print job data part of DebuggingPrintingProblems. As far as I can see, disabling the printer will stop the print queue handling *before* filtering jobs. So all I am getting is the PDF that I already attached above. Am I doing something wrong? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Valentijn Sessink, it is true that the PDF which you will capture is of before the filtering, but it is not the PDF which you attached with an earlier posting, as PDF viewers, especially Evince do not simply pass through the PDF when printing but they re-render it. They use the same graphics engine as for the screen display (Cairo in case of evince) and create a PDF with it. This PDF is often much bigger than the original PDF, which makes subsequent filters much slower or even crashing. Therefore I need this captured print job. The PDF attached to this bug report and the captured PPD will only be identical if you had printed it with lpr and not with a PDF viewer. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
That is what I did. (Hence my confusion when the captured file came out identical to the original file ;) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
** Also affects: cups (Ubuntu Lucid) Importance: Undecided Status: New ** Changed in: cups (Ubuntu Lucid) Status: New = Incomplete ** Changed in: cups (Ubuntu Lucid) Importance: Undecided = High -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Your suggestion of modifiying the cost factors of the CUPS filters we have already applied in Maverick. Our implementation is a little different, we have only set application/postscript application/vnd.cups-postscript 65 pstops so that for a PostScript printer it is avoided to turn incoming PostScript into PDF and back into PostScript. If the incoming data is already PDF, there is not much difference whether one passes it through pdftopdf and then through pdftops or first through pdftops and then through pstops. The change especially eliminates PostScript to be turned to PDF via the (Ghostscript-based) pstopdf filter. I can issue an SRU (Stable Release Update) for Lucid to apply this change. The main problem is that applications deliver ineffectively made output files which blow up a lot when converting them, ending up with a huge file sent to the printer and the printer simply runs out of memory. See also bug 668800 describing a possible cause for slow printing and a suggested solution for Natty. Maverick does not only have the cost factor change for the pstops filter but also several printing improvements in the code of the filters. So if you do not require to stay on LTS, you could try to use Maverick. If you want to stay on LTS, please try also whether only setting application/postscript application/vnd.cups-postscript 65 pstops in /usr/share/cups/mime/mime.convs already solves your problem. Please tell whether this works or only using application/pdf application/vnd.cups-postscript 43 pdftops in addition remedies the problem, so that we can make an appropriate SRU. Also try a Maverick live CD only to see whether Maverick has your problem solved without any additional changes. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 691130] Re: PDF workflow flawed, crashes printers
Op 16-12-10 19:07, Till Kamppeter schreef: Your suggestion of modifiying the cost factors of the CUPS filters we have already applied in Maverick. Our implementation is a little different, we have only set application/postscript application/vnd.cups-postscript 65 pstops I know. (See below). so that for a PostScript printer it is avoided to turn incoming PostScript into PDF and back into PostScript. If the incoming data is already PDF, there is not much difference whether one passes it through pdftopdf and then through pdftops or first through pdftops and then through pstops. The change especially eliminates PostScript to be turned That's the theory. In practice, there *is* a difference. want to stay on LTS, please try also whether only setting Yes we do. application/postscript application/vnd.cups-postscript 65 pstops in /usr/share/cups/mime/mime.convs already solves your problem. Please tell whether this works or only using I did the trick with 65. But then customers complained that they could not print PDF files, they sometimes would only print half, sometimes it took very, very long. (I'm not sure if they would also crash the printer) So that's why we also set the pdftops cost to 43. So: only setting pstops to 65 does not solve the issue. My feeling is that there's a problem within the filtering, one that's not easy to spot but that pops up with the pstopdf stuff. SRU. Also try a Maverick live CD only to see whether Maverick has your problem solved without any additional changes. It's only a couple of printers that crash, in live situations, with print servers at customer premises. So it's a bit hard to check. I'll see what I can do. Our own HP Laserjet doesn't crash, that's the main problem ;-) V. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 691130] Re: PDF workflow flawed, crashes printers
Can you please also try the Maverick live CD only to see whether the filter code changes of Maverick already solved problems? Can you also follow the instructions of the sections CUPS error_log and Capturing print job data of https://wiki.ubuntu.com/DebuggingPrintingProblems, once for the original /usr/share/cups/mime/mime.convs having a printer crash and second, for your version with the two cost factors changed and the job coming out correctly. Can you also attach the input file which you have used for the test. Please attach the files one by one, do not package or compress them. ** Changed in: cups (Ubuntu) Status: New = Incomplete ** Changed in: cups (Ubuntu) Importance: Undecided = High -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/691130 Title: PDF workflow flawed, crashes printers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
