OK, followed the tips outlined in
https://wiki.ubuntu.com/DebuggingPrintingProblems
First, this is a parallel port printer:
tomman@saki:~$ lsmod | grep lp
lp 12797 0
parport31375 3 lp,ppdev,parport_pc
tomman@saki:~$ lsmod | grep ppdev
ppdev
In my case I was able to print a larger pdf
(~700k, 23 pages) reasonably quickly by performing
the following two steps before initiating the print job:
1) Close firefox and a few chromium tabs to free up as much
memory as possible. In my case there was about 150M of
RAM free wi
Le vendredi, 14 juin 2013 19.17:36, Didier 'OdyX' Raboud a écrit :
> So apparently the IPP interface only answers 72 bytes without some of the
> mandatory attributes with this patch enabled. The full HTML log is attached
> if one of you wants to take a look. I don't have an immediate clue right
> n
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 14 Jun 2013 17:41:03 +0200
Source: pxljr
Binary: printer-driver-pxljr pxljr
Architecture: source amd64 all
Version: 1.4+repack0-1
Distribution: unstable
Urgency: low
Maintainer: Debian Printing Team
Changed-By: Di
Your message dated Fri, 14 Jun 2013 16:21:06 +
with message-id
and subject line Bug#703758: fixed in pxljr 1.4+repack0-1
has caused the Debian Bug report #703758,
regarding printer-driver-pxljr: Typo in package description
to be marked as done.
This means that you claim that the problem has b
pxljr_1.4+repack0-1_amd64.changes uploaded successfully to localhost
along with the files:
pxljr_1.4+repack0-1.dsc
pxljr_1.4+repack0.orig.tar.xz
pxljr_1.4+repack0-1.debian.tar.gz
printer-driver-pxljr_1.4+repack0-1_amd64.deb
pxljr_1.4+repack0-1_all.deb
Greetings,
Your Debian queu
I have written more about the cost factor and its motivations in bug
#712237 now.
Till
--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51bb23ff.9050...@gmail.co
The old cost factor (65) I had introduced to overcome an ugliness in the
PDF-based printing workflow.
If the cost factor is 66 and an app sends a PostScript input file and
the printer is PostScript (or some old-fashioned driver insisting on
PostScript input is used), I got
PostScript -> pstopdf -
Hi, Brian
You guys are great! After changing 66 to 65, and a "sudo /etc/init.d/cups
restart", the output PDF looks beautiful again! And the output PDF file
name also gets friendly. When it's 66, the output file always named
_stdin_.pdf overwriting previously generated one. Now it's 65, the output
On Thu 13 Jun 2013 at 17:22:20 +0800, 王晓林 wrote:
[Snipped: A very useful account of a testing procedure]
> In a short word, all the PS in /var/spool/cups look very good; all the PDF
> in ~/PDF look ugly. In the attachment, you can find
>
>1. d00107-001, the PS file in /var/spool/cups
>2.
Package: cups-server-common
Version: 1.6.2-8
Severity: normal
In /usr/share/cups/mime/mime.convs there is
application/postscript application/vnd.cups-postscript 66
pstops
In cups 1.5.x we have
application/postscript application/vnd.cups-postscript 65
pstops
11 matches
Mail list logo
