On 12/14/2015 01:30 PM, Didier 'OdyX' Raboud wrote:
I'm likely to wait for 1.4.0 upstream release for an upload to unstable,
and will then prepare the package for jessie (if the Security Team
agrees).
I have 1.4.0 released upstream now, including the fix. I have also
updated the Debian packagi
Hi,
I have added the Braille support and today discussed it with the Ubuntu
folks, and there we came to the conclusion to move Braille into a
separate binary package named cups-filters-braille. I was about to do
this now.
Especially in Ubuntu the new dependencies would need a move of package
Splitting done in Debian GIT repository of cups-filters, ready for
release of 1.4.1-2.
Till
On 12/15/2015 03:07 PM, Till Kamppeter wrote:
Splitting done in Debian GIT repository of cups-filters, ready for
release of 1.4.1-2.
Sorry, 1.4.0-2.
Till
foomatic-filters I have discontinued upstream, as it seems that the only
printing environment used in Linux nowadays is CUPS.
Loosing beh in the upstream world by that I decided to re-introduce it
in cups-filters (where foomatic-rip also has its upstream home now). In
cups-filters I have porte
On 03/31/2016 02:29 AM, Jason Lewis wrote:
* What led up to the situation?
trying to compile and install the Perl module Net::CUPS::Destination
Your actual problem is that you are not able to build or install this
Perl module. It is not due to the fact you mention below. To find t
Fixed in cups-filters upstream, BZR rev. 7455.
Thank you very much for the bug report.
The wrong documentation of the input formats of sys5ippprinter was also
in the man page of cups-browsed.conf (utils/cups-browsed.conf.5) and in
README. I have fixed it there, too.
The fix will appear in cu
I have added a new quirk rule to pdftops now that in hybrid mode also
for Dell PostScript printers Poppler will get used.
Note also that pdftops uses the hybrid mode by default.
Till
I have done the following changes now:
In the upstream BZR repo of cups-filters I have removed the now unneeded
"Wants=cups.service" from cups-browsed.service (BZR rev. 7474).
In the Debian GIT repository I have added a "Depends: cups-daemon" to
the cups-browsed binary package, as cups-browse
I think we do not really need this patch. What is does is allowing to
set color calibration mode as default setting for a print queue via the
CUPS web interface. But this option should only be set when calibrating
the printer, not permanently, so Mike Sweet is right that this is a
per-job option. I
I have fixed this regression on the BZR repository, rev. 7241. Thank you
for the bug report.
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On 02/22/2015 01:25 AM, tony mancill wrote:
> Package: hplip
> Version: 3.14.6-1
> Severity: wishlist
>
> Dear Maintainer,
>
> Please consider packaging the latest upstream version. The attached
> patch will build a working package for 3.15.2.
>
> Thank you!
> tony
>
Thank you for the patch.
On 09/27/2015 10:13 AM, Didier 'OdyX' Raboud wrote:
Indeed, it seems that you can't. I can confirm that cups and
foomatic-filters are not coinstallable, at least since jessie.
The most important part of foomatic-filters, foomatic-rip, is included
in cups-filters, only thing not included is b
On 10/30/2014 08:29 AM, Didier 'OdyX' Raboud wrote:
> Hi Michal, and thanks for your bugreport,
>
> I think I understand the problem you're having, let's see.
>
> Le mercredi, 22 octobre 2014, 13.12:51 Michal Hocko a écrit :
>> (..)
>> Of course I had
>> BrowseAllow all
>>
>> present and that cau
On 10/30/2014 01:13 PM, Tim Waugh wrote:
> I've added support for 'BrowseAllow All' in revno 7303.
>
Tim, thank you very much for the quick help.
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.de
I by myself have never tested cups-browsed with that many printers or
otherwise very noisy networks. It is also the first time that someone
reports that cups-browsed takes a lot of CPU.
cups-browsed is running an event loop and if an event (= broadcast
signal from local avahi-daemon or from remote
Your problem seems to be a bad interference between your printer and the
USB CUPS backend. Please follow the instructions of the section
USB printer does not print or prints garbage
on
https://wiki.ubuntu.com/DebuggingPrintingProblems
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ
On 11/01/2014 09:17 PM, ael wrote:
> On Fri, Oct 31, 2014 at 11:35:05PM +0100, Till Kamppeter wrote:
>> USB printer does not print or prints garbage
>>
>> on
>>
>> https://wiki.ubuntu.com/DebuggingPrintingProblems
>
> Somehow my last message repeated -o
I have forwarded this report to Tim Waugh from Red Hat, original author
of system-config-printer and he has answered me the following:
--
> can you check this ppdcache.py problem mentioned here?
I've committed a change which should stop the looping by failing the
call on IOError.
https://
On 09/30/2014 07:34 PM, Didier Raboud wrote:
> Till: would you have an idea of what is causing #763517 ?
>
Unfortunately, I have no idea about what is exactly happening here. I
have forwarded this to Joe Simon who created the color management
extension patch. Let's wait for his answer.
Till
This got also reported to Ubuntu as
https://bugs.launchpad.net/debian/+source/system-config-printer/+bug/1156398
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Thanks for the bug report.
Fixed in cups-filters upstream, BZR rev. 7446, to be released with
cups-filters 1.8.2.
Now there is a new configuration option:
CreateRemoteRawPrinterQueues Yes
to be set in cups-browsed.conf. Then cups-browsed also takes into
account remote raw queues. See also
I think this is a good idea. It makes one of the two utility packages be
installed if at least one is available (ex: Ubuntu with only Main) and
does not error if none is available. And it prefers the better if both
are available (Debian and Ubuntu with Main and Universe).
Let us go this way.
I have done an alternative (and hopefully better) fix for this problem
by re-implementing beh in C and adding it to cups-filters upstream (from
version 1.6.0 on).
Till
Package: ghostscript
Version: 9.16~dfsg-2.1
Matthias Klose from Ubuntu has added multi-arch extensions for the libgs
of Ghostscript. The patch from Ubuntu is here:
http://launchpadlibrarian.net/235445264/ghostscript_9.16~dfsg~0-0ubuntu3_9.16~dfsg~0-0ubuntu4.diff.gz
Can this be added to the De
On 06/07/2017 03:05 PM, Samuel Wolf wrote:
Wed Jun 7 20:03:07 2017 Unable to create/modify CUPS queue (Success)!
Here a successful operation was considered an error and this leads to
the repetition.
I have fixed this already in the 1.13.4 release of cups-filters.
Till
The fix prevents the repeated loading of this printer as it considers
the loading done after the first load.
Till
Bug reported upstream to HP (and to Ubuntu) as:
https://bugs.launchpad.net/debian/+source/hplip/+bug/1710378
I am Till Kamppeter, leader of the OpenPrinting project and also of
cups-filters which is part of OpenPrinting.
The upstream bug tracker is the Linux Foundation one, bugs and feature
requests in cups-filters are filed under the product OpenPrinting and
the component cups-filters.
Here I
On 07/14/2017 11:38 AM, Roland Hieber wrote:
Hi,
On 13.07.2017 16:55, Till Kamppeter wrote:
I am Till Kamppeter, leader of the OpenPrinting project and also of
cups-filters which is part of OpenPrinting.
The upstream bug tracker is the Linux Foundation one, bugs and feature
requests in cups
It seems that the printer answers the wrong resolution (firmware bug).
Under the printer's attributes I have found:
DEBUG2: Attr: pwg-raster-document-resolution-supported
DEBUG2: Value: 600x2dpi
Please run the following command:
ipptool -tv ipp://copper.local:631/ipp/print get-printer-attrib
I have now added a fallback mechanism to the PPD generator in
cups-filters which does not accept resolutions < 75 dpi.
It is committed (rev. 7652) to the upstream BZR repository. Please test.
Till
On 07/17/2017 08:34 PM, brian m. carlson wrote:
It does not appear to fix the problem. The PPD that's generated is
identical and still contains the 600x2 resolution. I will lose access
to the printer tomorrow, unfortunately, so I'll be unable to test
further.
The actual change takes place i
This is all very strange.
What do you get if you run the command
driverless
This should make the printer's IPP URI appear. Now run
driverless [IPP URI] > out.ppd
with [IPP URI] replaced by the printer's IPP URI, the output of the
first command.
out.ppd then is a valid and working PPD for y
Fixed in cups-filters upstream, BZR rev. 7667, will be included in the
cups-filters 1.16.1 release.
Thank you for your bug report with backtrace.
Problem was an uninitialized pointer which made the crash always happen
when a BrowsePolled printer has no "Location" field in its IPP attributes.
Thank you very much for the patch.
I have applied it now to he upstream code of cups-filters (BZR rev. 7672).
Note that the error message
"Unable to create/modify CUPS queue (Success)!"
is actually caused by another bug which I had already fixed earlier. The
queue has actually been created bu
On 12/08/2016 05:54 PM, Brian Potkin wrote:
The printing system is intended to put ink or toner on paper. If it does
not do that it has failed. Can we agree on that?
Does it matter for the primary purpose of printing whether a PDF produced
during the process is searchable or not?
Note that th
Didier, note that rastertopdf was installed all the time, via the
cups-filters-core-drivers binary package. It serves for PWG Raster input
(so that the combo of CUPS and cups-filters emulates an IPP Everywhere
printer). Now with the new CUPS this rastertopdf understands Apple
Raster in addition
On 12/11/2016 05:18 PM, Brian Potkin wrote:
Package: cups-filters-core-drivers
Version: 1.13.0-2
Severity: normal
The driverless utility/backend requires ippfind to be useful. Shouldn't
cups-ipp-utils be a dependency of cups-filters-core-drivers?
So please add cups-ipp-utils to the dependen
On 12/13/2016 05:51 AM, Didier 'OdyX' Raboud wrote:
I'm unconvinced that it makes sense for cups-filters to pull cups-ipp-utils:
This package provides IPP utilities for developers and system administrators
in all installations that have CUPS (aka, _all_ desktops). Is it not possible
to replace
I observed this already by myself on the HP DeskJet 2540 and reported it
to CUPS upstream as
https://github.com/apple/cups/issues/4934
It is partially fixed, but still needs more work from the CUPS side.
Till
I saw that Mike has done the still missing fix now. I have tried it out
and it works now. So it is fixed in the current GIT state of CUPS. To
fix the package in experimental, you need to replace the file
filter/raster.c by the current one from GIT.
Till
On 12/15/2016 11:48 AM, Brian Potkin wrote:
On Thu 15 Dec 2016 at 10:35:00 +, Brian Potkin wrote:
The same behaviour can be reproduced with the commands:
logrotate -f /etc/logrotate.d/cups-daemon
or
systemctl restart cups cups-browsed.service
or
systemctl restart cups ; sleep 3 ; sys
I have fixed the problem (at least I hope so) in the upstream BZR
repository of cups-filters (rev 7580, only file util/cups-browsed.c
needed a change).
If possible, please test.
If you are not familiar with working with source code, please tell me
and I will do the 1.13.1 release so that Didi
tkin wrote:
On Fri 16 Dec 2016 at 21:02:34 -0200, Till Kamppeter wrote:
I have fixed the problem (at least I hope so) in the upstream BZR repository
of cups-filters (rev 7580, only file util/cups-browsed.c needed a change).
If possible, please test.
I will do so. Probably tomorrow morning.
If y
Fixed in the upstream BZR repository of cups-filters (rev. 7580).
Till
I have also fixed #848167 with the commit yesterday, so in the current
BZR state the problem of the queues not being removed is fixed.
Does the problem you mention in this bug occur with the current BZR
state (rev. 7580)?
Till
On 12/17/2016 09:52 AM, Brian Potkin wrote:
[...]
./configure
This file did not exist, so I ran autogen.sh to get it. Was that ok?
Yes, this was correct. I forgot to put ./autogen.sh here.
[...]
And now everything looks fine. The IPP printer remains visible after
doing 'logrotate -vf /etc/
If you have observed the problem with the current BZR state of
cups-filters. Please try
sudo systemctl stop cups-browsed
check whether all cups-browsed-generated queues have gone away and run
sudo systemctl start cups-browsed
Is the setting now obeyed?
Did all the generated queues go away af
Problem of generated queues not being removed solved on upstream BZR,
rev. 7582.
Till
The problem with cups-browsed erroring out when
CreateRemoteCUPSPrinterQueues=No is set and queues from the previous
cups-browsed session did not get removed I have solved now.
The fix is intended to be BZR rev. 7583, but the servers of the Linux
Foundation went completely down, so I attach it
The servers of the Linux Foundation are back online and so I have
committed rev. 7583 and also released cups-filters 1.13.1.
Till
Please attach your /etc/cups/cups-browsed.conf and the output of the command
lpstat -v
Also activate debug logging by adding the line
DebugLogging file
to /etc/cups/cups-browsed.conf and restart cups-browsed via
sudo systemctl stop cups-browsed
sudo systemctl start cups-browsed
When cups-bro
Thank you for the log file.
The high load was probably caused by cups-browsed repeatedly creating
local queues for the discovered remote queues as it did not recognize
that the queues were already successfully generated.
I have corrected the error checking now to interpret the resulting IPP
Strange, seems that avahi-daemon does not hold the info about the
printer in a local cache. And when the network is more busy, the
response times to requests to avahi-daemon get longer.
How does it behave with
ippfind -T 2
ippfind -T 3
?
Till
Added "-T 3" to the ippfind command line in the driverless utility. This
should improve the reliability in finding IPP printers.
I have committed this as rev. 7585 to the cups-filters upstream BZR
repository. Please test.
Till
Did you install the newly compiled driverless utility correctly into
your system?
Do
ls -l /usr/bin/driverless
ls -l /usr/lib/cups/driver/driverless
ls -l /usr/lib/cups/backend/driverless
Are all the three files the same or are there symlinks pointing to one
of the three files, so that indepe
And "lpinfo -v" still does not list it at all?
Please put CUPS into debug mode via:
cupsctl --debug-logging
Then run
time lpinfo -v
and post the output here.
Attach also /var/log/cups/error_log.
Does
lpinfo -m | grep driverless
give some output? Can you post that, too?
Till
Thank you for testing.
I tried "make install" as root and "driverless" and the symlinks all get
root.root ownerships.
So we can consider this bug as fixed upstream now.
Till
Fixed in upstream BZR rev. 7588.
Problem were bugs in the calculation of the page geometry in imagetoraster.
Thank you very much for the bug report.
Fixed in upstream BZR rev. 7592.
Thank you for the bug report.
Fixed in cups-filters upstream, BZR rev. 7599.
Thank you for the bug report.
"lpadmin -m everywhere" uses the PPD generator in the CUPS library. The
generator has no public API and so it cannot be used by other programs
using the CUPS library.
Therefore I have copied the PPD generator from C
This looks like some bug-in-the-PostScript-interpreter-of-the-printer
issue. Please follow the instructions of the section
PostScript (PDF) printer chokes on the PostScript (PDF) coming from Ubuntu
on
https://wiki.ubuntu.com/DebuggingPrintingProblems
Note that the printing parts of Debian and
The problem is most probably caused by inconsistency in how cups-browsed
accesses the local CUPS daemon, for some accesses it uses the domain
socket (which made it mostly well working in your case) and at other
places, especially also during shutdown, it accesses localhost:631 (this
is why it h
Brian, thank you very much for the testing. I will do the next (bug fix)
release containing also other fixes (version 1.11.3) most probably on
Monday.
One question: Did cups-browsed use the socket out-of-the-box or did you
need to set it in cups-browsed.conf?
Till
On 09/03/2016 07:42 PM, Brian Potkin wrote:
# DomainSocket /var/run/cups/cups.sock
Thank you. As this line is commented out cups-browsed connects by the
socket out-of-the-box on your machine.
Till
On 10/18/2016 02:51 PM, Roger Shimizu wrote:
Dear Printing team,
I'm almost finished packaging “fxlinuxprint”.
Because I think it's more proper to ask for sponsorship here, than the
mentors list, I'm wondering whether anyone can sponsor this upload.
Thanks for working on this printer driver.
Another possible issue:
The mimefx.convs rule
application/pdf application/vnd.cups-pdfprintfx 0 pdftopdffx
makes the pdftopdf filter not being used, leading to many CUPS options,
like number-up, page-ranges, ... not working any more.
Is this intended, for example because the output of
0300
+++ ghostscript-9.19~dfsg+1/debian/changelog2016-09-16 18:12:46.0
-0300
@@ -1,3 +1,9 @@
+ghostscript (9.19~dfsg+1-0ubuntu4) yakkety; urgency=medium
+
+ * Multiarchify the library packages.
+
+ -- Till Kamppeter Fri, 16 Sep 2016 18:12:58 -0300
+
ghostscript (9.19~dfsg+1-0ubuntu3
When re-applying the multi-arch support I based myself on the original
implementation in Ubuntu:
http://launchpadlibrarian.net/235445264/ghostscript_9.16~dfsg~0-0ubuntu3_9.16~dfsg~0-0ubuntu4.diff.gz
Till
On 09/17/2016 11:08 AM, Jonas Smedegaard wrote:
Did you test that the multi-arch packages work in a multi-arch
environment? Looking at the symbols file, it seems headers do vary.
- Jonas
I have simply re-introduced the accidentally dropped multi-arch support
which Doko has introduced in
Should be fixed in cups-filters 1.11.3 (in Debian GIT repo but package
not released yet).
Make also sure you have cups 2.2.0-2 installed.
Which CUPS version are you using on the system where the build failure
happens?
The problem seems to be the same as I have already observed with HPLIP.
Since CUPS 2.2.0 at some points
#include
lines need to be added.
Unfortunately, I cannot reproduce your problem on Ubuntu Yakkety (16.10)
Sorry for not having seen this mail in the first place.
There are two parameters: BrowseInterval (currently 60 sec) and
BrowseTimeout (currently 300 sec). Both were configurable in CUPS (<
1.6) and are hardcoded in cups-browsed. It is a good idea to make them
configurable and it should be easy
Thank you very much for the patch. I have applied it to the upstream BZR
repository now (rev. 7541).
Note that I had to do a little fix on the patch. The original one
applied both the BrowseInterval and BrowseTimeout directives to the
BrowseInterval variable. I have also added some info to the
I ran into the same problem at Ubuntu. See the hplip 3.23.12+dfsg0-0ubuntu4
package in Ubuntu 24.04 (Noble Numbat). We have added the patch
debian/patches/0086-hplip-use-raw-strings.patch
here which marks the strings as raw strings. This should be ported over to
Debian.
Also please check the
On 30/03/2024 23:19, Paul Szabo wrote:
Most issues now reported upstream:
https://github.com/OpenPrinting/cups/issues/917
https://github.com/OpenPrinting/cups/issues/918
https://github.com/OpenPrinting/cups/issues/919
The issue with pdftopdf not reported upstream, because I could not find
the co
On 31/03/2024 22:23, Paul Szabo wrote:
(Sadly, my other issues were "declined" upstream. Maybe they know what
they are doing...)
Where did you report them?
Till
gpr is not only not upstream-maintained any more and depending oon the
obsolete GTK2, it is also only used for printing with LPD/gnulpr/LPRng,
all these being printing systems which are obsolete for near 2 decades
(replaced by CUPS) and all not maintained upstream any more.
So it does not actu
Probably you are hitting this bug
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1971242
The bug is fixed upstream in CUPS 2.4.3 and later and I have created 2
Stable Release Updates (SRUs) for Ubuntu Jammy (CUPS 2.4.1) and Lunar
(CUPS 2.4.2). So you could try these fixes and they could p
Jeroen van Wolffelaar wrote:
owner 411167 !
thanks
On Fri, Feb 16, 2007 at 04:14:02PM -0300, Carlos Pasqualini wrote:
Package: wnpp
Severity: wishlist
Owner: Carlos Pasqualini <[EMAIL PROTECTED]>
* Package name: splix
Version : 1.0.1-1
Upstream Author : Aurélien Croc <[EMAIL
I suggest that you simply merge the current Ubuntu Jaunty package
(ghostscript 8.63.dfsg.1-0ubuntu7) into Debian. It contains the new
filter and many other important bug fixes.
Till
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROT
Martin Pitt wrote:
Hi Marc,
Marc Haber [2008-10-27 10:03 +0100]:
after upgrading to the experimental CUPS packages, I can no longer
configure an IPP printer: The "Device" combo box in the "Add" and
"Configure Printer" dialogs only shows "AppSocket/HP JetDirect",
"Backend Error Handler", "CUPS-P
Package: poppler
Currently unstable uses Poppler 0.10.x. For introducing the new
pdftoopvp CUPS filter into the cups package (for the PDF printing
workflow:
https://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_Format)
I need that unstable has at least Poppler 0.11.0. Can
Package: ghostscript
I have made a new Ubuntu package of Ghostscript (in Karmic) to fix some
bugs and to add the "cdnj500" driver for the HP DesignJet 500 and 800.
Most important change is that the "ps2write" device does not segfault on
the testfile.pdf of the CUPS test suite any more, so tha
The source for the current Ubuntu package of Ghostscript you find here:
https://launchpad.net/ubuntu/+source/ghostscript
Click on the newest package in the list (currently 8.64.dfsg.1-0ubuntu9).
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubs
Please merge the following Ubuntu package version of Ghostscript into
Debian:
8.64.dfsg.1-0ubuntu11
It has the following fixes and new feature (in addition to the ones of
0ubuntu9 and earlier):
- pstoraster did not work when called with an input file name as the 6th
command line argument.
Jonas Smedegaard wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Hi Till and others,
On Sun, May 24, 2009 at 08:44:43PM +0200, Till Kamppeter wrote:
Please merge the following Ubuntu package version of Ghostscript into
Debian:
- pstoraster did not work when called with an input
Jonas Smedegaard wrote:
perl-base is sufficient if no modules are loaded, which is the case for
the postinst routines. Perl-base is part of "base" so need not be
declared as a dependency (except for versioned dependencies).
You are right that defoma should care for its own dependencies.
All
Jonas Smedegaard wrote:
By Debian social norms, Masayuki Hatta has to accept it. He is a quiet
guy, however, and these mails are cc'ed the package, reaching all team
members. So I would say that the lack of response, keyed with earlier
approval of moving to Git in the collab-maint group, can
Please also add the following bug fix patches (they are both accepted
into Poppler upstream):
https://bugs.freedesktop.org/show_bug.cgi?id=20420
pdftops produces broken Postscript
15_poppler-ps-output-broken-binary-encoding-fix.patch
https://bugs.freedesktop.org/show_bug.cgi?id=19777
pdft
If you do not consider updating to 0.11.x as it is a development
release, so please add the following two patches to the current Poppler
in Debian, so that we can at least build CUPS with the new pdftoopvp
print filter.
This patch is required for building pdftoopvp:
http://www.openprinting.or
Martin-Éric Racine wrote:
2009/6/18 Josselin Mouette :
Sorry, but cups depends on ghostscript-cups since it cannot work without
it.
AFAIK only certain printers depend on ghostscript-cups. Till can
correct me if I'm wrong.
Yes, that's it. ghostscript-cups contains the pdftoraster, pstoraste
Josselin Mouette wrote:
Sure, if only the affected drivers need to depend on ghostscript-cups,
it’s fine to put the dependency that way. But currently it is not here.
Then the bug here is that these dependencies in the driver packages are
missing. So assign this bug to splix, gutenprint, hpli
On June 11 I have proposed two bug fix patches for the Debian package of
Poppler. One of them needs some additional changes to correctly work. So
do not use the
10_pdftops-multiple-page-size-support.patch
which I have attached to this bug report earlier, but the patch attached
to this e-mail.
I have packaged GPL Ghostscript 8.60 (SVN snapshot of ESP/GPL
Ghostscript merger) for Ubuntu now with separated libgs and also
libgs-dev package.
I have informed Masayuki Hatta, Ghostscript maintainer of Debian, about
it and agreed with him on "ghostscript" as package name. The Ubuntu
source
No, this is a part of the PDF printing workflow. As PDF is the standard
job format, PostScript printers need a driver now, which turns PDF to
PostScript and especuially inserts the option code of the PPD into the
PostScript output. This is done by the cpdftocps filter.
Transforming incoming Po
We should also inform the upstream maintainers. I have CCed them to this
e-mail.
David, Don, can you check this Qt3/Qt4 issue? Thanks.
Till
Mark Purcell wrote:
Dear python-qt4 dudes,
I'm the hplip maintainer and I'm having an issue with the transition of hplip
from python-qt3 to python-q
Mark Purcell wrote:
Sorry about the delay, yes I agree this would be good to resolve before lenny.
hplip also checks for the scanner group and adds it if necessary. But hplip
also depends on libsane.
Is hplip able to rely on libsane to add and remove the scanner group as
required?
If li
Mark Purcell wrote:
On Sun, 22 Jun 2008, you wrote:
I was just also receiving a code=12 error message and by adding myself to
the scanner group. I am now able to access the device correctly through
hp-toolbox.
Yes, this fixed the problem.
code=12 was a bit obtuse for "you are not a member of th
101 - 200 of 323 matches
Mail list logo
