[cups] Printed area offset from paper area

[Helge Blischke]

> Am 03.11.2014 um 00:34 schrieb G.W. Haywood <ged at jubileegroup.co.uk>:
> 
> Hi there,
> 
> Thanks for getting back to me.
> 
> On Sun, 2 Nov 2014, Helge Blischke wrote:
> 
>> (1) describe your configuration, especially how your Windows
>> printers are configured and connected to CUPS.
> 
> I'm afraid I don't really understand the question.  There are dozens
> of printers and dozens of Windows machines and about a dozen servers
> in the domain.  Do you want me to describe the whole thing?  It would
> take me days to write such a document and even if I were allowed to
> publish it (I would not be) it would take you weeks to digest it all,
> if you ever did!  There are very few 'Windows printers', by which I
> mean printers directly connected to Windows machines, and the few of
> them that there are unsurprisingly give no problems printing from the
> Windows machines to which they are connected.  The majority of the
> printers are directly connected to the LAN, they are thus neither
> 'Windows printers' nor 'Linux printers', they are just 'printers'.  I
> can describe one printer for example, and one Windows machine, and how
> that machine prints to that printer via CUPS in case that will help:
> 
> The Windows machine (Windows XP Pro) prints via CUPS using the usual
> menus presented by Windows for printing.  To add the printer is a
> matter of using the menu options 'Start->Printers&faxes->Add printer
> ->network printer ->connect to a printer on the Internet'.  The URL
> given is e.g. "http://192.168.0.241:631/printers/Brother-MFC-7860DW"
> which is the "scheme/IP address:port/.../QueueName" of a Linux box
> CUPS printer queue as you would expect.  The Windows machine can use
> either the generic 'Imagesetter' driver supplied with Windows or the
> driver supplied by Brother.  Either way the print is unsatisfactory.
> The CUPS server can use 'raw' printing, or a generic PPD file, or the
> PPD file supplied by Brother for Linux/CUPS.  All methods produce
> similar unsatisfactory results.  The same printer is visible both as a
> normal Windows network printer and through CUPS.  Printing the exact
> same job (from a Windows accounting application called 'Exchequer') to
> the same printer using Windows printing directly to the printer with
> the Windows driver (installed using the 125Mbyte Brother installer)
> produces perfect results.  Sending that same print job through CUPS is
> guaranteed to trash the print job.  It's as if the printing mechanism
> somehow forgets both the size of the paper and the printable area.
> 
> Unfortunately at the moment I only have confidential printouts which
> I can't show you but I'll try to produce some publishable prints of
> garbage and scan them so that you can see the results together with
> the debug output you request below.
> 
>> (2) switch on debug-logging (cupsctl ?debug-logging), print a test
>> job which exhibits the issue, and post (an URL to) the portion of
>> CUPS?s error_log which refers to that job.
> 
> Debug logging has been turned on for a while :( so that won't be a
> problem, but I won't be able to do it for a day or two as I have some
> commitments early in the week.
> 
> PS: Before you tell me that XP is EOL, the XP machines are firewalled
> so they can't communicate with the Internet.  The particular version
> of accounting software which I've mentioned doesn't run on any later
> version of Windows.  That's another issue which is currently in hand.
> The same problems are present when printing from Windows 7 Pro.
> 
> —

Well, no objections against XP. I did a quick test on Win7 installing a test printer using a generic
PPD (imagesetter, color printer). Looking into these PPDs, i found
that they are PPDs for PostScript language level 1 printers which assume
that media sizes like „letter“, „a4“ etc. are defined as operators in a
dictionary named „statusdict“. This may cause your issues, because
a)	most printers speaking PostScript now are level 2 or even level 3 printers
	and do not implement these „compatibility operators“ any more,
and
b)	the respective CUPS filters, be it „stops“ or „pdftops“, cannot deduce any
	default settings from that.

Moreover, I suspect that your CUPS installation uses the cups-filters package
from open printing.org, which by default convert incoming PostScript jobs
to PDF using a pstopdf filter. Without digging deeply into the source of this (these)
filter(s), I suspect that it (they) use some hard coded defaults if they cannot deduce
the proper page size and image position from within the job and/or the printer’s PPD.

So, the first suggestion I could give you is to replace the M$ generic PPDs by
e.g. Adobe’s ADIST3.PPD or similar.

Let me know about the results.

Helge