Back again.

Hey, so really long time no blog, and almost as long no code.  Life, as you'll guess has been real busy, between a full-time job, uni, training (my first half-marathon coming up), and amazingly a full-on social life, KDE has struggled to compete for my time.  It's summer holidays now though, so no uni for a while which means time back on KDE.  It helps to have a place of my own now, a really nice apartment on Clapham Common in South London, where I can hack away uninterrupted (on that note, if you're passing through London on KDE-releated business and need a floor to crash on, drop me a line).  My first task is fixing up the Plasma Calendar which doesn't play well with the non-Gregorian calendar systems, and solving a few small bugs in the calendar systems in time for 4.3.

But enough of all that, I know what everyone's asking (or so it at least seems on the mailing lists/forums/bugzilla): what's the current status of Printing in KDE4?  Well, let me be clear here: KDEPrint is dead, not mostly dead, not just resting, but firmly staked through the heart and 6 feet under.  I know there are people out there who would like to see us have our own Print System and Print Dialog again, but they really don't realise the effort involved.  Anyone is more than welcome to have a crack, I’ll even help out with advice and pointers, but good luck as it's a huge and complex area that would take a team of several devs months of concerted effort to even get up to par.  I personally see little point in duplicating all the cross-platform Print Engine and Print Dialog stuff when we can hack on a Qt git branch and push the needed changes upstream for Qt 4.6 which is due out before any new KDEPrint could be ready.  I also see little point in duplicating all the Printer Admin stuff when most distros have now settled on a single config backend in system-config-printer which we can build on and contribute to.  Yes, there's restrictions in dealing with BIC and release schedules and we won’t always get our own way, but it relieves us of the ongoing maintenance burden, and all Qt apps on all platforms or all distros will also benefit.  Besides, in over a year of my tinkering with it no-one has stepped up to help out, so the resources just are not there to support a separate effort.  I don't even really want to be working on it, there's other stuff I find far more fun and fits better with my interests and very limited available time.

(Yes, I could eventually see us doing our own Print Dialog again, especially if the OpenPrinting effort comes together, but it would be built on QPrinter so we need to push the required features into there first).

So we need to focus on how best to achieve our goals by working with upstream, both Qt and system-config-printer.  I will be at Akademy all week working on it, if there's enough interest I'll get a BoF together to discuss a more co-ordinated effort, because relying on just me to get this done is a recipe for disaster (or at least a very long wait).

To start with I’ll post a series of blogs to cover things in more detail, what issues are still outstanding, how I see them being resolved, and what others can do to help:

* Printer Admin - The KCM module for Printer Configuration, and the Print Job Applet.
* Advanced Page Ranges - Adding Current Page, Odd/Even Page Set, and Non-Continuous Page Ranges to Qt
* Advanced CUPS options - Move all the KDE supported CUPS features into the Qt X11 Print Dialog
* Save/Restore Print Settings - Adding save and restore of current state to QPrinter, and direct support for this in the Print Dialog (a la OSX)
* File Printing - Yes, there is a way to hack X11 and probably OSX to do this, it's Windows that's the problem.
* Virtual Printers - Adding Print to Fax, Print to E-mail, Add Printer, etc directly in the Print Dialog printer selection combo box, and do we really want to?
* Page Previews – In-line previews in the Print Dialog, a la OSX.
* Utilities – kprinter and kprintfax.
* Other stuff - Anything else I can think of missing in Qt, e.g. full cross-platform support for apps adding tabs to the dialog, full cross-platform duplex support, fixing the CUPS properties dialog, etc
* The Future - The new OpenPrinting dialog, what has happened to that project???

So lets get the first one out of the way now: Printer Admin.  With Ubuntu and Mandriva both having adopted Red Hat's system-config-printer as their official printer configuration system, and at least Debian, Arch, Slackware and openSuse all packaging it, I think we can safely assume that it has a secure future.  Hey, if it's good enough for Til Kampeter to go with it instead of printerdrake, that's good enough for me.  Jonathon Riddell and the Kubuntu guys added a KCM and job applet in 4.2 and have put quite a bit of work into it for 4.3, so we seem to be well covered there now.  I know there are some complaints that it is very CUPS oriented and possibly doesn't play so well with LPR-only systems, but with every modern distro shipping with CUPS as the default print system, if you're one of the 6 people explicitly choosing not to use CUPS but still expect to use a modern desktop like KDE,  then I don't think it's a big ask that you have to manually configure your own printers.

Next blog, advanced page range selection, the stuff that people seem to be complaining about most (or is that persistance of settings?).

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

system-config-printer in Slackware

Small correction on the status of system-config-printer in Slackware. Currently, there's only pycups in Slackware-current (the development tree for the next version), but not system-config-printer. I don't expect this to change before the next release, but I might be wrong there.Addon-packages from third-party sites are not really helping either, because there would need to be a system-config-printer-kde package as well. KDE4 in Slackware-current only ships with printer-applet.

OK, thanks for that.  I

OK, thanks for that.  I hope this will come in time.

Ink level monitoring?

Is there any possibility we will get ink level monitoring? 

Ink level monitoring?

This is handled by printer-applet which displays notices sent by the printer, including low ink warnings (if the print driver supports it). 

I seem to recall seeing some

I seem to recall seeing some discussion of a CUPS standard way of interactively querying this, but for now I think all we have are the standard CUPS notifications put out by the driver if and when it knows about them.  I believe for 4.3 that the Kububtu guys have added support for the printer-applet to report these through the KDE notification framework.  But don't quote me as I haven't looked at the admin for a long time as it's now in better hands than mine.

virtual printers

[quote]Virtual Printers - Adding Print to Fax, Print to E-mail, Add Printer, etc directly in the Print Dialog printer selection combo box, and do we really want to?[/quote]

I'd say yes please.  I always appreciated these anyway.  I never use fax these days but print as email/pdf file is a useful feature.  Though I admit it might be more intuitively placed elsewhere (e.g. File->send, File->SaveAs or Export) and overloading the print subsystem for these tasks appears confusing to the uninitiated.  As long as the function doesn't go away!  (In the print subsystem it is automatically available to all applications - yay)

Add printer is a usability issue.  It is often when you have a print dialog open that you realise you need to add another printer (especially in a networked setting).  Having to switch context and go searching for the right control to add a new printer at that time is a frustrating experience.  It is similar IMHO to wanting to be able to create a new folder from aFileSave dialog.

Agree with the Add Printer,

Agree with the Add Printer, but I'm still in two minds about the  Print to Fax/Mail/Carrier Pigeon for the very reasons you cite.  Of course, the Virtual Printer infrastructure required to support Add Printer would also support those, so it simply becomes a matter of how KDE would choose to configure the dialog.

What I really miss in Kde4 printing system

The only reason, for me, to keep kpdf (and all kde3.x print system) it's the ability to pass the ps/pdf/whatever to external filters, like psbook, psnup, etc...

Maybe it's a uncommon  usecase, but I do a lot of booklet printing, and with okular (and all kde/qt 4.x print stuff) I simply cannot rearrange the pages as I need.

BTW: here's the bug

You might be interested in

You might be interested in this bug too, which request for KDE to use it's own print dialog, as in KDE 3:

http://bugs.kde.org/show_bug.cgi?id=196303

 

Okular and booklet printing

File based printing can and should be done by okular in the okular codebase; doesn't make a whole lot of sense to ask the same people to write something in kdelibs instead of in okular just for one usecase that is unique to okular.

The okular people know they can do it, but they keep saying someone else should do it for them. *shrug*

easy? not quite

> The okular people know they can do it, but they keep saying someone else should do it for them. *shrug*

You still don't  seem to understand ripping out kdeprint and replacing it with a 'invoke CUPS' lpr on command line' was one of the worst ideas ever, and we were nor are happy about it. Building a printing system is not quite an easy task: you either do a "kinda basic" configuration (like current Okular's), or end up basically rewriting kdeprint or the Qt printing functionalities, and both of them are quite big own modules; there's no intermediate solution.

Also, you don't understand that  we don't have experienced people in printing, and not having all the possible configurations which users report does not help in the job.

You can shrug as you want, but your shrugging won't tell us what to improve, nor how to cope with printers (and their configurations) which we never heard about, and so on.

 

Pino Toscano (Okular maintainer) 

File printing has other uses

File printing has other uses outside Okular.  Try the kprinter utility for example to print any file that CUPS understands, or anyone else wanting higher quality printing than the QPainter canvas can support, or any advanced ps/pdf file manipulation like booklet printing which could be built into kprinter.  It seems pointless to re-render a file onto a canvas just so Qt can re-render it back to a print file again.  And the Okular guys shouldn't have to know how to do this, the print system should provide it.  I wrote the X11 file based printing support in Okular because we had removed a feature vital to them and the KDE desktop.  I've had thoughts of moving that support into kdelibs, and eventually will if Qt desn't accept the proposal, but I'd rather not as we'd effectively be building a whole other print system again and it's not cross-platform.

And it is actually an incrediably simple thing to do, QPrinter already translates the QPainter canvas into a ps/pdf file and sends that to CUPS or LPR to print, all we need is an API to give it the name of a print file instead and Qt can send that file instead.  It would take a Troll all of 1-2 days to implement as an X11 only feature, me rather longer.

Thanks, great blog!

I'm thankful you want to continue working on this and want to do this in coorporation with Qt.

Find me at Akademy if you want hints / tips on how to hack in such functionality!

Thomas Zander

Will do :-)

Will do :-)

OpenPrinting dialog

TIll wants this to be  worked on again as part of summer of code.  I have doubts that students will be experienced enough to complete in the limited time it but we can hope. 

From what I saw at last

From what I saw at last years Akademy presentaion, I think there's a bit of work that would need to be done inside Qt to make the dialog work.  For example the current workflow is: show Dialog, on Accept get page range, generate pages. But to have live preview in the dialog of the pages will require pages to be rendered in advance by the app or with a call-back mechanism for the dialog to request pages be generated. Which also means each app will need re-writing to take full advantage of the dialog.  Designing such a feature in QPrinter is on the to-do list, but I doubt that will be done for Qt 4.6.

Persistent print options

Persistent print options please! Makes total sense to use underlying infra-structure such as CUPS to relieve KDE development effort, but why are the non-persistent print options even different from the CUPS printer options (not honouring duplex mode and not remembering duplex mode etc.).
I must confess I am a little surprised to see printing apparently not attracting much development interest, I could go back to no plasmoids, compositing etc etc., but I need to print, every day, from pretty much every application.....

Print Dialog

What 4.3 is missing is the ability to specify which pages you want printed.
In all previous efforts there has been a text field that allowed you to print a selection of pages like "1,4,6,8-11,15" or any other selection you needed.

Is there any chance of KDE getting the technology of a text field back into the standard dialog?

breitling tourbillion watches

As the business grows, breitling watches has also jumped into an international brand. It is worth mentioning that,breitling replica is the ancestor of today's brand-oriented, in order to protect the quality and brand name will be printed on their products, the history of fashion in the world, is the first one first.breitling watch, replica breitling, fake breitling,breitling tourbillion watches.

One of the main advantages

One of the main advantages to LEED over other certifications is that it begins in the design phase. Before plans are drawn up the owners, architects, builder and key sub contractors like HVAC, plumbing and electrical, meet to discuss the design and ways to make the home more efficient and livable. The synergy created in this type of process produces a home that is very livable, healthy, sustainable, and has less impact on the environment Promotional gifts.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

The content of this field is kept private and will not be shown publicly.