CUPS-PDF folder

Bug #158406 reported by olli on 2007-10-29
30
This bug affects 5 people
Affects Status Importance Assigned to Milestone
cups-pdf (Ubuntu)
Undecided
Rolf Leggewie

Bug Description

CUPS-PDF saves the printed pdf files by default to a folder created to your home directory. In my opinion, CUPS-PDF should always ask to which folder the created pdf file should be saved to. In addition, the user should be able to choose a name for the created file.

I see this as an issue of productivity. Of course we all have created lots of folders to sort our data. Of course, I wish to save my printed pdf files to certain folders somewhere in my folder tree. In other words, the default folder mentioned above is not the final place of any of my files. I doubt that practically all users wish to move files from the default folder to a specific folder as decided on a case by case method depending on the subject of the printed document.

So, if CUPS-PDF would always ask where to save the pdf file, we would save _lots_ of mouse clicks. I mean, We would not have to manually move the pdf file from one folder to another if we simply could decide where to save the file in the first place.

In addition, CUPS-PDF does not even ask a name for the created file. Therefore, it sometimes takes some time to find the freshly created from the default folder if there are other pdf files too. Therefore, CUPS-PDF should also let the user give a name to the printed document.

Hope that you get the idea :-)

Martin-Éric Racine (q-funk) wrote :

CUPS-PDF is a printer driver. It is not a graphic application or a component of the GNOME, KDE or XFCE desktop. Thus, there will never be such a Save As dialog.

Instead, the output directory and file naming policy is controlled by a global configuration file for all users. One caveat on Ubuntu is that the output directory cannot be changed without first modifying the AppArmor rule for CUPS to allow CUPS-PDF to write to the new location.

Rolf Leggewie (r0lf) wrote :

I agree that from a user perspective, the current situation is unintuitive (to say it cautiosly). I myself have been bitten by this. But the situation is just as Martin describes it. cups-pdf is a back-end. There is no concept of a back-end. cups-pdf was not really intended to be used in GUI environments. AFAIU, there is no intention to fix this in the cups-pdf project.

Changed in cups-pdf:
status: New → Won't Fix
assignee: nobody → r0lf
Rolf Leggewie (r0lf) wrote :

> There is no concept of a back-end.
no concept of a GUI

Apparently the Gnome print dialog used to allow you to specify the output location and that was removed recently.

Maybe this issue is reported at the wrong location. Is there a way to pass this information from such a print dialog to a CUPS driver? Can a CUPS driver signal to the print dialog that it accept a filename for output?

Chris Cheney (ccheney) on 2008-03-27
Changed in cups-pdf:
status: Won't Fix → New
Martin-Éric Racine (q-funk) wrote :

Sorry guys, we've already answered this question MANY times already and no, CUPS-PDF cannot have a dialog, because it's just a printer backend for CUPS.

The dialog you see in GNOME applications comes from GTKPRINT, which offers PDF generation as a standard feature; it has NOTHING to do with CUPS-PDF.

Changed in cups-pdf:
status: New → Invalid

Martin, I understand that CUPS-PDF does not expose any GUI, but my question is: does it provide the necessary information and accept corresponding parameters to/from a different layer that does have a GUI?

In this case the necessary information would be the fact that this driver prints to a file and the default folder or file name. The parameter coming back would be the actual file name to print to.

Martin-Éric Racine (q-funk) wrote :

It doesn't accept parameters either. It's not a command line tool.

Anyhow, AppArmor prevents anyone from changing the output path, even if you edit cups-pdf.conf, on Ubuntu.

If it does not accept parameters then it probably should. Not sure if this is a CUPS-PDF issue or a more general CUPS one. The fact that it is not a command line tool has nothing to do with this IMO.

If AppArmor prevents you changing the path then the whole thing becomes even worse. Is AppArmor installed by default? How are you supposed to edit config files whit AppArmor being active? There must be a way.

I see the tendency to totally disregard this issue, and I think this is a really bad attitude. Yes, maybe the suggested solution is not the right one, maybe the problem is somewhere else and hard to fix, but you should at least try to understand that there is an issue and show some willingness to solve it.

Thomas McKay (tom-mckay1) wrote :

I agree wholeheartedly with Marius, this attitude is unwarranted.

If there is no solution readily presenting itself, some creativity is needed, not sour attitudes.
One dirty solution I can think of is to edit the save-as dialogue to run a secondary GUI after cups-pdf saves the file. The file could be saved in a temporary and intermediate location to be automatically moved afterwards to the location specified by the second GUI.

Is there no way to implement this?

Perhaps a bug should be filed against CUPS for not allowing parameters, especially since it began offering file based print services. I would believe any interaction with files should require the ability for manipulation, be it file name or otherwise.

sbs (sbs-bugs) wrote :

Specifying an output folder for a pdf printer driver is similar to specifying the paper tray or other options for a physical printer driver. Where/how it should be implemented in this case I don't know, but the need itself should be obvious to anyone who has ever printed to a file.

Rolf Leggewie (r0lf) wrote :

Guys, this is easy. Cups-PDF is a backend. Feel free to rewrite something else from scratch that has a GUI. It's just not going to happen in Cups-PDF.

This is not a question of any more "me too", "I think this should be done" or "I vote for this to be implemented" unless you vote by writing code. You are beating a dead horse and thus annoy everyone following this bug.

If you want to see this changed, I guess your best option is to try and write a spec at https://blueprints.launchpad.net/ubuntu

PS: I am not speaking for Cups-PDF officially, I am not really affiliated with it apart from being a user (thanks, guys!). I doubt the official maintainers will tell you anything else but "it ain't gonna happen in cups-pdf", though.

Rolf, I don't think this is really that clear cut.

Did you read my comment from March 27? Any comments on that?

Thanks.

Puneet (puneet-lakhina) wrote :

Hi,

I was also looking for a solution for this issue and what I have reverted to is using the "Print to File" option in the Print dialog with the file type as pdf.

I guess that doesnt allow too much configuration of pdf generation options but its better than everything going into ~/PDF or some other fixed directory with some non selectable file name.

Puneet (puneet-lakhina) wrote :

Hi,

On second thoughts, I looked at the code of cups-pdf and it seems like the filename is built using the title argument passed to it, so if there is some way of inserting a dialog box before after I press print and before actually printing a document, it seems to be just a task of accepting the filename argument in that dialog and passing it as the title argument to cups-pdf.

The code snippet in cups-pdf.c that im basing my above message on is the following:

if (argc<6 || argc>7) {
    (void) fputs("Usage: cups-pdf job-id user title copies options [file]\n", stderr);
    log_event(CPERROR, "call contained illegal number of arguments", NULL);
    return 0;
  }

Any opinions?

Puneet (puneet-lakhina) wrote :

I forgot one thing though, the directory name still depends on the CONF file. So that probably will still allow me to choose a file name, but not really the output directory.

So overall some kind of post print hook that moves the file to the desired location seems like a better option instead of abusing the title argument.

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

Other bug subscribers