Thiago Macieira wrote:
> Em Monday 22 October 2007 12:20:00 Kurt Pfeifle escreveu:
>> Thiago Macieira wrote:
>>> kprinter -- as a command-line tool that prints PostScript input and shows
>>> a print dialog
>> You don't seem to know kprinter too well. Yes, kprinter shows the print
>> dialog. But no, it isn't confined to PostScript input...
>>
>>> should be replaced with a full-fledged PostScript reader.
>> ...and therefore, above recommonendation isn't quite spot on.
>>
>> kprinter can send *any* file to the print sub-system. If that is CUPS,
>> sending PDF, any image format (like GIF, TIFF, PNG, JPEG, PPM, PNM, Sun
>> Raster,...) is useful, because CUPS can auto-convert it to whatever the
>> target printer needs.
> 
> Ok, rephrasing:
> 
> it should be replaced with a full-fledged document viewer, like Okular. Can't 
> Okular read GIF, TIFF, PNG, etc. ?
> 
> In any case, CUPS isn't the only backend we support. 

It is a pretty save guess that more than 90% of *nix-based users have
CUPS.

This in turn means we should be very careful with what we change for
them, especially if we remove features.

I'm not at all favoring to *only* support CUPS. However, the KDEPrint
code to support non-CUPS print subsystems was never fully completed
in the first place as far as other *nix based systems are concerned.
And for Win32/64 of course, never existed at all up to now.

> Therefore, we cannot rely 
> on CUPS features, like accepting those formats.

Where there is CUPS underneath, *of course* you should rely on and offer
to use those features! What else?!

> We need an application that 
> understands the file format and converts to the printing system's printing 
> language (no, that does not mean PostScript -- the application may have to 
> read PostScript and output something else).

Maybe my old proposal (that I had directed to gwenview, kphoto, digikam,
krita, .... developers) will be taken up by okular developers: offer a
new, additional, optional, alternative printpath where the printjob files
are sent as "raw" png, tiff, jpeg, .... images (or PDF) to kprinter (or
the future kprinter-alike standalone print dialog, as soon as we get one
back; then let the user configure the print settings there (mainly on
'Image' tab).

>>> In any case, it's not a runtime issue: KDE applications shouldn't be
>>> calling kprinter, they should use the C++ classes. Are there any cases of
>>> KDE applications using this? (These are, by definition, non-GUI
>>> applications and KDE isn't in the business of writing them!)
>> There are cases were *non*-KDE apps, running inside a KDE environment,
>> use kprinter as the print dialog (Mozilla, Netscape, Firefox, Thunder-
>> bird, OpenOffice, StarOffice, Acrobat Reader....).
> 
> That is not a KDE3-vs-KDE4 co-installability issue. 

Right, But it is something to keep in mind whenever "printing" is dis-
cussed.

> You can still use KDE 3's 
> kprinter, since KDE 4 isn't overwriting it.


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