the print properties (page size, color/grayscale/margins) should be read from
cups-server if cups printer is chosen.
The PPD definition can give information which settings to the above properties a
printer can handle. This should be read via the PPD API.
See also bug 347518 and bug 415171. I'll mark them as dependent on this one, since fixing this one will probably fix those.
From bug 130075 comment #50:
Boris Zbarsky (reviews very slow until May) 2007-10-04 08:33:20 PST
Joseph, printing is basically unowned and has been for years. The only way
things get fixed in it is if someone steps up and fixes them.
So it seems there's litte hope of someone from the opensource community stepping in to take care of this.
The only hope seems to be in the Mozilla Foundation which could sponsor some paid developer time. Any ideas?
I think the best option for Mozilla Foundation would be to employ Roland Mainz (if he's still interested in Mozilla development):
He was one of the most valuable and active Mozilla printing subsystem and XPrint developers until around may 2005, when he apparently migrated to different activities.
The involved projects seem to have stagnated since then.
From bug 130075 comment #51:
Till Kamppeter writes:
This is a problem of the browsers, as they can find out about the unprintable
margins of the printer by means of the CUPS API. The CUPS API gives access to
the complete content of the PPD file and the PPD contains the margin info. So
this bug has to be assigned to both the printing part of the Gecko engine and
the printing part of Konqueror.
The bug is not in CUPS, CUPS has everything to tell the apps how big the
unprintable margins of each configured printer are.
One can get the PPD file for a printer by using the cupsGetPPD() function from CUPS API:
And the needed info can be extracted from this PPD using proper PPD-related functions:
There are lots of working examples of the usage of those functions in open source software: