I am not a gtk maintainer but if you are using GTKPrintOperation you can set the page size by loading an appropriate default GtkPrintSetting.

This would not work all times. Let's consider a printer that loads two or more paper types (for example, A4, Letter, Legal).

There is no way a default printer setting will cater for this (I want Doc1 to print on Legal, and Doc2 to print on A4).

Being able to change paper size on-the-fly is indeed a capability we should have.

Not having a paper size option in a print dialog is really a severe bug. Paper size is the most important option, in PPD files it is even the only required option. Strange for me is that the new GTK printing dialogs include the options from the PPD file but miss PageSize.

Can someone with appropriate access rights raise the severity/priority of this bug to something like "critical"?

Use the page setup dialog.

Matthias, I agree on the page setup -- if you are running *always* the same page size. But if you need to print different page sizes in an ad hoc manner, it does not make much of a sense to require the user to setup a page -- which means changing the default -- to print one single document that needs a different page size. 

For example, a layout that requires A3 (and the default is A4, and the *majority* of printouts is A4). Or a document that needs US Legal, adn the default is US Letter.

gnomeprint has a page size selection in the print dialog. This was cause for many bug reports since it is not clear how the page size determined in the page setup dialog and that determined in the print dialog interact. 

Would you expect that the whole document is reformatted to match the new page size?  In that case all page numbering would change and so the content of the print dialog may need to change to reflect the changed total number of pages available.

If the document is not reformatted do you expect scaling or trimming?

_If_ the powers that are should choose to add page size selection in the print dialog I hope they also allow that part to be programmatically hidden since for example we would not want that in Gnumeric.

@Andreas: I see no problems in having paper size as a programmatically controlled option. Then it is a question of what a specific product is able to do (or not). But the programmatic control would allow Gnumeric, for example, to keep doing what it does, with no difficult questions needing answer.

I am guessing, right now, that almost all Gnome applications will have problems here (based on your comments), since they all seem to prepare a print image candidate and then ask the user where to print it (without an option of re-prepare the print image). Then, of course, Gnumeric will not be able to handle this, forcing the user to change the default and then print and then change back the default to what it was. This really sounds not sane.

To answer your questions: I expect the whole document to correctly print on the printer that was selected, with the paper size that was selected. If you need to reformat, or scale, this is an application option. I very much doubt trimming would be acceptable, on the other hand. YMMV.

The available paper sizes depend on the printer and must be polled from the printer's PPD (usually through the CUPS API). So the printing paper size can only be selected when a printer is selected and also only in the printing dialog as probably only there there is access to CUPS.

If the paper size in the page setup and in the printing dialog are different, in most applications an aspect-ratio-conserving scale-to-fit would be the best solution. The user should be warned in such a case and get offered scale-to-fit, crop, or cancel.

Till: Have you used the gtk print page setup dialog? THe dialog allows you to set up the page size as printer agnostic in whihc case you have only a few common page sizes available or you can choose the specific printer hand then have all page sizes available given in the ppd file for that printer (or you can choose a custom page size). 

I've filed a similar bug on Launchpad (https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/258794). I encourage you to read it.

In fact, it's even more sever than that I think. The "Page Setup" dialog makes everything go wrong with paper size and is totally anti-ergonomic as it doesn't remember any setting for applications.

Let's consider this case :
- I have a printer dedicated to photo printing (and which can only print on 4x6 paper) ;
- I also have a standard document printer which prints on A4 paper.

I've created one printer queue for each one of them, resulting in having 2 PPD files in /etc/cups/ppd (on Ubuntu). These files contain the correct settings (4x6 paper for the first printer, A4 for the second one).

My LC_PAPER variable is set to "fr_FR", so the default paper size used by gtk-print will be A4.
This is totally OK for OpenOffice.org documents or web pages, but if I want to print a photo using EOG for example, or even F-Spot, selecting the Photo printer in the gtk-print dialog isn't enough since the setting from the "Page Setup" dialog will override it *all the time*.
As a consequence, I have to select the right paper size in the "Page Setup" dialog everytime I want to print a photo, along with the right printer.
This makes me have to go into a menu, click on the menu entry, choose 2 combo boxes options, validate, then click on print, select the right printer and finally have my photo printed!

That's extremely annoying and overkill.

Another problem rises when the application doesn't implement the "Page Dialog" setup (as does f-spot 0.4.3, which is the version available in Ubuntu hardy for instance) : I cannot print any photo on my photo printer, thanks to the gtk-print dialog.

A correct behavior would be, as I described it already in my launchpad bug report, to have the paper size option available in the gtk-print dialog, make it the default (quite logical, since it defines the physical capabilities of the printers, isn't it?) and have only the "Page Setup" override the paper size *optionally*.

Anybody alive? This bug is a fundamental one, considering you want to make GTK/Gimp user-friendly...

Please refrain from comments that don't add any insight.
Venting your frustration in bugzilla only raises the frustration level on the developer side, leading to less development...

I'm sorry, I didn't want to hurt anyone. I don't have any idea of the possible progress on this issue, but what I see is that the behavior I report has already been reported multiple times during the last year, and I havent seen any answer from a developper yet :/

I'm willing to help anyway but I don't really have the time to dive into the GTK+ code base :(

Anyway, I hope someone will pop up with a fix anytime soon :D

*** This bug has been marked as a duplicate of 551409 ***