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
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
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,
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
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
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
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.
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
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.
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
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
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
--
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,
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
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
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
(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.
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
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
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
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*
[...] 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
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
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
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
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
** 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,
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
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).
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
30 matches
Mail list logo
