Ubuntu
cups-pdf package

cups-pdf do not overwrite existing pdf

Bug #134671 reported by Nicklas Larsson
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
cups-pdf (Ubuntu)
Invalid
Wishlist
Unassigned

Bug Description

Version information: Gutsy tribe 5 (2007-08-25)

How to reproduce:

1. Make sure that the CUPS/PDF_file_generator is used for printing.
2. Go to http://www.ubuntu.com (I used Firefox)
3. Print with CUPS/PDF_file_generator.
4. Check the PDF catalog, a file Ubuntu_Home_Page___Ubuntu.pdf is created.
5. Print the page again.
6. Check the PDF catalog, the last print doesn't end up here as a pdf.

What I think is happening:

The problem seems to be that if the title is the same, the same name will be used for file generation. If a file name is already exists in the PDF catalog, the printing fails silently.

A similar problem happens when printing from Evince. However, here the problem is even worse. When printing from Evince, a file named evince-print.pdf is created, and the 2nd document you try to print will use the same name, and therefore fail silently.

How serious I think the bug is:

This bug needs to be fixed before Ubuntu 7.10 is released. The alternative is to remove this particular feature before release. (and, no, I don't want that, it is a really important feature)

Related branches

lp:ubuntu/karmic/cups-pdf
Revision history for this message
Patrice Vetsel (vetsel-patrice) wrote :

Cups-pdf do not fail on creating pdf the second time.
The problem is that it overwrite the first pdf with the second pdf with the same name.
You can see this keeping eyes on your pdf file with nautilus. Pdf is re-creating with same name.
So i change description of this bug

Changed in cups-pdf:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Patrice Vetsel (vetsel-patrice) wrote : Re: [Tribe5] cups-pdf should not overwrite existing pdf

Solution is to modify /etc/cups/cups-pdf.conf
and replace line :
#Label 0
by
Label 1

When it's done, all pdf files generated have an unique name. 'job id'+'pdf name'.pdf

Changed in cups-pdf:
status: Confirmed → In Progress
Revision history for this message
Nicklas Larsson (kilsmo) wrote :

> Cups-pdf do not fail on creating pdf the second time.

Yes, I think it does. Try the following:

1. Create two test files, test1.html and test2.html.

test1.html
=======

<html>
<head>
<title>Test</title>
</head>
<body>
Test 1.
</body>
</html>

test2.html
=======

<html>
<head>
<title>Test</title>
</head>
<body>
Test 2.
</body>
</html>

2. Print test1.html from Firefox.
3. Print test2.html from Firefox.
4. Open test.pdf, and see that the content in it is from test1.html.

Revision history for this message
Nicklas Larsson (kilsmo) wrote :

Tested the suggested workaround, and it worked fine for me.

I hope that the workaround will be included as default in Ubuntu 7.10.

Revision history for this message
Martin-Éric Racine (q-funk) wrote :

Experience shows that enabling job labels detracts from the expected default behavior, which is to have PDF files matching the name of the document being printed. Users actually expect old documents to be replaced by newer versions as well, which is why that feature is not enabled by default. Thus, rejecting this feature request.

Changed in cups-pdf:
status: In Progress → Invalid
Revision history for this message
Patrice Vetsel (vetsel-patrice) wrote :

Martin-Éric : i think that we have to discuss more that problem.

I don't think that adding number of job in the name of pdf is too problematic.

In second time, if we decide to not add job number, it's a problem that cups-pdf do not overwrite pdf already made. It's a source of problem for the user. If he don't take care he can send a pdf older that he think..

Changed in cups-pdf:
status: Invalid → Confirmed
Revision history for this message
Martin-Éric Racine (q-funk) wrote : Re: [Tribe5] cups-pdf do not overwrite existing pdf

It doesn't add the job number; it replaces the document name with a job number, which is why it's not an acceptable default.

Also, as already said, most users WANT newer versions to overwrite older documents. Anyhow, we are already sending output to a folder that acts as a virtual "PDF inbox", from where users are expected to move the file to their preferred location. This is working fine as it is.

Revision history for this message
Patrice Vetsel (vetsel-patrice) wrote :

Launch firefox
go to http://www.ubuntu-fr.org/ubuntu/philosophie
print a pdf
go to ~/PDF/
you can find job_13-Philosophie_-_Ubuntu-fr.pdf (13 for me)

open a picture : ubuntu-lion_2.jpg with eye of gnome (default action for double clik on jpg file)
print to pdf
go to ~/PDF/
you can find job_14-ubuntu-lion_2.pdf

cups-pdf do not replace. It add job number.

Revision history for this message
Patrice Vetsel (vetsel-patrice) wrote :

I'v printed this from thunderbird :
job_16-_Bug_134671__Re___Tribe5__cups-pdf_do_not_overwrite_existing_pdf ;)

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

I think we should use the job names labled with job numbers by default as there are several apps sending all print job with one and the same name (and not with the document name).

Revision history for this message
Onno Benschop (onno-itmaze) wrote :

Patrice Vetsel suggested to change Label 0 to Label 1, which works as expected, it adds the Job number to the file name.

What it doesn't tell you is that the job number is not guaranteed to be unique as far as I know, so there is a possibility of the same job and file name overwriting, which is going to be extremely hard to notice because it won't likely happen that often.

Personally I think that the preference should be:
Overwrite 0 - no, never overwrite an existing file, create a unique name
Overwrite 1 - yes, if a file exists with the same name, overwrite it

The biggest challenge in all these discussions are that it is likely that Server users and Workstation users have different requirements. Likely they'll conflict - for example, a Workstation user has access to a notification method like d-bus, but I'm pretty sure that there is no mechanism for a Server process to notify a user on their workstation - given that the workstation could be running any OS.

From reading reports about this and related issues I can only suggest that the issue is not if the behaviour is buggy or not, rather that each person has a different expected behaviour. As I see it, fixing this bug is one of "Expectation Management", rather than fixing an actual bug - other than the unexpected behaviour I've documented above.

Revision history for this message
Peter Würtz (pwuertz) wrote :

I just learned about the new PDF printing feature in 7.10. When I printed my first PDF from firefox, I just sat there waiting for some kind of confirmation of the printing process... but nothing happens... after a few moments I thought "hey, maybe the PDF has already been saved to the desktop", but nothing there... I checked the cups logfiles for any errors and so on... it took some minutes to accidentally find out that my pdfs have been saved to ~/PDF

What I'm trying to tell is that the pdf printing option requires a standard "save-file as..." dialog. The current solution is misleading and broken. One can see this by reading the discussion about possible workarounds for yet simple and common situations as described above.

Right now, printing to PDF in gutsy is not satisfactory. There must be a way to ask the user what to do and to inform about the result of a printing job. Even without a "Save As..." dialog, a simple "The file has been saved to ~/PDF/xxx.pdf" message would be enough to clear things up. The user will know about the location and the name of the PDF, and he/she will learn about the behavior regarding the replacement of files.

Revision history for this message
Martin-Éric Racine (q-funk) wrote :

CUPS-PDF is not a desktop application, it is a CUPS back-end. This is why there won't ever be any dialog.

Anyhow, both GNOME and KDE already offer options to save as PDF or PostScript. Given this, CUPS-PDF mostly is a server-side gaffer tape to provide PDF ouput to non-desktop applications.

Revision history for this message
Peter Würtz (pwuertz) wrote :

Indeed, GNOME and KDE already offer options to save PDF and PostScript files, but only for applications using the desktop libraries. A cups based PDF printer is a valuable asset for applications like Gimp, Firefox or generic applications independent from a specific desktop.

I know CUPS is not a desktop application, but problems like this have been encountered before. Think about the pin-helper application used by the bluetooth utilities. Although the bluetooth service is not a desktop application, in case of a handshake-event a helper application of choice is started.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Closing. See my comment earlier, some apps give always the same name to the jobs, so PDFs for different purposes will overwrite each other.

Changed in cups-pdf:
status: Confirmed → Invalid
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Sorry, default was no job numbers and I will switch to having job numbers with the next release. I had once manually changed to adding job numbers and forgot that I have done so. When closing the bug I assumed that this was the default. So I am reopening this report and it will get closed with the next package upload.

Changed in cups-pdf:
status: Invalid → In Progress
Till Kamppeter (till-kamppeter)
Changed in cups-pdf:
status: In Progress → Fix Committed
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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

Changed in cups-pdf:
status: Fix Committed → Fix Released
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

I have withdrawn the proposed fix of letting the output file names being preceeded by the print job numbers, as job numbers (and even the word "job") can be confusing to non-technical users. Also files do not get sorted by the names of the documents when they have a prefix, so PDFs of the same document are not standing together in the display of the file manager.

A better solution would be adding date and time (or simply 1, 2, 3, ...) to the end of the file name, or better having a GUI tool to configure the behavior of cups-pdf. This would require a major redesign of cups-pdf by upstream, for which it is too late to include it in Gutsy.

In general it is a much better solution 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 way 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.

Changed in cups-pdf:
importance: Medium → Wishlist
status: Fix Released → Confirmed
Revision history for this message
Richard Elkins (texadactyl) wrote :

Personally, I like what PDFCreator (Sourceforge.net project) does as a Windoze driver, providing the equivalent function.
It computes a name and then it provides a pop-up to allow the user to edit/override the computed name and the chosen folder.

In the future, I would like to see cups-pdf do that or something better.

-Richard

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :
Download full text (4.1 KiB)

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"...

Read more...

Changed in cups-pdf:
status: Confirmed → Fix Released
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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

Changed in cups-pdf:
status: Fix Released → Confirmed
Revision history for this message
Jesse (storyjesse) wrote :

I agree that this issue is a matter of differing opinions on what 'expected' behavior is. It appears to me that the simplest solution is simply to allow the desired behavior to be set through cups-pdf.conf
This appears to have been done but I am running into a problem:
- I want cups-pdf to overwrite a file if it has the same name.
- I have placed (or set, can't remember if it was there originally or not) the overwrite key in cups-pdf.conf

### Key: Overwrite
## Hopefully this will enable overwriting of same filenames.
### Default: ie before I added this jobs were failing silently when the filename already existed.
Overwrite 1

- cups-pdf still does not overwrite files with the same name and I have resorted to deleting/renaming them manually before printing a new one.

Is Overwrite an official supported key?
Does it clash or depend on any other key's that anyone knows of?
cups-pdf used to overwrite (some time ago on a different system - now defunct) but I do not know why it won't do it now.

Any help greatly appreciated
Thanks.

Revision history for this message
Martin-Éric Racine (q-funk) wrote :

I suspect that AppArmor prevents the overwrite from taking place.

Till: why don't we use SELinux instead of AppArmor? SELinux usage with CUPS-PDF is fully documented and it works.

Revision history for this message
Jesse (storyjesse) wrote : Re: [Bug 134671] Re: [Tribe5] cups-pdf do not overwrite existing pdf

Thanks, I'll try that but can you tell me what AppArmour and SELinux
are as I have no idea. If you can give me a quick run down or point me
in the right direction for more info that would be great.

Cheers
Jesse

On 27/12/2007, Martin-Éric Racine <email address hidden> wrote:
> I suspect that AppArmor prevents the overwrite from taking place.
>
> Till: why don't we use SELinux instead of AppArmor? SELinux usage with
> CUPS-PDF is fully documented and it works.
>
> --
> [Tribe5] cups-pdf do not overwrite existing pdf
> https://bugs.launchpad.net/bugs/134671
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
--
Jesse
The Wind Wanderer

Revision history for this message
Rolf Leggewie (r0lf) wrote : Re: [Tribe5] cups-pdf do not overwrite existing pdf

@quoting Martin
> I suspect that AppArmor prevents the overwrite from taking place.

bug 147551

Revision history for this message
mexlinux (mcanedo) wrote :

I have this problem on Hardy Alpha 6.
New PDFs with the same name are not created.

Using the "Label 1" solution works perfect.

The result are files named like: job_number-TITLE.pdf

And that is much better than do not have the new pdf been generated at all.

Revision history for this message
Andrew Francis (andrew-sullust) wrote :

I disagree with statements that this is "expected" behaviour.

In no way did I expect ~/PDF to function as some sort of "inbox" where I would be expected to move files out of the way or risk losing them.

Users have a common and reasonable expectation that on modern computing systems, when actions that would not normally cause data loss could do so (eg save to a file, and it turns out that file already exists), they will be confronted with the problem and offered a choice to go ahead, or cancel.

That this is implemented by a CUPS backend, and that CUPS backends normally have no GUI presence, is an implementation detail of no relevance to the user. If the user sees a "PDF" printing option in their stock install Firefox dialog, and selects it, they should expect reasonable PDF printing behaviour.

Revision history for this message
mexlinux (mcanedo) wrote :

I came with a solution:
When you print to the PDF printer, a Save As dialog pops up, it also has a button to email the file.
See this thread:
http://ubuntuforums.org/showthread.php?p=5346500#post5346500

Revision history for this message
Nanley Chery (nanoman) wrote :

This is more of a bug than a feature request, please fix it! To save resources, I regularly use the PDF printer and leave all the printed PDF's in the ~/PDF folder. When handling my loan information I noticed that many of the printed objects have very similar titles. I believe I might have overwritten a page I printed earlier!

I would be satisfied with just a dialog warning that I am about to overwrite an existing file or with a solution mentioned above, appending a number next to the file's title.

Revision history for this message
TimMadden (timmadden) wrote :

I believe this is a huge bug and I am surprised to see that it has persisted for so long. Just because the document has the same name does not mean that it is a new version of the same document. The typical case is when I purchase something online and would like to print my receipt but do not wish to kill a tree. If I print a second receipt from the same vendor, the HTML document title will remain the same, yet the content is now different in important ways. With the current behavior of CUPS-PDF, I lose the record of the first receipt when I print the second. My expectation as a user is that the system when it sees that the file exists, either a) ask me if I want to replace the existing file with a pop up box or b) increment the file name so that an overwrite does not occur. The job number solution is OK or a save as pop up like cutepdf uses (http://www.cutepdf.com/Products/CutePDF/writer.asp).

Thanks

Revision history for this message
Martin-Éric Racine (q-funk) wrote :

As previously stated, GTK2 and QT -based applications already include the possibility of saving to PDF via their Print dialog, which accomplishes what people in this thread have been expecting: to be able to choose the name under which their PDF export will be saved. Thus, I'm closing this bug.

Changed in cups-pdf (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
TimMadden (timmadden) wrote :

Sorry, I completely disagree. The value of cups-pdf is it works across applications. The most typical use case for me is printing something from Firefox which does not provide the ability to save to pdf itself. Martin's logic for closing this bug is flawed.

Nanley Chery (nanoman)
Changed in cups-pdf (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Martin-Éric Racine (q-funk) wrote :

People, the default settings will not be changed. If you want them set differently, simply edit the configuration file.

Revision history for this message
Tamlin (storyjesse-gmail) wrote : Re: [Bug 134671] Re: cups-pdf do not overwrite existing pdf

I agree,

Unless there is a problem with editing the config file, ie. editing it
doesn't allow you to set the behaviour you want, then I think this bug
can be closed.

I have had cups-pdf overwriting files with the same name, adding a
unique job number to the names, and failing silently when the name
already exists.

If this is a debate about what the default settings should be then I
think it's gone on long enough and people need to either accept the
project maintainer's decision (I'm assuming Martin is one of them) or
create a folk of the project if your that passionate about it.

The only thing I'd suggest is it might be a good idea if anyone has the
time to summarise the information in this bug as it's REALLY useful
when trying to get cups-pdf to work how you want it to.

Well there's my 20c
Jesse

On Tue, 01 Sep 2009 17:27:23 -0000
Martin-Éric Racine <email address hidden> wrote:

> People, the default settings will not be changed. If you want them set
> differently, simply edit the configuration file.
>

--
Mythology explains the world, fairytales teach us how to live in it.

Nanley Chery (nanoman)
Changed in cups-pdf (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Tamlin (storyjesse-gmail) wrote : Fwd: [AU Story List] Fw: Urgent - This is important for Google users (isn't that everyone?)
Download full text (10.2 KiB)

---------- Forwarded message ----------

If you use Google, you may want to read this
Stephen HutcheonFebruary 29, 2012 - 11:39AM

   - Read later
   - Comments 72<http://www.brisbanetimes.com.au/technology/if-you-use-google-you-may-want-to-read-this-20120229-1u1i9.html#comments>

[image: Want to clear your Google data history? (Video Thumbnail)]Click to
play video<http://media.brisbanetimes.com.au/technology/tech-talk/how-to-clear-your-google-history-3082344.html>
How to clear your Google history
Learn how to clear your Google data history with this demonstration by
Tablet editor Stephen Hutcheon.

   - Autoplay *On*Off<http://www.brisbanetimes.com.au/technology/if-you-use-google-you-may-want-to-read-this-20120229-1u1i9.html>
   - Video feedback<http://www.brisbanetimes.com.au/technology/if-you-use-google-you-may-want-to-read-this-20120229-1u1i9.html>
   - Video settings<http://www.brisbanetimes.com.au/technology/if-you-use-google-you-may-want-to-read-this-20120229-1u1i9.html>

   - Opinion: *Australia absent in Google privacy
feud*<http://www.smh.com.au/technology/technology-news/australia-absent-in-google-privacy-feud-20120228-1u1g2.html>

Today is your last chance to adjust your Google privacy settings ahead of a
major change to the way Google collects and collates data about you, its
users.
From March 1, the company will begin to aggregate all the information it
acquires about its users who are logged in to Google services into a
single, unified pool of data.
Advertisement: Story continues below
[image: How your web history page should look after you've clicked
"remove".]
How your web history page should look after you've clicked "remove".
This collectable information is what Columbia Law School professor and
privacy advocate Eben Moglan refers to as the “data dandruff of life”. It
comprises the obvious and the obscure. Details you expect to be logged as
well as inferred data that is created as a result of joining the dots.
In the past, data collected in the course of a web search would be kept
separate from, for instance, your YouTube viewing activity, your Gmail
usage or your Map queries.
From Thursday, that will cease being the case.
And unless you specifically scrub your Google Web History, everything that
has been collected about your past search activities and the sites you
clicked through to, can be scooped up and combined with information gleaned
from usage on other Google-owned sites.
The changes will allow Google to better target ads to users and in doing
so, enable the company to extract a higher price from advertisers. This is
not unusual; all web publishers are attempting to deliver more targeted
advertising. But not all publishers can combine as much information as
Google can.
In tandem with the impending changes, Google has taken the opportunity to
unify some 60 separate privacy policies into one simpler document.
The company has also been up front about the coming changes and for the
past few weeks has posted notices on its websites and emailed its
users *explaining
the changes <http://www.google.com/policies/>*.
However, it’s fair to assume that many users have been oblivious to the new
policies either because they m...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.