Bug#617468: [Pkg-cups-devel] Bug#617468: My cups-pdf is also producing blank pages, downgraded to 2.5.0-16 works
Hi, On Sat, 2011-03-19 at 00:39 -0400, Bin Guo wrote: > Hi Volker, > > I did try "lpr tiger.eps" on two debian system, still one working and > the other (laptop) empty (with similar logs). While playing with the > laptop, I recreated the PDF printer and now it works! > > Luckily I have another debian system that's having the problem, and > attached are the /etc/cups/printers.conf from bad(empty) debian and my > now good laptop. Was it the application/vnd.cups-pdf line causing > problem? > on my system there is no difference whether the line is there or not. I still think there is a difference to the original PS-code (as you could see from your logfiles the contents of the two PS files printed differed. When re-creating a printer, its new PPD is copied to /etc/cups/ppd/.ppd - maybe the original ppd was not the correct one and while re-creating the printer you copied to proper one in place. Could you compare the ppd in /etc/cups/ppd on the working system vs. the one on the broken system? Regards, Volker -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619461: [Pkg-cups-devel] Bug#619461: cups-pdf: PDFVer and GSCall keys not taken into account
On Thu, 2011-03-24 at 17:54 +0100, Jean-Philippe Thierry wrote: > Hi, > > Le 24 mars 2011 15:44, Martin-Éric Racine > a écrit : > 2011/3/24 Volker Behr : > > The log-file you sent me contains the following line: > > > > Thu Mar 24 11:05:53 2011 [DEBUG] file already pdf, simply > copying it > > > (cp /var/spool/cups-pdf/SPOOL/cups2pdf-12256 > /home/jpht/tmp/PDF/Bugs_in_package_cups-pdf_--_Debian_Bug_report_logs.pdf) > > > > This option to directly copy PDF instead of reprocessing it > was > > suggested to me some time back and I decided not to > implement it since > > it would disable all options set in cups-pdf.conf on the > respective > > files. This is exactly what happens to you here: the PDF is > just passed > > through instead of getting re-worked with all your desired > options by > > CUPS-PDF. > > > > So, speaking for upstream: no fix needed. > > My advise to the distribution: remove this additional patch > on CUPS-PDF > > since it breaks basic functionality. > > > The patch in question was removed in 2.5.1-1 as far as Debian > and > Ubuntu are concerned: > > * Dropped 70_cups-pdf_support-pdf-workflow.patch >+ This patch has received more criticism than praises from > the end-users, > because it essentially renders the Ghostscript options in > cups-pdf.conf > useless, plus it no longer applies cleanly to the > upstream code. > > From this perspective, I'd mark the issue as fixed since that > version. Agreed? > > Martin-Éric > > just tried installing cups-pdf from sid on my squeeze. GSCall and > PDFVer are taken into acount but... I am only getting 1 page empty > documents; even failling back to the default settings > in /etc/cups/cups-pdf.conf. Could it be due to a dependency issue even > if not raised by the package? > > log file attached > Just as a note: might be related to issue #617468 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619461: cups-pdf: PDFVer and GSCall keys not taken into account
On Thu, 2011-03-24 at 12:15 +0100, Jean-Philippe Thierry wrote:
> sorry. File rights messed it up. Here it is.
>
> 2011/3/24 Volker Behr
> Hi,
>
>
> On Thu, 2011-03-24 at 11:07 +0100, Jean-Philippe Thierry
> wrote:
> > Hi,
> >
> > 2011/3/24 Volker Behr
> > On Thu, 2011-03-24 at 08:54 +0100, Jean-Philippe
> Thierry
> > wrote:
> > > Package: cups-pdf
> > > Version: 2.5.0-16
> > > Severity: normal
> > >
> > > Hi,
> > >
> > > I am trying to set up an encrypted pdf printer
> using
> > cups-pdf. I find my way in
> > > identifying the right command-line options for
> encryption
> > with ps2pdf and
> > > everything works fine.
> > > I then tuned the /etc/cups/cups-pdf.conf file
> changing the
> > GSCall key but
> > > without any success so far :( PDF document is
> generated but
> > is still a PDF 1.3
> > > document (although I set the PDFVer key to 1.4)
> and
> > encryption options are not
> > > taken into account.
> > > I looked at the logs (DEBUG level) but nothing
> there except
> > that it says: found
> > > beginning of pdf code (%PDF-1.3).
> > >
> > > I tried -dCompatibilityLevel=%s,
> -dCompatibilityLevel=1.4,
> > > -dCompatibilityLevel=PDFVer; none of them worked.
> I am
> > probably missing
> > > something straightforward but googling did not
> help me so...
> > >
> > > Thanks for your help
> > >
> > > Jean-Philippe
> > >
> > >
> > >
> > > -- System Information:
> > > Debian Release: 6.0.1
> > > APT prefers squeeze-updates
> > > APT policy: (500, 'squeeze-updates'), (500,
> 'stable')
> > > Architecture: i386 (i686)
> > >
> > > Kernel: Linux 2.6.32-5-686 (SMP w/4 CPU cores)
> > > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8
> > (charmap=UTF-8)
> > > Shell: /bin/sh linked to /bin/dash
> > >
> > > Versions of packages cups-pdf depends on:
> > > ii cups1.4.4-7
> Common UNIX
> > Printing System(tm) -
> > > ii cups-client 1.4.4-7
> Common UNIX
> > Printing System(tm) -
> > > ii ghostscript 8.71~dfsg2-9 The
> GPL
> > Ghostscript PostScript/PDF
> > > ii libc6 2.11.2-10
> Embedded GNU C
> > Library: Shared lib
> > > ii libpaper-utils 1.1.24
> library for
> > handling paper charact
> > >
> > > cups-pdf recommends no packages.
> > >
> > > Versions of packages cups-pdf suggests:
> > > pn system-config-printer-gnome | (no
> description
> > available)
> > >
> > > -- Configuration Files:
> > > /etc/cups/cups-pdf.conf changed:
> > > Out ${HOME}/tmp/PDF
> > > Label 0
> > > Grp lpadmin
> > > LogType 1
> > > PDFVer 1.4
> > > GSCall %s -q -dCompatibilityLevel=PDFVer -dNOPAUSE
> -dBATCH
> > -dSAFER -sDEVICE=pdfwrite -sOutputFile="%s"
> > -dAutoRotatePages=/PageByPage
> -dAutoFilterColorImages=false
> > -dColorImageFilter=/FlateEncode -sOwnerPassword=AjC
> > -dEncryption
Bug#619461: cups-pdf: PDFVer and GSCall keys not taken into account
On Thu, 2011-03-24 at 08:54 +0100, Jean-Philippe Thierry wrote:
> Package: cups-pdf
> Version: 2.5.0-16
> Severity: normal
>
> Hi,
>
> I am trying to set up an encrypted pdf printer using cups-pdf. I find my way
> in
> identifying the right command-line options for encryption with ps2pdf and
> everything works fine.
> I then tuned the /etc/cups/cups-pdf.conf file changing the GSCall key but
> without any success so far :( PDF document is generated but is still a PDF 1.3
> document (although I set the PDFVer key to 1.4) and encryption options are not
> taken into account.
> I looked at the logs (DEBUG level) but nothing there except that it says:
> found
> beginning of pdf code (%PDF-1.3).
>
> I tried -dCompatibilityLevel=%s, -dCompatibilityLevel=1.4,
> -dCompatibilityLevel=PDFVer; none of them worked. I am probably missing
> something straightforward but googling did not help me so...
>
> Thanks for your help
>
> Jean-Philippe
>
>
>
> -- System Information:
> Debian Release: 6.0.1
> APT prefers squeeze-updates
> APT policy: (500, 'squeeze-updates'), (500, 'stable')
> Architecture: i386 (i686)
>
> Kernel: Linux 2.6.32-5-686 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages cups-pdf depends on:
> ii cups1.4.4-7 Common UNIX Printing System(tm)
> -
> ii cups-client 1.4.4-7 Common UNIX Printing System(tm)
> -
> ii ghostscript 8.71~dfsg2-9 The GPL Ghostscript
> PostScript/PDF
> ii libc6 2.11.2-10Embedded GNU C Library: Shared
> lib
> ii libpaper-utils 1.1.24 library for handling paper
> charact
>
> cups-pdf recommends no packages.
>
> Versions of packages cups-pdf suggests:
> pn system-config-printer-gnome | (no description available)
>
> -- Configuration Files:
> /etc/cups/cups-pdf.conf changed:
> Out ${HOME}/tmp/PDF
> Label 0
> Grp lpadmin
> LogType 1
> PDFVer 1.4
> GSCall %s -q -dCompatibilityLevel=PDFVer -dNOPAUSE -dBATCH -dSAFER
> -sDEVICE=pdfwrite -sOutputFile="%s" -dAutoRotatePages=/PageByPage
> -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode
> -sOwnerPassword=AjC -dEncryptionR=3 -dKeyLength=128 -dPermissions=-3904 -c
> .setpdfwrite -f %s
>
>
> -- no debconf information
Hi,
please set LogType to 7 to receive full debug information and check
whether the GSCall given in the debug-log is the one you expect it to
be.
If it is, it is an issue of the options since GhostScript does not
honour them.
If the debug-log shows a different GSCall than the one you set in the
options then for some reason the config-file does not get evaluated
properly and we have to take a deeper look into it.
Regards,
Volker
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#617468: [Pkg-cups-devel] Bug#617468: My cups-pdf is also producing blank pages, downgraded to 2.5.0-16 works
On Thu, 2011-03-17 at 23:25 -0400, Bin Guo wrote: > On Thu, 2011-03-17 at 12:16 +0100, Volker Behr wrote: > > > > Comparing the logs for the two installations of 2.5.1 it seems the files > > printed in either case are not identical and/or not printed the same > > way, so it is hard to discern what differences in the log are due to > > what differences in the setup (e.g., in one case, there is a PS title > > found, in the other it is not). > > > > It would be good to have the log for one empty PDF and one good PDF > > using 2.5.1 (and, of course, identical versions of CUPS and GhostScipt - > > chack that in any case!), both using identical cups-pdf.conf-settings, > > identical PPDs, identical printing commands and identical input files. > > > > Regards, > > Volker > > > > Hi Volker, > > I'm pretty sure that I've printed the same web page: www.cups-pdf.de > The web page's title is CUPS-PDF. All three logs are printed from > iceweasel. >From the log of the empty page you can see that there was no title found within the original PS file that was sent (by iceweasel) to the printer. In the good case there was. So the input obviously differed. Since there was no PS-title in the first case, perhaps there was more information in the file missing so the PDF could not be created. There are two possible culprits I can think of: iceweasel itelf and CUPS/the PPD used. Please make double-sure those are absolutely identical (same version, same revision, same built). The best test for the printing system would be to just print two identical files (e.g. the tiger.eps from Ghostscript's examples) via commandline to the PDF-printer (to avoid any additional interaction by other programs that might decide to modify the input). Regards, Volker -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#617468: [Pkg-cups-devel] Bug#617468: My cups-pdf is also producing blank pages, downgraded to 2.5.0-16 works
On Wed, 2011-03-16 at 15:27 +0200, Martin-Éric Racine wrote: > 2011/3/16 Bin Guo : > > On Mon, 2011-03-14 at 18:35 +0100, Volker Behr wrote: > >> Just as a hint from upstream: you might want to have a look > >> at /var/log/cups/cups-pdf_log with LogType set to 7 > >> in /etc/cups/cups-pdf.conf. > >> I myself have no current Debian available for testing at the moment. > >> > >> Regards, > >> Volker > > > > This is frustrating: while downgraded cups-pdf works, I have > > another debian system that works fine. No idea what changed, > > but on my laptop definitely only 2.5.0-16 works. > > > > Logs: > > cups-pdf_log-2.5.0-16-good (downgraded and working on my laptop) > > cups-pdf_log-2.5.1-1-empty (upgraded but empty on my laptop) > > cups-pdf_log-2.5.1-1-good (upgraded but working on another debian) > > This is confusing, because the exact same 2.5.1-1 somehow works on > another one of your hosts. I wonder why. > > Volker: can you spot anything in those logs that I might have missed? > > Martin-Éric Comparing the logs for the two installations of 2.5.1 it seems the files printed in either case are not identical and/or not printed the same way, so it is hard to discern what differences in the log are due to what differences in the setup (e.g., in one case, there is a PS title found, in the other it is not). It would be good to have the log for one empty PDF and one good PDF using 2.5.1 (and, of course, identical versions of CUPS and GhostScipt - chack that in any case!), both using identical cups-pdf.conf-settings, identical PPDs, identical printing commands and identical input files. Regards, Volker -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#617468: My cups-pdf is also producing blank pages, downgraded to 2.5.0-16 works
Just as a hint from upstream: you might want to have a look at /var/log/cups/cups-pdf_log with LogType set to 7 in /etc/cups/cups-pdf.conf. I myself have no current Debian available for testing at the moment. Regards, Volker On Mon, 2011-03-14 at 00:25 -0400, Bin Guo wrote: > Package: cups-pdf > Followup-For: Bug #617468 > > > I also noticed ALL cups-pdf outputs are blank. I tried downgrading to 2.5.0-16 > and outputs are fine again. All blank PDF files are the same size (2192 byte). > I'll try to attach blank pdf (by cups-pdf 2.5.1-1) and working pdf (by > cups-pdf > 2.5.0-16). > > -- System Information: > Debian Release: wheezy/sid > APT prefers unstable > APT policy: (900, 'unstable'), (800, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.37-2-amd64 (SMP w/2 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages cups-pdf depends on: > ii cups 1.4.6-1 Common UNIX Printing System(tm) > - > ii cups-client 1.4.6-1 Common UNIX Printing System(tm) > - > ii ghostscript 9.01~dfsg-2 interpreter for the PostScript > lan > ii libc62.11.2-13 Embedded GNU C Library: Shared > lib > ii libpaper-utils 1.1.24 library for handling paper > charact > > cups-pdf recommends no packages. > > Versions of packages cups-pdf suggests: > ii system-config-printer 1.2.3-3graphical interface to configure > t > > -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531409: Does the issue still apply to cups-pdf 2.5.1-1 ?
Just for your information in tracking down the bug: A PDF created by the following command line (the one given above as example): echo test | a2ps --title='my test' -2qo- | lp -d pdf yields for me upstream with default-settings of CUPS-PDF (2.5.1 as well as earlier versions) and the default-PPD that is shipped with CUPS-PDF as output filename my_test.pdf To check the concern against the CUPS version, I tested it with CUPS 1.3.9 and CUPS 1.4.4 and in either case it worked. Nevertheless, CUPS cannot do much about it, since it should just pass through the PS to CUPS-PDF, which extractes the PS-title itself. What _might_ make the difference: using different PPDs with CUPS-PDF. Regards, Volker -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606444: segfault
On Tue, 2011-01-04 at 08:54 +0100, Harald Dunkel wrote: > The problem seems to be related to "LogType 7" in the > config file. Using "LogType 3" there is no crash (by now). I just released CUPS-PDF 2.5.1. This fixes a crash due to an unitialized pointer which didn't follow a straight pattern but caused exactly the output shown in this bug. On differnt machines the bug appeared with different settings. With 2.5.1 this should be fixed. Also, logging was improved in case of crashes, so it should be easier to track down similar issues in the future. Regards, Volker -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#556867: cups-pdf: strong kerning errors
On Wed, 2009-11-18 at 17:31 +0100, Dirk Vogt wrote: > Hi, > > > (the spots marked in the pngs look 1:1 the same as in the PDF on my screen) > > I think that the pngs and pdf look the same IS the problem, and by the > way logical, as the pngs are screen shots of the PDF viewer's output. > > In the PDFs and PNGs, a can see obvious problems concerning the kerning > of the font: > > example: > > google.png: the first 'o' is way to near to the 'g' of google. Also > between the 'g' and the 'l' in the word google is not enough space. > Ok, I checked that again - with Firefox (or any related browser) I get exactly the kerning errors shown. With Opera the page looks just fine. I remember in the past several issues with PostScript-Code generated by Firefox. This issue cannot be fixed by CUPS-PDF, since probably it is some trouble with the original PostScript-Code (generated by Firefox). In case it is an issue of the processing of this PS-code that has to be fixed by GhostScript which is the utility CUPS-PDF employs internally to convert PS to PDF. Regards, Volker -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#556867: cups-pdf: strong kerning errors
On Wed, 2009-11-18 at 01:05 +0100, Michael wrote: > Package: cups-pdf > Version: 2.5.0-12 > Severity: grave > Tags: patch > Justification: renders package unusable > > I do not know, whether this is a CUPS-PDF bug or not, but at least the PDF > files created on my computer look horrible (also when printing them!). > > See the files free.pdf and google.pdf printed out from Iceweasel (and the > three examples I marked in the pngs) > > > -- System Information: > Debian Release: squeeze/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.31-6.slh.2-sidux-amd64 (SMP w/2 CPU cores; PREEMPT) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages cups-pdf depends on: > ii cups 1.4.1-5Common UNIX Printing System(tm) > - > ii cups-client 1.4.1-5Common UNIX Printing System(tm) > - > ii ghostscript 8.70~dfsg-2+b1 The GPL Ghostscript > PostScript/PDF > ii libc6 2.10.1-7 GNU C Library: Shared libraries > ii libpaper-utils1.1.23+nmu1library for handling paper > charact > > cups-pdf recommends no packages. > > Versions of packages cups-pdf suggests: > ii system-config-printer-kde 4:4.3.2-1 KDE 4 printer configuration > utilit > > -- no debconf information I viewed the two examples with evince, gv and acroread and failed to see any issues (the spots marked in the pngs look 1:1 the same as in the PDF on my screen) - my system is not Debian, so it might still be an issue with Debian's viewers but the PDF themselves seem absolutely fine to me. Regards, Volker -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531409: [Pkg-cups-devel] Bug#531409: cups-pdf: no longer deduces filename for output file from PS title
Just as a quick comment: whether the PS-title or the command-line title ist prefered can be set via cups-pdf.conf, option TitlePref. Regards, Volker On Mon, 2009-06-01 at 13:39 +0300, Martin-Éric Racine wrote: > On Mon, Jun 1, 2009 at 1:23 PM, martin f krafft wrote: > > Package: cups-pdf > > Version: 2.5.0-2 > > Severity: normal > > > > Not too long ago (~4-5 months), cups-pdf would use the postscript > > title for the output filename. Now it just uses the same name as > > passed on the command line, or _stdin_.pdf. > > > > piper:~|master|% echo test | a2ps --title='my test' -2qo- | grep '^%%Title' > > %%Title: my test > > piper:~|master|% echo test | a2ps --title='my test' -2qo- | lp -d pdf > > request id is pdf-1158 (1 file(s)) > > piper:~|master|% ls -l ~/PDF/*.pdf > > -rw--- 1 madduck madduck 5494 2009-06-01 12:14 > > /home/madduck/PDF/_stdin_.pdf > > > > I am pretty sure this worked with 2.4.8, so I assume it's > > a regression in 2.5.0, possibly related to Ubuntu#237224, though > > I did not verify that. > > Thanks for reporting this. > > I would be more inclined to think that it's a regression in CUPS > itself starting with 1.3.10, since CUPS-PDF 2.5.0 works fine using > CUPS 1.3.9 (at least on Ubuntu). I just did a quick test, printing > this message from the BTS via Gmail on Firefox and I correctly got the > long HTML document title as the filename found in ~/PDF. > > Martin-Éric -- Dr. rer. nat. Volker Christian Behr Experimentelle Physik V (Biophysik), Physikalisches Institut Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany Office: Room F-069a +49-931-31-85766 (phone) +49-931-888-5851 (fax) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524730: problem with text in pdf files created with cups-pdf
Just some information from upstream: I just checked CUPS-PDF 2.5.0 using the CUPS-PDF.ppd with two tests: a) printing a textfile directly to a PDF (lp -d CUPS-PDF .bashrc) b) converting a textfile with a2ps to PS and then printing it to PDF (a2ps .bashrc -o - | lp -d CUPS-PDF) In either case the text was fully intact and I could copy and paste arbitraty sections out of it and do a text-search on it. So this might be an issue of the application creating the the original document (maybe this application already creates a PS file with text being converted to graphics). If that is the case, CUPS-PDF works as designed since it never got any text to convert. BEWARE: the above mentioned tests were NOT done on a Debian system! So you should try to reproduce them. Regards, Volker -- Dr. rer. nat. Volker Christian Behr Experimentelle Physik V (Biophysik), Physikalisches Institut Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany Office: Room F-069a +49-931-31-85766 (phone) +49-931-888-5851 (fax) On Sun, 2009-04-19 at 15:40 +0200, Anders Lagerås wrote: > Package: cups-pdf > Version: 2.5.0-1 > Severity: important > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > If CUPS-PDF.ppd is used as recommended does not the pdf files created contain > text, instead is everthing seems to be handled as graphics, resulting in large > non searchable pdf files. > > - -- System Information: > Debian Release: squeeze/sid > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) > Locale: LANG=en_US, LC_CTYPE=sv_SE (charmap=ISO-8859-1) > Shell: /bin/sh linked to /bin/bash > > Versions of packages cups-pdf depends on: > ii cups 1.3.10-1Common UNIX Printing System(tm) > - > ii cups-client 1.3.10-1Common UNIX Printing System(tm) > - > ii ghostscript 8.64~dfsg-1 The GPL Ghostscript > PostScript/PDF > ii libc62.9-7 GNU C Library: Shared libraries > ii libpaper-utils 1.1.23+nmu1 library for handling paper > charact > > cups-pdf recommends no packages. > > Versions of packages cups-pdf suggests: > pn system-config-printer-gnome | (no description available) > > - -- no debconf information > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAknrKdwACgkQw5UvgfnzqGq0NgCePLg2Fp8P4kSt64wJ+hyDNQQv > MZcAnRtqxI98Ieyg77ng6hpsRUNVhUtu > =W7Ed > -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#502624: cups-pdf: "Test page" from web interface should use real user instead of 'anonymous'
On Tue, 2008-12-23 at 22:06 +0200, =?UTF-8?Q? Martin-=C3=89ric?= Racine wrote: > > Otherwise one can't print a test page when 'anonymous' is disabled in > > cups-pdf configuraiton file. Moreover, no errors are reported either > > in web interface or log files in this case. > > > Looking at the completed jobs I conclude that Etch version used real > > users to print test pages. So, this sudden change after upgrade to Lenny > > confused me while I was trying to locate the printed test page in ~/PDF > > folder. > > This report seems to confuse too many issues. Let's divide those into > smaller blocks: > > 1. what user should be used to generate the test page? (a CUPS issue) ...and that's already the end of the story. Since CUPS-PDF has no means to determine whether a specific page is a CUPS test page (no, CUPS-PDF will never do an in-detail analysis of the contents of the PostScript passed to it) the test page will always be printed as the user CUPS chooses for printing it. > 2. where should the test page file be saved to? (a CUPS-PDF issue) This is solely determined by the user chosen at 1. (i.e. by CUPS). > 3. whether CUPS-PDF should be dependent upon the AnonUser being > enabled to produce a test page? > a) if yes, should it print an error message to alert the administrator > that, when AnonUser is disabled, it cannot produce the test page? > b) if not, which system user should be used to produce the test page? > (all those are CUPS-PDF issues) Once again: since I do not have any chance to tell a test page apart from a real print job, the statements made above fully apply. In case of denied anonymous accesses already now CUPS-PDF prints an "anonymous access denied" as INFO-message to its log file. Regards, Volker > Fellow CUPS maintainers and the CUPS-PDF upstream author are welcome > to comment if I forgot anything. > > Martin-Éric -- Dr. rer. nat. Volker Christian Behr Experimentelle Physik V (Biophysik), Physikalisches Institut Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany Office: Room F-069a +49-931-31-85766 (phone) +49-931-888-5851 (fax) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#501719: [Fwd: Re: [Pkg-cups-devel] Bug#501719: cups-pdf: doesn't play well with NetWare shares]
Hi, an according note has been added to the documentation in the upstream sources of v2.5.0 which will be available later this day. Regards, Volker Behr On Tue, 2008-10-28 at 10:04 +0100, Volker Behr wrote: > Hi, > > On Mon, 2008-10-27 at 18:56 +0100, Luca Capello wrote: > > tags 501719 + patch > > thanks > > [...] > > --8<---cut here---start->8--- > > --- cups-pdf-2.4.8/README.~1~ 2008-06-22 13:41:29.0 +0200 > > +++ cups-pdf-2.4.8/README 2008-10-27 18:35:03.0 +0100 > > @@ -45,6 +45,13 @@ > > and set the file permissions of the backend to 0700 (root only). > > *make sure if any of CUPS-PDF's working directories (e.g. output) is a > > NFS mounted volume it is mounted without root_squash! > > + *make sure that the filesystem for any of CUPS-PDF's working directories > > +(e.g. output) features all basic properties of UNIX-filesystems, > > +especially chown(1) and chmod(1). This means that if you want to use a > > +NetWare share as CUPS-PDF's output directory, the NetWare share should > > be > > +mount with the ncpfs' options uid and gid set to the user that want to > > +print her/his PDFs there. This was extensively discussed in the Debian > > +bug #501719 (http://bugs.debian.org/501719). > > *CUPS-PDF is known to fail if the gs (GhostScript) binary on a system > > is > > compressed by upx (Ultimate Packer for eXecutables). > > *if you are using SELinux make sure it does not interfere with CUPS-PDF > > --8<---cut here---end--->8--- > > [...] > > I will add an according paragraph upstream to the documentation as > already mentioned earlier. > > Regards, > Volker > -- Dr. rer. nat. Volker Christian Behr Experimentelle Physik V (Biophysik), Physikalisches Institut Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany Office: Room F-069a +49-931-31-85766 (phone) +49-931-888-5851 (fax) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#503928: per-user configuration of output directory
Configuration of CUPS-PDF via lpoptions will be a feature of the next version 3.x . Regards, Volker On Wed, 2008-10-29 at 12:32 +0100, martin f krafft wrote: > Package: cups-pdf > Version: 2.4.8-3 > Severity: wishlist > Tags: upstream > > It would be nice if I could use .lpoptions to tell CUPS-PDF that > I want PDF files written to ~/.tmp without having to impose this on > every other user! > > -- System Information: > Debian Release: lenny/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) > Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages cups-pdf depends on: > ii cups 1.3.8-1lenny2 Common UNIX Printing System(tm) > - > ii cups-client 1.3.8-1lenny2 Common UNIX Printing System(tm) > - > ii ghostscript 8.62.dfsg.1-3.1 The GPL Ghostscript > PostScript/PDF > ii libc62.7-15 GNU C Library: Shared libraries > ii libpaper-utils 1.1.23+nmu1 library for handling paper > charact > > cups-pdf recommends no packages. > > Versions of packages cups-pdf suggests: > pn system-config-printer-gnome | (no description available) > > -- no debconf information > > -- Dr. rer. nat. Volker Christian Behr Experimentelle Physik V (Biophysik), Physikalisches Institut Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany Office: Room F-069a +49-931-888-5766 (phone) +49-931-888-5851 (fax) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501719: [Fwd: Re: [Pkg-cups-devel] Bug#501719: cups-pdf: doesn't play well with NetWare shares]
Hi, On Mon, 2008-10-27 at 18:56 +0100, Luca Capello wrote: > tags 501719 + patch > thanks > [...] > --8<---cut here---start->8--- > --- cups-pdf-2.4.8/README.~1~ 2008-06-22 13:41:29.0 +0200 > +++ cups-pdf-2.4.8/README 2008-10-27 18:35:03.0 +0100 > @@ -45,6 +45,13 @@ > and set the file permissions of the backend to 0700 (root only). > *make sure if any of CUPS-PDF's working directories (e.g. output) is a > NFS mounted volume it is mounted without root_squash! > + *make sure that the filesystem for any of CUPS-PDF's working directories > +(e.g. output) features all basic properties of UNIX-filesystems, > +especially chown(1) and chmod(1). This means that if you want to use a > +NetWare share as CUPS-PDF's output directory, the NetWare share should be > +mount with the ncpfs' options uid and gid set to the user that want to > +print her/his PDFs there. This was extensively discussed in the Debian > +bug #501719 (http://bugs.debian.org/501719). > *CUPS-PDF is known to fail if the gs (GhostScript) binary on a system is > compressed by upx (Ultimate Packer for eXecutables). > *if you are using SELinux make sure it does not interfere with CUPS-PDF > --8<---cut here---end--->8--- > [...] I will add an according paragraph upstream to the documentation as already mentioned earlier. Regards, Volker -- Dr. rer. nat. Volker Christian Behr Experimentelle Physik V (Biophysik), Physikalisches Institut Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany Office: Room F-069a +49-931-888-5766 (phone) +49-931-888-5851 (fax) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501719: cups-pdf: doesn't play well with NetWare shares
Hi! On Fri, 2008-10-17 at 21:55 +0200, Luca Capello wrote: > Hi again, Volker! > > On Fri, 17 Oct 2008 21:45:05 +0200, Luca Capello wrote: > > However, I performed more tests and I found the *real* error. > > > > If the output directory doesn't exists, CUPS-PDF fails with an error: > > = > > [DEBUG] switching to new gid (lpadmin) > > [DEBUG] initialization finished (v2.4.8) > > [DEBUG] user identified (irlab) > > [DEBUG] output directory name generated (/mnt/Novell/PROD/PDF-Printer) > > [STATUS] directory created (/mnt/Novell/PROD/PDF-Printer) > > [DEBUG] user output directory created (/mnt/Novell/PROD/PDF-Printer) > > [ERROR] failed to set owner for output directory (irlab) > > = > > The more I think about it, the more I don't understand why CUPS-PDF > wants to set the ownership for the output directory :-( CUPS-PDF creates by default a new directory for each user that is only accessible by this user (since the created documents might be confidential and therefore must not be accessible by everyone by default). To make it accessible by just one single user the directory is chown-ed to this user and the permissions are set to 700. > > While this seems not to be a bug in CUPS-PDF (please feel free to > > reassign it to ncpfs [2]), however CUPS-PDF should report a more > > informative error. > > With my feelings above, this is still a bug in CUPS-PDF. I disagree that this is a bug - it behaves exactly as designed. Nevertheless I admit that I should make a clearer statement in the documentation that I assume a filesystem for the output that features all basic properties of UNIX-filesystems. Regards, Volker > Thx, bye, > Gismo / Luca -- Dr. rer. nat. Volker Christian Behr Experimentelle Physik V (Biophysik), Physikalisches Institut Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany Office: Room F-069a +49-931-888-5766 (phone) +49-931-888-5851 (fax) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501719: cups-pdf: doesn't play well with NetWare shares
At a first glance it looks like GhostScript is failing (return code 256). Since it is working for root, it might be an issue with file permissions on the Netware volume. Is the user 'irlab' allowed to write to /mnt/Novell/PROD/PDF-Printer? Does the test.pdf already exist? If so, is 'irlab' allowed to overwrite it? On Thu, 2008-10-09 at 22:08 +0200, Luca Capello wrote: > Package: cups-pdf > Version: 2.4.8-3 > Severity: important > > Hi there! > > Note1: I set Severity: important because I cannot find any reference >about this particular problem in the CUPS-PDF documentation nor >on the net, feel free to downgrade it at most to normal. > > Note2: this can be similar to bug #496317 [1], but the origins are >different, that's why I submitted a new bug. > > Note3: AFAIK ncp doesn't offer a 'root_squash' option. > > I setup a print server for Windows/OSX machines for the laboratory > where I work and it's working pretty well. Instead of installing one of > the free (as in beer) virtual PDF printers for Windows, I decided to > offer a different free (as in speech) solution thanks to CUPS-PDF. > > A bit more about my laboratory setup: we don't use user logins, but only > one for everyone and on every computer. Since our university offers > NetWare shares (incrementally backup-ed), all of our documents are > stored on one unique NetWare volume. > > My idea is simple: from their Windows/OSX machines colleagues print to > the shared CUPD-PDF printer, which saves the PDF file in one specific > folder on the NetWare volume. However, this doesn't work and there's no > useful error shown by CUPS-PDF :-( > > The print server setup: > > - irlab/PDF is a symlink to /mnt/Novell/PDF-Printer > > - the NetWare share is mounted with ncp options > noatime,rw,exec,auto,multiple,gid=plugdev,mode=775 > > - /mnt/Novell, when the NetWare share is not mounted, has permissions > 775 and is owned by root:plugdev > > - irlab is in the plugdev group > > With the setup above, even when printing from command line through lpr, > the situations is the following, with logging at level 7: > > a) irlab cannot print > = > [DEBUG] switching to new gid (lpadmin) > [DEBUG] initialization finished (v2.4.8) > [DEBUG] user identified (irlab) > [DEBUG] output directory name generated (/mnt/Novell/PROD/PDF-Printer) > [DEBUG] user information prepared > [DEBUG] spoolfile name created (/var/spool/cups-pdf/SPOOL/cups2pdf-4115) > [DEBUG] source stream ready > [DEBUG] destination stream ready (/var/spool/cups-pdf/SPOOL/cups2pdf-4115) > [DEBUG] owner set for spoolfile (/var/spool/cups-pdf/SPOOL/cups2pdf-4115) > [DEBUG] found beginning of postscript code (%!PS-Adobe-3.0) > [DEBUG] now extracting postscript code > [DEBUG] found title in ps code ((test.txt)) > [DEBUG] found embedded (e)ps code (%!PS-AdobeFont-1.0: Courier-Bold 1.05) > [DEBUG] found embedded (e)ps code (%!PS-AdobeFont-1.0: Courier 1.05) > [DEBUG] found embedded (e)ps code (%!PS-AdobeFont-1.0: Symbol 001.005) > [DEBUG] found end of embedded (e)ps code (%%EOF) > [DEBUG] all data written to spoolfile > (/var/spool/cups-pdf/SPOOL/cups2pdf-4115) > [DEBUG] trying to use PS title ((test.txt)) > [DEBUG] removing trailing newlines from title ((test.txt)) > [DEBUG] removing enclosing parentheses () from full title ((test.txt)) > [DEBUG] removing file name extension (.txt) > [DEBUG] removing special characters from title (test) > [DEBUG] title successfully retrieved (test) > [DEBUG] input data read from stdin > [DEBUG] output filename created (/mnt/Novell/PROD/PDF-Printer/test.pdf) > [DEBUG] ghostscript commandline built (/usr/bin/gs -q > -dCompatibilityLevel=1.4 \ > -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite \ > -sOutputFile="/mnt/Novell/PROD/PDF-Printer/test.pdf" \ > -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false \ > -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress \ > -c .setpdfwrite -f /var/spool/cups-pdf/SPOOL/cups2pdf-4115) > [DEBUG] output file unlinked (/mnt/Novell/PROD/PDF-Printer/test.pdf) > [DEBUG] TMPDIR set for GhostScript (/var/tmp) > [DEBUG] entering child process > [DEBUG] GID set for current user > [DEBUG] UID set for current user (irlab) > [DEBUG] ghostscript has finished (256) > [ERROR] failed to set file mode for PDF file (non fatal) > (/mnt/Novell/PROD/PDF-Printer/test.pdf) > [DEBUG] ERRNO: 2 > [DEBUG] waiting for child to exit > [DEBUG] spoolfile unlinked (/var/spool/cups-pdf/SPOOL/cups2pdf-4115) > [DEBUG] all memory has been freed > [STATUS] PDF creation successfully finished (irlab) > = > >The only error I get seems to be non fatal, which according to [2], >is not true: if this kind of error is fatal, why the '(non fatal)' >statement? And if Ghostscript exits with an error (256), why isn't >this marked as so by CUPS-PDF? > >FWIW, so far I've failed to mount the NetWare share with file/mode >permission features and I've tested all the nc
Bug#496317: [Pkg-cups-devel] Bug#496317: cups-pdf: only works for root
On Sun, 2008-08-24 at 15:42 +0300, =?UTF-8?Q? Martin-=C3=89ric?= Racine wrote: > 496317 severity normal > thanks > > On Sun, Aug 24, 2008 at 3:20 PM, Jasen Betts <[EMAIL PROTECTED]> wrote: > > Package: cups-pdf > > Version: 2.4.8-2 > > Severity: grave > > Justification: renders package unusable > > > > > > the cups-pdf printer driver only works for root. > > > > when invoked by a user it produces no output in the ~/PDF > > directory > > > > as a regular user: > > $ lpr mozilla.ps > > $ ls -al ~/PDF > > total 24 > > drwx-- 2 jasen jasen 4096 2008-08-22 23:50 . > > drwxrwxr-x 141 jasen jasen 20480 2008-08-25 00:06 .. > > There's your explanation: you chose to make your home directory > writable by yourself only. Usually CUPS-PDF should assume the UID of the printing user thereby being allowed to write to the home. > > #cat /var/log/cups/cups-pdf_log > > Mon Aug 25 00:10:31 2008 [ERROR] failed to set file mode for PDF file (non > > fatal) (/home/jasen/PDF/mozilla.pdf) > > ...which the log confirms. This results from no file being generated at all. is there any AppArmour oder SELinux in place? Otherwise the more detailed debug-output might be of use (to be enabled in cups-pdf.conf). Regards, Volker > -- Volker Christian Behr Experimentelle Physik V (Biophysik), Physikalisches Institut Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany Office: Room F-069a +49-931-888-5766 (phone) +49-931-888-5851 (fax) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#472631: cups-pdf: typo in config file
Typo fixed upstream in version 2.4.8. Alvaro Herrera wrote: > Package: cups-pdf > Version: 2.4.6-5 > Severity: minor > > > In /etc/cups/cups-pdf.conf, the description of the Cut parameter says > "is not longer than " -- it should read "is not longer than ". > > -- System Information: > Debian Release: lenny/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) > Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > > Versions of packages cups-pdf depends on: > ii cupsys 1.3.6-2 Common UNIX Printing System(tm) > - > ii cupsys-client1.3.6-2 Common UNIX Printing System(tm) > - > ii gs-esp 8.15.3.dfsg.1-1 The Ghostscript PostScript > interpr > ii gs-gpl 8.56.dfsg.1-1.1 The GPL Ghostscript PostScript > int > ii libc62.7-6 GNU C Library: Shared libraries > ii libpaper-utils 1.1.23 library for handling paper > charact > > cups-pdf recommends no packages. > > -- no debconf information > -- Volker Christian Behr Experimentelle Physik V (Biophysik), Physikalisches Institut Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany Office: Room F-069a +49-931-888-5766 (phone) +49-931-888-5851 (fax) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
