Hello Kai-Uwe, nice to hear from you on this mailing list! On May 17 18:07 Kai-Uwe Behrmann wrote (excerpt):

Am 17.05.11, 12:59 +0200 schrieb Johannes Meixner:

...

On the other hand there is the "Common Printing Dialog", see https://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonpr... ... Maintaining a own print dialog per application is pretty hard. I know only of PhotoPrint and Scribus doing this properly. So it makes sense to share code and get features for free into applications.

Yes, this is why I do not understand why there is not much more interest in the Common Printing Dialog. I would expect a strong demand from the desktop projects and from various application projects to have a Common Printing Dialog. If there was a strong demand from various projects to have it, it would be at least much easier for Till Kamppeter to get it funded when there are no volunteers who implement it. Without strong and noticeable interest by various projects I have little hope that there will be a Common Printing Dialog. I am afraid that there is not yet enough suffering which could force the various projects to overcome their lone wolf behaviour. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Hello, On May 18 09:31 Johannes Mueller-Lahn wrote (excerpt):

We run 60 desktops with openSuSE since 7 years. In the past we had some annoying openSuSE bugs, but we could work around

Regarding a workaround for the current issue: What happens when you set up several print queues for the same printer device - each queue with a particular paper tray set as default in the print queue config? When you then select the queue for a particular paper tray from the KDE4 print dialog, does it then print form this tray? Alternatively: When you print from the KDE4 print dialog into a PDF or PostScript file via the "Print to File (PDF)" or "Print to File (Postscript)" entries in the KDE4 print dialog, and then print this file and specify a particular paper tray via the "lp -o ..." command, does it then print form this tray? By the way: Have all those above mentioned issues been really bugs which were introduced by openSUSE - i.e. by faulty packaging or by bad patches which were made by openSUSE? ;-) You got the software from us so that it is of course perfectly right to ask for help or support on our mailing lists and to file bug reports using our Bugzilla (but please don't use Bugzilla as support forum). Nevertheless have in mind that openSUSE mainly distributes software "as is" from the various upstream projects. This means that often the actually right addressee is an upstream project and your particular case is a good example how complicated it could become to identify the root cause of an issue so that an issue could be solved by the actually right upstream project. What I like to say is: Even if you got the software from openSUSE, please do not expect that it is openSUSE which can solve any issue. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On May 16 09:16 Johannes Mueller-Lahn wrote:

http://bugreports.qt.nokia.com/browse/QTBUG-19233

Yes, if printing from other apps works then it confirms that it is not a CUPS problem. If you test with a pure Qt application rather than a KDE application you are likely to find the same result (e.g. Qt Assistant) and confirm it is a Qt bug. It is virtually impossible for it to be a KDE only bug. Unfortunately, Nokia consider Printing to have a status of 'Done' so bugs below level P0 and P1 do not get any attention, and they don't even have a maintainer assigned, so it is highly unlikely the bug will be fixed in Qt4 unless someone goes looking for the bug and provides them a patch. Hopefully with the sale of support services to Digia and the coming of Qt OpenGov with Qt5 we can get a team of maintainers together to work on fixing the all too many bugs. On Tuesday 17 May 2011 11:59:31 Johannes Meixner wrote:

Basically KDE 4 printing is insufficient (polite form).

They decided to trash the whole KDE 3 kdeprint subsytem and now - what a surprise - the KDE 4 printing is insufficient.

Sigh. We do do these things for a reason, not just on a whim, so let me explain this one more time. KDEPrint in KDE3 was basically unmaintained for about 1-2 years so no-one worked on porting it to KDE4. About 2 weeks out from release of 4.0 we realised this was the case and tried to fix it. We soon found that the code was broken when used with KDE4 and was virtually incomprehensible and thus unmaintainable by any new people due to a complete lack of documentation or in-line comments. Even if we had the people with the sklls to fix it and maintain it, 2 weeks was too short a time to do so. Besides which, KDEPrint did not work on OSX or Windows and writing the required backends would have taken months as well even if we could find the people with the required skills. Fortunately Qt did have cross-platform printing support that worked with a near identical api (unsurprisingly as KDEPrint was really just a wrapper around QPrinter), albeit with fewer features, and we were able to quickly switch to using it for the 4.0 release. Over the course of the next year I added many missing features to the dialog, then worked on adding the other missing features upstream in Qt but so far these contributions have not been accepted. It's not that we don't care, or that we enjoy inflicting sub-standard solutions on users, it's simply that in the 3 years since 4.0 not one single other person has stepped forward to help, leaving it to someone completely lacking in the required skills to muddle through, i.e. me when I find time and motivation. If this stuff was easy it would have been done ages ago. Qt for example had to hire in a number of consultants to write parts of their printing code as they didn't have the required skills either. It's not something people work on for the fun of it. On a brighter note, with Qt5 and OpenGov coming I'm are hopeful that our patches will finally make it into Qt.

On the other hand there is the "Common Printing Dialog"

KDE and OpenPrinting have been talking about the CPD for several years now, and only now is it getting near the point where it may be a viable option in the next 12 months. I attended the OpenPrinting summit this year to discuss how to move the CPD forward and get it into the various toolkits. Unfortunately there is a lack of skilled manpower and funding to get this done at OpenPrinting as well. Discussions are ongoing, especially around whether we can get it integrated into Qt as part of Qt5 and OpenGov which is where it would ideally belong, and trying to find more government funding to get it finished. We have our Platform 11 sprint and the Qt Contributors Summit coming up over the next couple of months where printing is going to be a topic of discussion and we can hopefully develop an action plan that resolves the issues. Just don't expect us to abandon using Qt as the core solution, we just don't have the skilled manpower to do so. John. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 18 May 2011 10:17:39 Johannes Meixner wrote:

Was there perhaps a discussion on the OpenPrinting summit this year why it is so terrible to implement printing stuff that nobody likes to contribute for the fun of it?

It was a topic that was discussed, and the general conclusion was that it's just something that you need to pay people to work on. It's yet another reason while I still want to keep printing support upstream in Qt because there is some commercial incentive to at least not break things, even if recently Nokia couldn't be bothered funding bug-fixing due to their mistaken belief no-one wants to print from mobiles. As Qt's focus returns to desktops and tablets hopefully we'll see their interest return.

Is there perhaps something missing or broken by design in the base printing system (e.g. CUPS, Ghostscript, whatever...) or in the base system (e.g. X11, dbus, kernel, whatever...) which makes implementing printing stuff such a nightmare?

There's certainly been a lot of problems in the stack in the past, or rather in the 3 or 4 competing stacks, but that's all over now and we're actually in a very good state and able to produce very high quality results. The fact that Apple purchased Cups to use in OSX says a lot. But most people view printing as in a "good-enough" state. The average FOSS developer doesn't have to support an office full of people printing documents so don't see the problems that need solving. Most FOSS devs are also drawn to the latest cool thing, and we are in the age of the paperless office, so who needs printing right??? And it's just hard to get right at times. Cheers! John. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 19/05/11 08:32, Johannes Mueller-Lahn wrote:

Hi John,

I do understand the problematic. Is there any chance that I can help or contribute to fix the bug for the papertrays? Its no enhancement at all, its just to print to the desired papertrays.

Best regards,

Johannes Müller-Lahn

You never need permission to contribute :) Even if you can at least identify which component the bug is in (i see you've opened bugreports at qt, kde, and opensuse) -- if you could do some testing to determine at which level the bug enters -- I would guess that would be a huge help. At least it would indicate who you need to pressure to get some action. For example does the bug still happen using a Qt-only app (non-KDE)? Does it happen on different distributions? Different printers? Different CUPS versions? If you have the expertise to dive into the code, even better, but it's not necessary. Once you've isolated the problem it's a much easier task for the developers. Until a problem is reproduceable on the developer's machine it's not solvable. It's sad that no-one takes responsibility for printing in open source in general; printing, and PIM, and stuff like that isn't shiny code that new contributors are interested in. But it is absolutely vital for everyday usage of the system! Tejas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thursday 19 May 2011 13:49:58 Ken Schneider - openSUSE wrote:

+ 1 on it being vital. But how do I report my problem? (Duplex tri-fold brochure with many pictures on one side). When I print from openSUSE (11.4) it appears that each copy of the print job is uploaded to the printer and from Nuance on Win7 one copy is uploaded to the printer with an instruction to print x number of copies. The difference in speed is significant as it takes 3-4 minutes to upload the document on openSUSE for each sheet of paper. With Nuance on Win7 3-4 minutes to upload the doc _once_ and then 5-6 seconds for each sheet to print. When printing 200 copies the difference is quite significant.

Interesting. Once Cups has the document I believe it queries the printer driver to see if it supports multiple copies from a single upload and the printer has enough memory for the file. If Cups is uploading the file every time but it works under windows that would suggest to me that the combination of your Cups driver and your printer model and your printer firmware version doesn't work properly so Cups is falling bak to multiple uploads. Check you have the latest versions of everything possible and maybe ask on the support forum/list for your printer drivers or Cups to find out. John. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Hello, On May 19 08:49 Ken Schneider - openSUSE wrote (excerpt):

On 05/19/2011 06:47 AM, Tejas Guruswamy pecked at the keyboard and wrote:

...

It's sad that no-one takes responsibility for printing in open source in general; printing, and PIM, and stuff like that isn't shiny code that new contributors are interested in. But it is absolutely vital for everyday usage of the system!

If printing was absolutely vital every single day for usage of the system, it would be one of the issues with topmost attention. But usually one does not need printing every day. But if one really needs to print a document once in a while, then printing becomes absolutely vital. Furthermore there is a big difference in printing by home users compared to printing in a business environment where printing is absolutely vital every single day for usage of the system. Guess what: In the latter case it works well! (Of course not without any issues but really good.) Guess what the main difference is: High quality rock solid true PostScript printers with any kind of add-ons like duplexer, stapler, puncher,... Once you pay the money for such a device, you get its value. For home users a simple true PostScript printer with sufficient main memory but without special add-ons (perhaps only a duplexer) usually provides a totally new feeling how "printing works". PostScript printers do not need a driver and the manufacturer provides a 100% matching PPD file so that all the zillions of device specific options are fully available to the users, see http://en.opensuse.org/Concepts_printing Want a brochure? Have a big-and-fat high quality rock solid true PostScript printer? Just let it make it for you! Select the right device specific options (the hard work is to find out which of the zillions of device specific options make the brochure as you need it - but once you know them, save them as an instance of the CUPS print queue for later re-use) and let the printer machine produce it.

+ 1 on it being vital. But how do I report my problem?

You already did:

(Duplex tri-fold brochure with many pictures on one side). When I print from openSUSE (11.4) it appears that each copy of the print job is uploaded to the printer and from Nuance on Win7 one copy is uploaded to the printer with an instruction to print x number of copies. The difference in speed is significant as it takes 3-4 minutes to upload the document on openSUSE for each sheet of paper. With Nuance on Win7 3-4 minutes to upload the doc _once_ and then 5-6 seconds for each sheet to print. When printing 200 copies the difference is quite significant.

There is much text but mandatory basic information is missing. Basically: Never ever assume someone knows about your particular environment. In detail: Never ever assume the exact printer model is irrelevant. Even if you are 100% sure that your particular issue can never ever depend on your particular printer model, tell the model nevertheless. Never ever assume it is irrelevant how your particular printer model is connected to the Linux system from where you submit the print job. I.e. what does YaST or whatever setup tool show as connection or more precisely what is the CUPS device URI on the Linux system from where you submit the print job ("lpstat -v")? Never ever assume it is irrelevant which exact driver you use for your particular printer model. I.e. what does YaST or whatever setup tool show as driver or more precisely what is the NickName entry in the PPD in /etc/cups/ppd/<queue_name>.ppd Never ever assume everybody knows about your particular software. I have no idea what "Nuance on Win7" is and I neither want nor do I have the time to find out so that I just skip it. If you have a business support contract with us, you can of course expect that I invest more time to find out what you are talking about but not on a voluntary base ;-) Regardless of the missing information, some general information: I assume the difference is whether CUPS generates N copies (i.e. CUPS makes the printer specific data N times) or whether the printer device makes N copies on its own. To verify this: Set "FileDevice yes" in /etc/cups/cupsd.conf and restart the cupsd. Set up a test queue without a driver: # lpadmin -p testy -v file:/tmp/testy.prn -E Test what CUPS results when CUPS is requested to make copies: # echo -en "One\r\fTwo\r\f" | lp -d testy -n 2 # cat /tmp/testy.prn One Two One Two I think you should inspect the device specific options of your particular printer model (plus driver) i.e. the PPD file of your print queue via # lpoptions -p queue_name -l to find out whether or not your particular printer model (plus driver) can make copies on its own. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, 20 May 2011 11:24:50 -0700 John Andersen <jsamyth@gmail.com> wrote:

On 5/20/2011 1:58 AM, Johannes Meixner wrote:

...

Hello,

On May 19 08:49 Ken Schneider - openSUSE wrote (excerpt):

...

On 05/19/2011 06:47 AM, Tejas Guruswamy pecked at the keyboard and wrote:

...

It's sad that no-one takes responsibility for printing in open source in general; printing, and PIM, and stuff like that isn't shiny code that new contributors are interested in. But it is absolutely vital for everyday usage of the system!

If printing was absolutely vital every single day for usage of the system, it would be one of the issues with topmost attention.

But usually one does not need printing every day.

Speak for yourself Johannes.

I also need it every day. Karl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Hello, I isolated the problem, to being KDE only applications. The printing to desired paper trays from LibreOffice, Firefox and Gimp works perfectly. But as soon as, for example kwrite or gwenview comes into the game, the paper trays are wrong. You can see it, that the printer window is the same in gwenview, kwrite, whatsever. Thats why I posted this to KDE, then they told me that the print dialog comes from QT, so I went to QT bugzilla. I can prove this bug on a fresh installed openSuSE 11.4 machine. There is just one cups version installed (1.4.6). In my opinion, it must be a QT bug, because Gimp and others do work. The situation is like this: You have a HP printer (or maybe another) with 1 manual feeder (Tray 1), 1 built-in feeder 250 sheets (Tray 2) and an additional one with 500 sheets (Tray 3). Everyone is loaded with paper, beside Tray 1, it'll contain labels. The papertrays 2-3 are set to A4 default paper, the Tray 1 is set to any paper, containing different labels. Now the print command (you want to print to A4 Paper, Tray 3) is sent to the Printer (orientating from QT Print), and here comes the problem. He doesn't sent the Tray 3 command correctly to the printer. He just sees there is something to print, and selects Tray 1, because its loaded and can print every size of paper.

For example does the bug still happen using a Qt-only app (non-KDE)?

Don't know which one I could test... Do you have maybe an example?

Does it happen on different distributions?

I don't know. We just run openSuSE 11.2 and 11.4, KDE 4.6. The problem occured with KDE4.6 on openSuSE 11.4.

Different printers?

Yes, different HP printers (We just have HP with add. Paper trays).

CUPS versions?

Didn't try another cups versions yet. I'll try this asap.

If you have the expertise to dive into the code, even better, but it's not necessary. Once you've isolated the problem it's a much easier task for the developers. Until a problem is reproduceable on the developer's machine it's not solvable.

Sadly, I don't have. Otherwise I would have completly rewritten the whole KDE printing system.. ;) Best regards, Johannes Müller-Lahn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org