CUPS-PDF folder

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.

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.

> 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?

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.

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.

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.

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.

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.

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.

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.

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?

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.