user can't find the generated pdf files

2. 4. and 5. were previously attempted, but users found this distracting or, in a few cases, that it could put existing documents in danger of being overwritten in case a similarly-named document already exists there.

1 and 3. might be possible, now that CUPS is finally Dbus-aware, so adding some support for this in CUPS-PDF too might not be entirely impossible, but it would probably render the codebase incompatible with older CUPS releases. Still, investigating this might be a good Summer of Code project. It would be useful for whoever attempts this to contact upstream and coordinate with him.

For 3. it would also work if one has a notifier which watches the PDF directory and pops up a notification if a new file is there.

Does such a notifier exist?

Another option is to simply dump it to the desktop and let the user decide where to store it, similar to where gnome-volume-manager puts its icons.

Outputting to any directory, be it ~home or Desktop or some other arbitrary location, has been repeatedly seen by users as potentially dangerous, because files could be overwritten. The problem is that every user has a different idea of how this should be handled: some users would prefer getting job numbers automatically appended to all filenames, while others prefer keeping the document's original name and older versions of a similarly named document always being overwritten. This is how I came to the compromise of this ~/CUPS-PDF (previously ~/PDF) folder.

besides, let's put things in perspective: all 3 desktop environments supported by Ubuntu have their own printing system in place, which means that CUPS-PDF's only role on Ubuntu is as an "if all else fails" catch-all safety net. This is mainly useful for non-GNOME and non-KDE applications, such as Firefox or OpenOffice, that directly access CUPS back-ends rather that use e.g. gnomeprint as a printing front-end to CUPS.

Well, the "overwritten file" problem should not a hard one to solve... it's not really that hard to use a different filename if that file exists (of course there's a potential race condition if the user is trying to create another file with the exact same name at the exact same time, but this is really not a case to code around, IMHO)

Agreed that every user would want the file in a different place, but the best default choice is the desktop, since that's the most visible, and is the one _least_ likely to cause the user to think that the PDF printer did nothing.

I certainly think a notification icon or (heavens!) an file save dialog would be best, but if you're going to put the file somewhere without asking, put it on the desktop.

It's not just a different place. Some users WANT to overwrite old files.

Regardless, let's keep in mind that CUPS-PDF is not meant to be used with a desktop environment or any environment in particular. It is only a CUPS back-end. All those ideas about notification icons etc. are nice when the code is a GNOME or KDE component, but they transpose poorly to daemon back-ends.

The overwriting is another bug -> Bug #134671

Here we discuss the simple fact that when a user print using cups-pdf, he don't know where his pdf is.

So how can we resolv this ?

Certainly, CUPS-PDF was intended to be a server-oriented solution (IMHO it's not so great, even for that use case), but the package is now being used in a desktop environment. It is in the initial Ubuntu install. It seems GNOME/KDE integration must be done if this feature is to be present in the default UI.

I suppose the answer is for someone to code up a patch that implements one of the 5 options presented in the bug report and attach it to this report, since arguing about CUPS-PDF means in the desktop is pointless without code ;-)

This comment is a bit off-topic, but I don't want to start a new topic for what may be a minor issue.

In Feisty, the CUPS-PDF output directory was set by default to ~/PDF in the CUPS-PDF configuration file. I changed this to ~/work, and the PDF files created by CUPS-PDF were saved to that directory.

After upgrading to Gusty, the configuration file still showed the CUPS-PDF output directory as ~/work. However, the PDF files were not saved to that directory or any directory that I could find. So, I changed the output directory to ~/PDF (i.e. ${HOME}/PDF) in the configuration file, and the PDF files were saved in that directory.

Why are we no longer able to specify the output file in the configuration file.

I have withdrawn the proposed fix of moving the output to the ~/Desktop directory as this will have several problem. Users can configure another directory to be displayed on the desktop and also they could not like the desktop being cluttered by the generated PDFs. So we will leave the destination being "~/PDF", as no known application is using this directory.

The only solution would be using either a D-Bus notification or better a pop-up asking the user where to drop the file. This would need major changes to be done by upstream for which it is too late to include them in Gutsy.

In general it is a much better soplution to have the applications by themselves generating PDFs via "File"/"Export to PDF ..." or "File"/"Print ...". OpenOffice.org has "File"/"Export to PDF ..." and the current printing dialogs of both KDE and GNOME have functionality to print into a PDF file, actually saving it as PDF, asking the user for name and location. This is the most intuitive and does not involve any system process which runs with other rights than the calling user, so it gives also the maximum security.

cups-pdf is an interim solution for all the apps which did not yet adopt the latest printing dialogs (especially Firefox and Thunderbird). So we will remove cups-pdf from Ubuntu as soon as all apps have caught up. In the mean time we will only sync with upstream and fix bugs.

The real bug is in the apps which do not use the current printing dialogs.

To modred: If you have e.g. cups-pdf configured to place the created files in $HOME/work, you'll need to change cups-pdf-settings in /etc/apparmor.d/usr.sbin.cupsd file, too.

Given you want still to have the files in $HOME/work, you'll need to apply the following changes

Change the line:

Out ${HOME}/PDF

into:

Out ${HOME}/work

in your /etc/cups/cups-pdf.conf

_and_ the lines:

  @{HOME}/PDF/ w,
  @{HOME}/PDF/* w,

into:

  @{HOME}/work/ w,
  @{HOME}/work/* w,

in your "/etc/apparmor.d/usr.sbin.cupsd" file.

After restarting apparmor and cups, you'll be able to print to the given location.

cups-pdf (2.4.6-3ubuntu8) gutsy; urgency=low

  * debian/patches/50_default_conf.patch: Use ~/Desktop as default destination
    for the PDF files so that users find them more easily (LP: #134682,
    LP: #134671)
  * debian/prerm, debian/postinst: Make any failure of CUPS command line tools
    non-fatal, to not affect the setup of cups-pdf if CUPS crashes immediately
    after being restarted by the cups-pdf setup (LP: #136449, LP: #147974).
  * debian/control: Require cupsys 1.3.2-1ubuntu2 or newer, to have
    AppArmor restrictions allowing to write into ~/Desktop.

 -- Till Kamppeter <email address hidden> Wed, 4 Oct 2007 17:56:19 +0100

To Till: Wouldn't it be better to use something like "XDG_DESKTOP_DIR" instead of hardcoding the "Desktop" value? I don't know, but it may be that other locales are using different names for the Desktop directory.

Gert, this is once too late for Gutsy, and second, AppArmor will probably not know what "XDG_DESKTOP_DIR" means.

I will upload a new cups-pdf package soon which returns to ~/PDF being used as output dir.

You're right, apparmor doesn't know anything about XDG variables, so forget my comment.

Hopefully my last comment on this and similar bugs:

Obviously there are users, who want to change the default output directory, but do not know that they need to change the apparmor profile, too. Wouldn't it be possible, to add something like this in the according comment of /etc/cups/cups-pdf.conf:

### Key: Out
## CUPS-PDF output directory
[...]
## For Ubuntu Gutsy users: If you change the default output location,
## please make sure to change the according settings in
## /etc/apparmor.d/usr.sbin.cupsys file, too.
[...]

Gert,

Thanks for the response.

I put the entries...

Out ${HOME}/work

in the cups-pdf.conf file and...

@{HOME}/work/ w,
@{HOME}/work/* w,

in the usr.bin.cupsd file.

After making the above changes and rebooting, I opened Firefox and attempted to print several web pages to a PDF file. I could not find the PDF files in the ~/work directory or any other directory.

I then changed "work" back to "PDF" in the above configuration files and and, once again, attempted to print several web pages to a PDF file. These PDF files were created in the PDF directory as expected.

I double checked spelling and capitalization, and I rebooted after making the changes.

Thanks again!

Modred

To Modred: The problem is that if you want to use "PUT-HERE-YOUR-DESIRED-LOCATION" directory, you'll need to change _both_ /etc/cups/cups-pdf.conf _and_ /etc/apparmor.d/usr.sbin.cupsys files to point to the _same_ location. The "PUT-HERE-YOUR-DESIRED-LOCATION" directory has to be a real directory, a symlink would not work.

Gert,

I guess I'm confused. I changed the /etc/cups/cups-pdf.conf file. I also changed the /etc/apparmor.d/usr.sbin.cupsd file. Both files point to my ~/work directory, which is a real directory and not a symlink. I cannot find a file with the name and path /etc/apparmor.d/usr.sbin.cupsys.

I upgraded the same install from Dapper to Feisty and now to Gutsy. Perhaps something is gunked up that is causing me this issue.

It's actually not that difficult to use the PDF directory rather than the work directory, and that's what I'm going to do.

Thanks for your help.

Modred

Excuse me, it was a typo: instead of /etc/apparmor.d/usr.sbin.cupsys it should be: /etc/apparmor.d/usr.sbin.cupsd.

But you're right: better use the default settings.

cups-pdf (2.4.6-3ubuntu10) gutsy; urgency=low

  * debian/postinst: Before creating a CUPS queue wait 3 seconds to be sure
    that the CUPS daemon is listening (LP: #152293).

cups-pdf (2.4.6-3ubuntu9) gutsy; urgency=low

  * debian/patches/50_default_conf.patch: Withdrawn the chnage of the PDF
    destination to ~/Desktop, returned to ~/PDF, also do not let cups-pdf
    label documents with job numbers by default (see LP bugs 134682 and
    134671).
  * debian/control: Removed the versioned require on cupsys, as we have
    withdrawn the change of the PDF destination.

cups-pdf (2.4.6-3ubuntu8) gutsy; urgency=low

  * debian/patches/50_default_conf.patch: Use ~/Desktop as default destination
    for the PDF files so that users find them more easily (LP: #134682,
    LP: #134671)
  * debian/prerm, debian/postinst: Make any failure of CUPS command line tools
    non-fatal, to not affect the setup of cups-pdf if CUPS crashes immediately
    after being restarted by the cups-pdf setup (LP: #136449, LP: #147974).
  * debian/control: Require cupsys 1.3.2-1ubuntu2 or newer, to have
    AppArmor restrictions allowing to write into ~/Desktop.

cups-pdf (2.4.6-3ubuntu7) gutsy; urgency=low

  * debian/control: Add explicit cupsys-client dependency, since the postinst
    needs 'lpadmin' and cupsys itself only recommends -client.
    (LP: #134453)

cups-pdf (2.4.6-3ubuntu6) gutsy; urgency=low

  * debian/postinst: Fix invocation of "lpstat -r" (remove backticks). This
    makes the automatic setup of the PDF queue actually work again.

cups-pdf (2.4.6-3ubuntu5) gutsy; urgency=low

  * debian/postinst: force PDF queues on localhost only; systems configured
    for remote CUPS servers are not expecting it.

cups-pdf (2.4.6-3ubuntu4) gutsy; urgency=low

  * debian/postinst, debian/prerm: Check, create, or remove PDF queues only
    if the CUPS daemon is running, otherwise go on silently (LP: #133743).

cups-pdf (2.4.6-3ubuntu3) gutsy; urgency=low

  * debian/postinst: Only set up the PDF queue, do not make it the default.
    Otherwise the PDF queue would stay the default when the first real printer
    is detected after installation and as the installation of the packages
    happens before the detection of the printers all systems will have the PDF
    queue as default.

cups-pdf (2.4.6-3ubuntu2) gutsy; urgency=low

  [ Till Kamppeter ]
  * debian/control: Updated dependencies: ghostscript, paperconf.
  * debian/postinst, debian/prerm: Create a PDF print queue when installing
    and take it down when uninstalling (LF: #82674)
  * debian/patches/10_auto_assign_ppd.patch: Make the PPD automatically
    assigned to the PDF printer by CUPS/printer setup tools
  * debian/rules: Enabled the package for applying patches by adding
    "include /usr/share/cdbs/1/rules/simple-patchsys.mk"

  [ Martin Pitt ]
  * Now that we use simple-patchsys.mk, make a proper patch
    debian/patches/01_mkdir_as_user.patch from the src/cups-pdf.c change in
    the last upload. Also move the default configuration changes into a patch
    50_default_conf.patch, so that the diff.gz is now free of upstream diffs.
  * debian/postinst: If paperconf fails, fall back to paper size "a4"...

This bug got accidentally closed by a buggy upload process. Reopening ...

This is still in Hardy, just FYI. When you print, you have 'Print to file' which can do PDF and asks you where to save it, and you have 'PDF', which causes the file to go nowhere, as far as the user is concerned. PDF should be hidden from user dialogues I think, it's isn't necessary and isn't useful.

I have solved this problem on hardy writing a simple server in python that I added to my session autostart list, then i have modified cups-pdf which now, after reading the configuration file, connect to the server sending him the path to the output file. The server create and present the user a file save dialog pointing at that path and the user can simply save there or choose another output file. The dialog ask confirmation if the file already exists. The server sends back to cups-pdf the chosen path which is used as the destination file. If the server is not active cups-pdf simply use the directory in the configuration file as destination. The server default port is 50000, but can be passed as first parameter to the program, the client also try to connect to the 50000 as default but the port can be changed in cups-pdf.conf adding the key FileChooserPort. The server accept connections only from 127.0.0.1 and only from one client at a time. I think dbus should be used for this task but for me was simpler to implement a tcp server. If this solution is acceptable for someone else i can attach the code and instructions to build and install.

This bug is still in Ubuntu 8.10.

sudo aa-complain cups
used to work in Intrepid but now when I tried to do this in Jaunty

It gives me the following:
Can't find cups in the system path list. If the name of the application is correct, please run 'which cups' as a user with the correct PATH environment set up in order to find the fully-qualified path.

sudo aa-complain cupsd

works in Jaunty

This issue has been fixed in Karmic by modifying the AppArmor rule for cups-pdf. Marking this bug as fixed.

When printing to a PDF file (from Firefox), the PDF file is created, then deleted before the user can access it.

I tried adding info to bug #879172 (https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/879172), but bug #879172 was closed 3 years ago.

I am encountering this bug in Ubuntu 16.10 x86-64, cups-pdf 2.6.1-21

The appropriate lines in /etc/apparmor.d/usr.sbin.cupsd are:
  capability mknod,
  capability dac_override,
  capability dac_read_search,
  @{HOME}/PDF/ rw,
  @{HOME}/PDF/* rw,

The appropriate line in cups-pdf.conf (attached in its entirety) is:
Out ${HOME}/PDF

The log file, /var/log/cups/cups-pdf_log, contains the following debug output:
Tue Feb 7 12:13:07 2017 [DEBUG] title successfully retrieved (235___Bugs___cups-pdf_package___Ubuntu)
Tue Feb 7 12:13:07 2017 [DEBUG] input data read from stdin
Tue Feb 7 12:13:07 2017 [DEBUG] output filename created (/local/home/skelem/PDF/235___Bugs___cups-pdf_package___Ubuntu.pdf)
Tue Feb 7 12:13:07 2017 [DEBUG] ghostscript commandline built (/usr/bin/ps2pdf -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="/local/home/skelem/PDF/235___Bugs___cups-pdf_package___Ubuntu.pdf" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f /var/spool/cups-pdf/SPOOL/cups2pdf-27959)
Tue Feb 7 12:13:07 2017 [DEBUG] output file unlinked (/local/home/skelem/PDF/235___Bugs___cups-pdf_package___Ubuntu.pdf)
Tue Feb 7 12:13:07 2017 [DEBUG] TMPDIR set for GhostScript (/var/tmp)
Tue Feb 7 12:13:07 2017 [DEBUG] waiting for child to exit
Tue Feb 7 12:13:07 2017 [DEBUG] entering child process
Tue Feb 7 12:13:07 2017 [DEBUG] GID set for current user
Tue Feb 7 12:13:07 2017 [DEBUG] supplementary groups set for current user
Tue Feb 7 12:13:07 2017 [DEBUG] UID set for current user (skelem)
Tue Feb 7 12:13:07 2017 [DEBUG] ghostscript has finished (32256)
Tue Feb 7 12:13:07 2017 [DEBUG] no postprocessing
Tue Feb 7 12:13:07 2017 [DEBUG] spoolfile unlinked (/var/spool/cups-pdf/SPOOL/cups2pdf-27959)
Tue Feb 7 12:13:07 2017 [DEBUG] all memory has been freed

@chelmite: I think it's it is unlikely you are seeing this bug. It's best to open your own ticket. Feel free to subscribe me to it.