One of the missing features of KDE 4 compared to KDE 3 was the not longer available KPrinter, a tool to print Postscript documents even out of non-KDE programs.
In KDE 3 KPrinter was responsible for printing of KDE applications, but other programs used it as well: if they had no own printing configuration but the possibility to add a generic command (like lp/lpr) they were often configured to print against the KPrinter command. KPrinter took the printed file and provided the the user a modern and flexible graphical user interface dialog to pick the preferred printer, change the printer configuration and so on.
With the transition to KDE 4 KPrinter vanished in favor of the Qt print dialog options, which worked only for Qt/KDE programs. All other programs outside Qt/KDE which relied on KPrinter as a drop-in command line tool were at a loss.
Now Marco Nelles – a co-worker of mine here at credativ – published KPrinter for KDE 4. As the (German) blog post shows the new Kprinter provides what we already know from the KDE 3 times: a drop in replacement for other command line printing tools but with the usability and flexibility of the KDE printing dialog. The two screenshots of the post give you an idea of the new interface. For example, the new KPrinter offers to scale the pages to various sizes and even print posters.
This development is incredibly useful if you have legacy software or software which does not offer for example a cups interface. It also helps in case you need to print Postscript files with your own applications but do not want to hook on to Cups yourself.
As the blog post mentions, the future of the kprinter code, hosted at Github, is open for everyone to participate. It might be worth a thought for example to extend the code to also process PDFs. If you want to track the development of kprinter you also might want to follow kprinter’s kde-apps page.
/home/liquidat 
Wow, nice, thanks for sharing the news
You’re welcome =)
Any reason he isolated himself in github instead of living in kde.org?
I’m not entirely sure, best is to ask himself. I thing it might be that he first wants to be sure that the resonance is positive enough to submit it to KDE.
I like it being hosted on github. Because for me kde.org infrastructure is slow (source tree viewer for example) and github is more usable. Pull requests are awesome!
KDE has internationalization support. Github not.
Yes, pull requests are great but more people benefit from internationalization.
FYI, there is some progress/ideas to adopt the gitlab.com platform on kde.org.
Richard, would be interesting to see how the adoption works out!
Regarding gitlab on kde.org:
https://plus.google.com/+AaronSeigo/posts/Qdhhpzg5tyx
and first repo:
https://git-next.kde.org/kde/sprinter/
Although I respect the decision in some ways, note that kde.org stuff is all free/libre/open. GitHub is proprietary. People just often seem unaware of that fact.
Hej Aaron, actually the people at credativ are very aware of that. We already discussed hosting our own Gitlab for various other projects in the future exactly due to that reason. But we haven’t reached a conclusion yet…
Given that you write that it was one of the “missing features” it also strikes me as odd to host it on the proprietary github platform instead of our kde.org infrastructure. It’s kind of sad to miss all the added benefits from being a kde project, like the translator infrastructure, the exposed visibility by having good contacts to distros, getting press coverage by getting notes on the dot.
I can only urge you to think about it and head over to the community mailinglist to get it into KDE infrastructure again 🙂
I will ask Marco about the reasons – as already mentioned, maybe he was not expecting the response and thought that it might not be worth your trouble 😉
I put it on github during its development process cause that’s where we (credativ) keep our other open source projects, there was no deeper thinking behind it.
Now that it is rather polished and finished, we could/should indeed see whether it can be migrated to KDE infrastructure.
Hej Michael, thanks for the clarification =)
Woo hoo! Thank you! I’d been meaning to write something like that myself for ages, but never got around to it (too many other things to do). I’ll be happy to see this back in KDE, if kdelibs 4 wasn’t frozen, I’d suggest to just merge the code there along with the other custom tabs. I’ll have a think about the best place for things to go once I’ve had a look at the code.
John, Qt/KDE printing maintainer, aka The KPrinter Killer…
Well, he’d first has to switch to LGPLv2.1+. Although he reuses lots of old code he hasn’t written himself, KPrinter4 is under GPLv3+ (legal but weird).
=D
Nice to see that you’re so positive about it.
Nice!!! I really missed this one. Can it also be used for batch printing, like the old KDE3 version?
What do you mean by batch printing?
I mean, is it possible to drag a bunch of files from the file manager into KPrinter for it to print them all automatically?
This is not possible at the moment I believe. We are currently waiting for the KDE repo/project application to be processed, than we will file this as an issue there.
Might be tricky to implement, though.
@Michael: Good work!
@albert, markus, graslin: do you really think that this is the right kind of attitude? If I were the developer I’d just give up on trying to collaborate after reading these comments… I am sure you meant well, but you could have phrased it in a much more inviting way, e.g. “Wow, a nice application. We really like it and would be happy to host it at kde.org? Come and chat with us…”