Future of KPrinter

[Kurt Pfeifle]

Alex Merry wrote:

> The reason setting the margins doesn't really make sense is that 
> printers have an area that they can print on (which may be the full 
> page for some printers), and no amount of software settings is going to 
> change that.

OH yes, it can (but only in one direction...)

You (again) forget, that KDEPrint (old or new) does not send its stuff
to a physical printer, but to the underlying print subsystem.

That subsystem *may* be configured to pass the job unfiltered to the
print machine. But in many cases, there will be some filtering going
there.

Example: the pdftops filter in CUPS understands a "-o fitplot=true"
         parameter. It makes the filter auto-scale the PDF page to
         the available ImageableArea of the printer (and auto-rotate,
         in case this leads to a better fitting). Now if you set on
         the commandline a different ImageableArea than in the PPD,
         you get a different scaling. (Of course you will not be
         able to trick the printmachine into using *less* margins than
         it can phyiscally handle -- but you can trick the print
         system to use *more*, and the printer has no problem with
         that).

> I'm not sure what applications are currently setting the margins for - 
> possibly just to change the co-ordinate system.

They are setting margins for... having margins on the printed output.

The margin dialog in KDEPrint3 is useful (and works!) for example when
printing HTML pages from Konqueror. Or Text from Kate. [Or it *could*
be useful when printing images (even when loading them into kprinter
without an application) but that feature was never implemented/enabled
for these file types, because development halted...].

Note, that CUPS understands a commandline options for setting top,
bottom, left and right margins for certain files/mime-types, but KDE
does use the margin setting dialog only towards the application (it
*could* use it to set it towards CUPS as well).

-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany