Michael Karcher ha scritto:
Am Mittwoch, den 12.11.2008, 16:41 +0100 schrieb Massimo Del Fedele:
The patch solves it adding "-o PageSize=<pagesize>" to lpr command.
Is there something wrong with this one ?
Adding parameters to the lpr command this way is ugly and dangerous. There has to be a better way to make cups use the correct page size.
Staying with LPR code, I could use lpoptions -d <printer> -o media=<media> exec-ing it before starting document, but then the selected media would stay there as default for next print jobs (I guess also outside wine's). Would it be better ?
No you should go into the opposite direction. CUPS should provide you with an PPD file telling you what postscript fragment has to be included into the job to select the right page size. Also the correct DSC comment "%%PaperSize" might help.
Regards, Michael Karcher
The problem is NOT the page size inside postscript file, it's already correct. If you "print to file", the resulting PS file is quite perfect. Problem lies in the backend communicating with cups, which doesn't ask for a page size. Is like sending an A0 postscript file to an A4 printer, without rescaling. The page is cropped to A4 size.
The best way would be, of course, replace ALL LPR code with direct cups calls. It's feasible, but it requires some refactoring of all printing code. For example, what's now exec("|lpr -P myPrinter") which I replaced with exec("|lpr -P myPrinter -o myPaperSize") should become CupsCreateJob(....) CupsStartDocument(....) CupsWriteRequestData(....) CupsFinishDocument(....)
That would require some amount of work and, over all, I'm not sure it could be accepted to go into wine code.
Max