KDE4 printing: results of IRC meeting

[Thiago Macieira]

Kurt Pfeifle wrote:
>> Though, again, I think that's the wrong place to have them.
>
>At least any *idea* where else to provide that function then?

I've said so more than once:

File -> Export as -> PDF
File -> Export as -> PS
File -> Export as -> PNG
add your own set of exportable formats there, configurable through desktop 
files, etc.

File -> Send to -> Mail recipient (PDF)
File -> Send to -> Fax recipient (PDF)
File -> Send to -> My FTP server (PS)
add your own set of export & save as or export & run.

This is what *I* think would be best.

>> So, yes, those features wouldn't be available for non-KDE
>> applications. I don't think it is KDE's job to fill in other
>> applications' shortcomings.
>
>Again, I beg to disagree. KDE does it at many different places too.

Ok, I agree. But the program that does that doesn't have to be part of the 
printing system.

Even if there's no "PDF printer" in the print dialog -- bear with me -- it 
does not mean you can't save as PDF.

If Okular can do it already and all it needs are some command-line 
options -- or a different executable loading the okularpart -- to open, 
print & close without showing a GUI, it can be done.

>Also, a commandline app that...
>
> ...can start a GUI to configure print options,
>
> ...select the printer,
>
> ...connect to a specific CUPS server,
>
> ...save specific sets of print options as profiles under their
>    own name (like "hi quality foto printing", "b/w draft quality
>    pamphlet mode") for easy re-use,
>
> ...without the need to open an application,
>
> ...and lastly (batch-)print the file(s)

All of that is possible. But it's part of kdebase, not kdelibs.

>But please don't give such an invalid advice like "do it with CUPS
>instead" then, and don't try to sell it as the way forward for
>KDE4Printing.

I agree that it was a bad solution for KDE 4 Printing. But it's not 
invalid.

>> KDE 4 wouldn't be losing the functionality anyways. The ability to
>> export as PDF, PS, send fax or email is still there. It's the non-KDE
>> applications that relied on kprinter to do its job that are losing
>> functionality.
>
>What a stupid argument. (Sorry.)

No, I take it back. There wouldn't be any functionality loss if the 
application I described above exists. I just don't think that application 
has to be part of the printing system. It can be any application that 
understands many file formats and prints.

>> And, like someone else said in this thread, if you want to print a
>> file, you don't want kprinter -- you want a document viewer like
>> Okular.
>
>That "someone" likely didn't speak on behalf of everyone (he surely
>didn't for me), and for every occasion and use-case.
>
>Sometimes I want to print files (multiple files at once), without
>starting up an application, and loading them there first, but I
>still want to have a GUI that lets me configure the print options:
>simply because selecting driver options for a multi-featured printer
>is easier and faster with the kprinter GUI

I still don't see how it wouldn't fit your use-case.

Previous use:
kdeprint file1 file2 file3
select the options in the dialog, hit Print

What I am proposing:
okular --print file1 file2 file3
select the options in the dialog, hit Print

Where's the problem?

>> I was merely comparing to other OSes. And I do think that a "PDF
>> printer" option belongs in the CUPS configuration so that all programs
>> benefit from it, not in the KDE client-side dialog.
>
>Why only for PDF then? Why not any other file conversion too then?

I'm using PDF as an example.

But, come to think of it -- especially after your arguments about CUPS 
having to run as root to save the file where the user wants it to -- I 
have to say that the PDF printer in the CUPS server would be a bad idea. 
At least, worse than have it client-side.

So, to summarise:
*MY* ideal world would be to have all of those "virtual printers" show up 
as different options in the File menu. The print dialog would only have 
real printers.

This is completely untested for usability or even code-feasibility. It's 
just a "wild guess" on my part (I won't even call it an "educated 
guess").

As long as you have an application that lets you select one of those 
options, you don't lose functionality. Call it "ksendto", for instance, 
or "kconvert". No, said application doesn't exist yet. This is the ideal 
world in my view.

Now, all KDE applications that print can export as PDF. So, if the plan I 
outlined above means it will be difficult to get the same, I'll be the 
first to say that PDF and PS filters should be there by default in any 
print dialog, provided at Qt level even. KDE would simply add more 
conversion filters from its own configuration (mail, fax, etc.).

But, back to reality: virtual printers are not possible with Qt 4.3.x's 
QPrintDialog.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070915/9f249270/attachment.sig>