--nextPart4535517.NJSF15ZjAG
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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:

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

=46ile -> Send to -> Mail recipient (PDF)
=46ile -> Send to -> Fax recipient (PDF)
=46ile -> 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=
=20
printing system.

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

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

>Also, a commandline app that...
>
>=A0...can start a GUI to configure print options,
>
>=A0...select the printer,
>
>=A0...connect to a specific CUPS server,
>
>=A0...save specific sets of print options as profiles under their
>=A0 =A0 own name (like "hi quality foto printing", "b/w draft quality
>=A0 =A0 pamphlet mode") for easy re-use,
>
>=A0...without the need to open an application,
>
>=A0...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=20
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=20
application I described above exists. I just don't think that application=20
has to be part of the printing system. It can be any application that=20
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=20
having to run as root to save the file where the user wants it to -- I=20
have to say that the PDF printer in the CUPS server would be a bad idea.=20
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=20
as different options in the File menu. The print dialog would only have=20
real printers.

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

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

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

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

=2D-=20
=A0 Thiago Macieira =A0- =A0thiago (AT) macieira.info - thiago (AT) kde.org
=A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:
=A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358

--nextPart4535517.NJSF15ZjAG
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBG65yBM/XwBW70U1gRAhDAAJ9xxbybRe5OQnY6sE7liWikTBTsMQCgrLqV
pg9n7RxD3cUEW5XPTIQ9Xkk=
=wxZo
-----END PGP SIGNATURE-----

--nextPart4535517.NJSF15ZjAG--