Massimo Del Fedele ha scritto:
Print jobs are sent to CUPS without the page size, so they're cropped to the default one (usually A4). The patch solves it adding "-o PageSize=<pagesize>" to lpr command.
Ciao
Max
Is there something wrong with this one ?
Max
Massimo Del Fedele max@veneto.com writes:
Massimo Del Fedele ha scritto:
Print jobs are sent to CUPS without the page size, so they're cropped to the default one (usually A4). The patch solves it adding "-o PageSize=<pagesize>" to lpr command.
Ciao
Max
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.
Alexandre Julliard ha scritto:
Massimo Del Fedele max@veneto.com writes:
Massimo Del Fedele ha scritto:
Print jobs are sent to CUPS without the page size, so they're cropped to the default one (usually A4). The patch solves it adding "-o PageSize=<pagesize>" to lpr command.
Ciao
Max
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 ?
Max
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
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
On Wed, Nov 12, 2008 at 12:51 PM, Massimo Del Fedele max@veneto.com wrote:
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.
You should check if cups is present at compile time (which I guess we already do) and then dlopen the cups libraries if present (again I assume we already do this) and yes use the cups api if possible rather than directly invoking lpr.
Steven Edwards ha scritto:
On Wed, Nov 12, 2008 at 12:51 PM, Massimo Del Fedele max@veneto.com wrote:
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.
You should check if cups is present at compile time (which I guess we already do) and then dlopen the cups libraries if present (again I assume we already do this) and yes use the cups api if possible rather than directly invoking lpr.
So, replace ALL existing execs to lpr with direct cups calls ? Mixing them for a single print job is not possible, AFAIK.
Max
Massimo Del Fedele wrote:
Steven Edwards ha scritto:
On Wed, Nov 12, 2008 at 12:51 PM, Massimo Del Fedele max@veneto.com wrote:
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.
You should check if cups is present at compile time (which I guess we already do) and then dlopen the cups libraries if present (again I assume we already do this) and yes use the cups api if possible rather than directly invoking lpr.
So, replace ALL existing execs to lpr with direct cups calls ? Mixing them for a single print job is not possible, AFAIK.
The correct way is to fix winspool and friends to use schedule_cups() which in turn uses cupsPrintFile(). Detlef could probably comment on how far away we are from using this.
Huw.
Huw Davies ha scritto:
The correct way is to fix winspool and friends to use schedule_cups() which in turn uses cupsPrintFile(). Detlef could probably comment on how far away we are from using this.
Huw.
Well, so I guess I'll keep the patch in my tree to make Autocad happier and wait for better times :-) Thanx all for answers !
Max
-
Alexandre Julliard -
Huw Davies -
Massimo Del Fedele -
Michael Karcher -
Steven Edwards