Print to file should say "Export as PDF" instead of "Print to File"

This cannot be fixed by modifying the cups-pdf package. cups-pdf does nothing more than providing a print queue which generates PDF files instead of sending the job to an actual printer. As it provides a print queue, you will only have a "print to PDF". Yo get an "export to PDF" (like in OpenOffice.org: "File" -> "Export to PDF ...") the individual applications need to be modified. Application developers have to add the "Export to PDF ..." function which generates a PDF from the current document and lets the user save it with the usual "Save as ..." dialog (as OpenOffice.org does). cups-pdf is an interim solution for the time being until all applications have an "Export to PDF ..." function.

PDF generators will be added to all applications sooner or later anyway as it was agreed on on the Printing Summit in April 2006 in Atlanta that PDF will replace PostScript as standard print job format. So it is no bg deal to add an "Export to PDF ..." function.

The best way to solve this is to add the PDF generating functionality to the desktop libraries (Cairo, GTK, Qt, ...) and to add a common PDF generator dialog which gets linked to the application via Portland/XDG. All this has to come from upstream. It cannot be solved by the Ubuntu packaging.

Thank you for your answer

so is it possible to report this bug "upstream" ?

The wishlist you reported does not concern CUPS-PDF at all.

Please note that CUPS-PDF is not an interim solution to anything. Rather, people have simply found it to be a convenient way to generate PDF documents. It is specifically intended to replace paper printouts with PDF documents and to do so using the familiar CUPS infrastructure. It is not meant to provide a replacement Print dialog or to compensate for any deficiency in desktop environments, since it is completely unrelated to any particular desktop's GUI.

What will instead be done is that all desktop environments (GNOME, KDE, XFCE, etc.) will eventually implement their own Export To PDF option, in their respective GUI library or via a unified interface that is DE-agnostic.

"What will instead be done is that all desktop environments (GNOME, KDE, XFCE, etc.) will eventually implement their own Export To PDF option, in their respective GUI library or via a unified interface that is DE-agnostic."

Shall i fill another bug report about that, then ?
And how ?

That should be a "One Hundred Paper Cuts" task

For me this isn't specially strange. A pdf is a document, in the sense that it is a finished work (no more editing or fiddling is possible), so I think that people can easily understand what printing to pdf means. And actually this exact functionality has become very popular in Windoze systems. There are a few packages that provide a virtual printer that prints to pdf (CutePDF, PDFCreator, etc...).

Having this functionality in CUPS is very nice. As stated before by Martin-Éric, don't confuse this with the options of a particular application.

Please don't point out windows addons as usability exemples.
Addons are not always well integrated into the system because they are addons.

Look at the thing like if you were discovering what a computer is.
Would you honestly say : "hey i'd like to make a pdf with that document, maybe i should look at print options ?"
Don't forget that printing as a definition that people know and that Ubuntu can't change.
As i said, printing is getting a sheet of paper out of the printer, and not getting another electronic file.
http://www.thefreedictionary.com/printing

What antistress is saying makes sense. I don't think this is a "cups" versus an "export to PDF" problem. This is a GUI problem.

As user, i don't care how the pdf-file is generated, whether it is done by dedicated "pdf generator" or a "print queue which generates PDF". As a user, I want to create a pdf-document, that's it. Why can't you implement an "export as pdf" button, which triggers a printing queue for generating a pdf-file? That way the user may find out that the options of generating pdf-files actually exists. Otherwise, the average user may think that this isn't possible.

How about just "Save as PDF" / "Save in PDF Format" .
Since all it does is , save a file in the PDF format!
Also users do know that "Save as" option creates a new file.

mac_v : yes, that's what i had in mind when i've made that report

@mac_v

I think the problem with "Save as PDF" / "Save in PDF Format" is that a PDF generator and a virtual printer go about the process of creating the PDF in two (very) different ways.

One way to improve things may be to say "Virtual Print to PDF".

I assume that "Virtual Print to PDF" suggestion is a joke ?
Can we find something understandable for normal people please ?

@Tim McNamara:
The main factor we need to consider is, the average user doesnt really care which way the action is done, as long as it does what they want...
For this instance , when they want to Save the file in PDF format, labeling this option appropriately, so that it conveys an understandable meaning for the user to choose this menu item quickly is better.
We dont need to bother them with the intricacies!

1) Both GTK2 and QT have implemented built-in Save as PDF support in their printing dialogs, which is what the initial request for this bug really was asking for, thus the goal for this paper cut has already been reached a couple of Ubuntu releases ago.

2) It has nothing to do with CUPS-PDF anyhow, so this is the wrong package to assign it to.

While choosing print from File>Print , the General tab , under the Printer column, it is still "Print to file" . [while OOo.org has a separate option "Export as PDF"]

It should rather be "Export as ..." since the user can choose the extension to save the file as.
And the Column should probably labeled something else too.

So what is the right package?

The right package would be the individual application that we would like to have an "Export to PDF..." (or "Export...") in, such as gedit, eog, etc.

The code is rather simple, from http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf :

op = gtk_print_operation_new ();
// Set up op
gtk_print_operation_set_export_filename (print, "test.pdf");
res = gtk_print_operation_run (print,
               GTK_PRINT_OPERATION_ACTION_EXPORT,
               NULL, NULL);

Then what is the plan ?
Do you plan to modify each application or should it rather be done upstream (maybe via a GNOME Goal ?)

antistress, I'm not sure - after thinking about for some time maybe an "Export ..." menuitem isn't the best either as you then can't make the settings now available in the print dialog (such as scale). What do you think?

As far as an end user is concerned , the export option has nothing to do with print.
So , it is wrongly placed in the "Print..." dialogue , and , less chances of discovering this option.

Ideally , These options should not be hidden away inside "Print..." menu item.
The best solution is to move all the Export options available via the Print dialogue , to Export's own dialogue window.

So we'd end up with:
----
 Export as...
 Print Setup...
 Print Preview
 Print...
----

The "Export as..." should lead to a dialogue window which has options to choose the format of the export and the location [options available at present when user selects Print to file]

Can this split be done in gtk print/CUPS? or which ever package controls the print dialogue... That would fix this in most of the Apps , rather than patching apps individually.

But,there are certain apps which already have the "Export as..." option [OOo.org], so for these apps the above option should not be displayed , and rather let the app display its own

Indeed, current implementation is wrong and has to be fixed.

>> Current implementation reflects the developer's model rather than the user's model <<

User can't know that there is an export functionality since it's hidden in a non-related menu entry
Question is not "do we have to fix this" but "how to fix this"
(unfortunately i have no skill for coding)

A dedicated menu entry is needed like with OOo

Actually the current design implementation in Print dialog box is not good since the beginning.
The good way would have been to make the functionality available to other applications and let them decide if they want/need to use it. I guess that some applications would have implemented the feature and some other not. I also guess that those which would have implemented it would have used a dedicated entry "Export as..." in the File menu.
Not all applications would have need it : some applications are editor some other are viewers ; some applications deal with text, some other with pictures, video or music.
I guess that a text editor or a web browser would have use it whereas a video editor would have not.
Concerning document viewers (evince) or image viewers (EoG) i don't know if they would have use it.

Instead of that, developers took a shortcut in adding the functionality for all applications in the Print dialog box.

I see 2 possibilities (although i don't know if it's technically doable) regarding former comment by mac_v :
A)
1°) Remove all the "print as file" stuff in the Print dialog box
2°) Create a trick to display a dedicated entry "Export as..." in the File menu each time the application has a "Print" entry
3°) Create a setting to allow applications to refuse the "Export as..." menu entry
This approach would be similar to the recent GNOME design decision to drop icons from menus by default : each application can decide to display some icons anyway by using the always-show-icons property of GtkImageMenuItem.

B)
1°) Remove all the "print as file" stuff in the Print dialog box
2°) Create an easy way for GNOME applications to add a dedicated entry "Export as..." in the File menu
(see comment #16)
3°) Fill bug reports against applications that would take benefit from that functionality

What do you think?

antistress, I'd definitely say B. Part because A isn't possible (as far as I know) and it wouldn't make sense in all applications (especially if they use custom print management).
But, maybe we should keep the "Print as file" as a backup function where the application designer didn't think the user would need an Export function but 1 out of 10 000 user once in there life would die to have it (no good example for this ;) ).

So, maybe a copy of the print dialog with the first tab redesigned to only have the export to file option available would make sense? API would be the same except for the last function where you say export () instead of print ().

That sounds reasonable even if GNOME would be better if you remove all the "print as file" current implementation in the Print dialog box.
GNOME would die if each time on thing is modified, the old one is not removed

Besides applications are not going to add the new menu entry if the old implementation is still there : "why should i add another entry in the file menu whereas the functionality already is in Print dialog box ?"

Where exactly is the string that needs to be changed to fix the issue?

Simply renaming "Print to File" into "Export as PDF" is not going to fix that bug.
Since "Export as PDF" has nothing to do with Print in user mental model, it should be shown in Print dialog box but in File menu, Like "Save"

David: gtk+/modules/printbackends/file/gtkprintbackendfile.c line 498:

printer = g_object_new (GTK_TYPE_PRINTER,
     "name", _("Print to File"),
     "backend", backend,
     "is-virtual", TRUE,
     NULL);

Is that what you're looking for?

"Export as PDF" instead of "Print to File" might be a good incremental change but my intuition says people aren't going to look for it in the print dialog. And there is also the problem of how to present the other formats currently in "Print to File" (svg and postscript).

Like antistress says, the best solution would be a menuitem in the File menu. antistress could you please identify the applications that most need this fix?

is it a papercut?

For the record, a “save as PDF” plugin has just been added to Gimp (https://bugzilla.gnome.org/show_bug.cgi?id=382688)

1. From what I can tell Gimp is implementing a custom pdf creator with extra functionality specific to Gimp such as creating multi-page pdfs when multiple images selected.

2. There is nothing stopping applications implementing export to Pdf directly in their menu, and separate bugs should be opened in each application you think should have this.
@antistress You can't just assume developer will not do this without asking them first.

3. This functionally should not just be removed as its useful for applications that have not implemented it in there menu, and for those that have, it allows people to print to postscript and svg.

4. As stated above Print to File allows pdf, ps, and svg file types and therefore can never be renamed to export to pdf, print to pdf etc.

Therefore I think this bug should be marked invalid and bugs created for any package you think should have Export to Pdf directly in the menu.

@Timothy Arceri (t-fridey) : I understand your point but note that the problem remains that "print to a file" doesn't make sense since printing involves a paper sheet. Export or Save is understandable, Print isn't

@antistress

I do see why you think this is a problem. However, your assumption that printing involves a paper sheet is incorrect. This may have been correct 100 years ago but as technology has changed so has the way in which the word is used. One perfect example of this is 3D printing. Anyway english use of print aside let use look at the reason this functionality exists in the print dialog in the first place.

Which is to save the document in a generic form (in order to print it again at another time - or in another place).

Why would you want to do this?

Suppose you create a document using LibreOffice in open document format. Here are some options you have if you print the document to a file:

1. You can later on print the file without needing to open LibreOffice.
2. If you send it to someone with only Word (which is not fully compatable with odf) they can still Print the document without needing LibreOffice.

The fact that PDF's are commonly used also for viewing the documents content is a nice side affect but the main reason for this funtionality is to support printing.

This is why you can't just strip this functionality out of the print dialog like some have suggested, as it is meant to be there to compliment the printing functionality.

If you still don't agree you should report this upstream https://bugzilla.gnome.org/ under GTK maybe they are willing to change it to "Export to File" but ultimately any change should be made here rather than a custom hack to Ubuntu.

I removed the bug watch which was automatically added from comment #31.

Is this reported upstream?