Re: OpenPrinting Summit - Print Dialog and Colour Management
Am Mittwoch 16 März 2011 schrieb John Layt: [1] https://www.linuxfoundation.org/collaborate/workgroups/openprinting/openpr inting- summit-san-francisco-2011 [2] http://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonp rintingdialog Hi, I'm very happy to read that there is work to improve the current printing situation. KDE 3 had a wonderful printing system. It was far from perfect but usable. Unfortunately KDE 4 replaced it with a print dialog that is barely usable. I've looked at the Requirements page and started the dialog application. I have some comments and questions: - My biggest wish for a printing dialog is that the preview exactly matches the output. All current print dialogs that I know on linux have the problem that the output is not really predictible if one goes away from the default: printing A4 portrait to an A4 portrait printer. Often one has to try several options to get the desired result or one finally fails. Options that often cause problems are landscape/portrait the size of the media, or multiple pages printing. - The choice of the output paper size and tray should be more prominent. I have one printer where I can find the paper size only in the General tab at the last position of 50 options. - There should be visual feedback how the document applies to the paper. What happens if I print an A4 document and select an A5 paper? How can I specify that the document has to be shrunk to fit? - Is it possible let the dialog shrink the document by a given percentage and to align the document on the paper to have more empty space on the left for a hole-puncher - Is it possible to print an A5 document on A4 paper centered with optional with crop marks at the border? - Will the applications be able to change the document and send a new preview as soon as the options change? - For duplex printing I would like to see a left and right page or top and down page side by side in the preview. - If one prints more than one document page on a paper sheet it should be possible to specify the horizontal and vertical gaps. - The preview should optionally show the media borders, the printable area borders and the document borders on the media. - One advanced option I would like to see: I do not know of any duplex printer that is able to print the front and back page such that for example crop marks exactly match. Often there is an offset one has to apply. It would be nice if one could do this independently for the front and back page in the dialog. Christoph Bartoschek
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Sun, Mar 20, 2011 at 10:10 AM, Christoph Bartoschek bartosc...@gmx.de wrote: Am Mittwoch 16 März 2011 schrieb John Layt: [1] https://www.linuxfoundation.org/collaborate/workgroups/openprinting/openpr inting- summit-san-francisco-2011 [2] http://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonp rintingdialog Hi, I'm very happy to read that there is work to improve the current printing situation. KDE 3 had a wonderful printing system. It was far from perfect but usable. Unfortunately KDE 4 replaced it with a print dialog that is barely usable. I've looked at the Requirements page and started the dialog application. I have some comments and questions: - My biggest wish for a printing dialog is that the preview exactly matches the output. All current print dialogs that I know on linux have the problem that the output is not really predictible if one goes away from the default: printing A4 portrait to an A4 portrait printer. Often one has to try several options to get the desired result or one finally fails. Options that often cause problems are landscape/portrait the size of the media, or multiple pages printing. - The choice of the output paper size and tray should be more prominent. I have one printer where I can find the paper size only in the General tab at the last position of 50 options. - There should be visual feedback how the document applies to the paper. What happens if I print an A4 document and select an A5 paper? How can I specify that the document has to be shrunk to fit? - Is it possible let the dialog shrink the document by a given percentage and to align the document on the paper to have more empty space on the left for a hole-puncher - Is it possible to print an A5 document on A4 paper centered with optional with crop marks at the border? - Will the applications be able to change the document and send a new preview as soon as the options change? - For duplex printing I would like to see a left and right page or top and down page side by side in the preview. - If one prints more than one document page on a paper sheet it should be possible to specify the horizontal and vertical gaps. - The preview should optionally show the media borders, the printable area borders and the document borders on the media. - One advanced option I would like to see: I do not know of any duplex printer that is able to print the front and back page such that for example crop marks exactly match. Often there is an offset one has to apply. It would be nice if one could do this independently for the front and back page in the dialog. Christoph Bartoschek In general it would be nice to see screenshots of the available options and how they are laid out. -Todd
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am Sonntag 20 März 2011 schrieb todd rme: On Sun, Mar 20, 2011 at 10:10 AM, Christoph Bartoschek bartosc...@gmx.de wrote: Am Mittwoch 16 März 2011 schrieb John Layt: [1] https://www.linuxfoundation.org/collaborate/workgroups/openprinting/ope npr inting- summit-san-francisco-2011 [2] http://www.linuxfoundation.org/collaborate/workgroups/openprinting/comm onp rintingdialog Hi, I'm very happy to read that there is work to improve the current printing situation. KDE 3 had a wonderful printing system. It was far from perfect but usable. Unfortunately KDE 4 replaced it with a print dialog that is barely usable. I've looked at the Requirements page and started the dialog application. I have some comments and questions: - My biggest wish for a printing dialog is that the preview exactly matches the output. All current print dialogs that I know on linux have the problem that the output is not really predictible if one goes away from the default: printing A4 portrait to an A4 portrait printer. Often one has to try several options to get the desired result or one finally fails. Options that often cause problems are landscape/portrait the size of the media, or multiple pages printing. - The choice of the output paper size and tray should be more prominent. I have one printer where I can find the paper size only in the General tab at the last position of 50 options. - There should be visual feedback how the document applies to the paper. What happens if I print an A4 document and select an A5 paper? How can I specify that the document has to be shrunk to fit? - Is it possible let the dialog shrink the document by a given percentage and to align the document on the paper to have more empty space on the left for a hole-puncher - Is it possible to print an A5 document on A4 paper centered with optional with crop marks at the border? - Will the applications be able to change the document and send a new preview as soon as the options change? - For duplex printing I would like to see a left and right page or top and down page side by side in the preview. - If one prints more than one document page on a paper sheet it should be possible to specify the horizontal and vertical gaps. - The preview should optionally show the media borders, the printable area borders and the document borders on the media. - One advanced option I would like to see: I do not know of any duplex printer that is able to print the front and back page such that for example crop marks exactly match. Often there is an offset one has to apply. It would be nice if one could do this independently for the front and back page in the dialog. Christoph Bartoschek In general it would be nice to see screenshots of the available options and how they are laid out. Hi, do you refer to the dialog I see for one of our printers? Which options do you want to see? The General tab? By the way, is there any reason to prevent resizing of the dialog? I've disabled this and made 3 screenshots showing the general dialog. http://www.pontohonk.de/screenshots/cpd-1.png http://www.pontohonk.de/screenshots/cpd-2.png http://www.pontohonk.de/screenshots/cpd-3.png Christoph
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am Sonntag 20 März 2011 schrieb Christoph Bartoschek: I've disabled this and made 3 screenshots showing the general dialog. http://www.pontohonk.de/screenshots/cpd-1.png http://www.pontohonk.de/screenshots/cpd-2.png http://www.pontohonk.de/screenshots/cpd-3.png The screenshots show another problem of the dialog. The pdf page size is 128mmx96mm. The default page size of the printer is A4. The preview gives no idea how the document will look on the sheet paper. Christoph
Re: OpenPrinting Summit - Print Dialog and Colour Management
Hi, Some very good points, some definately belong in the dialog, others belong in CUPS itself, but I'll take them all with me as everyone will be at the summit. - My biggest wish for a printing dialog is that the preview exactly matches the output. All current print dialogs that I know on linux have the problem that the output is not really predictible if one goes away from the default: printing A4 portrait to an A4 portrait printer. This is actually a very hard thing to do, basically it would involve asking the print system (in our case CUPS) to process the print job right up to the point of sending it to the printer, then to give us back the processed job to use for the preview which would be close, but there's always a conversion process from the job format (was ps, soon to be pdf) into the printer format (e.g. PCL) as there's very few printers that speak ps or pdf natively. So there's always a chance something will still not look right. All this back- and-forth of course adds overhead and slows the process down. I know there's a wish for this in the CUPS bugzilla. At the moment the CPD uses poppler to render the pdf print file as the preview, and then does manipulations on that pdf to simulate what CUPS would do. I assume the filters it applies to the preview pdf are the same ones used in CUPS so it should be fairly close. - The choice of the output paper size and tray should be more prominent. I have one printer where I can find the paper size only in the General tab at the last position of 50 options. The design of the CPD is that all the options will appear in the one area, no more tabs or separate Properties dialog. To control what options appear at any one time there will be a number of filters you can apply and even a search box. You'll also be able to save groups of presets. The default should be the most commonly used options. It's the polish on this stuff that the dialog is currently lacking and is planned for this years GSoC. It will be interesting to see if this works as well in practice as the usability engineers designed it to. - There should be visual feedback how the document applies to the paper. What happens if I print an A4 document and select an A5 paper? How can I specify that the document has to be shrunk to fit? - For duplex printing I would like to see a left and right page or top and down page side by side in the preview. - The preview should optionally show the media borders, the printable area borders and the document borders on the media. These should all be part of the dialog preview, I'll see if it's in the design or not, it could be one of the unimplemented things. - Is it possible let the dialog shrink the document by a given percentage and to align the document on the paper to have more empty space on the left for a hole-puncher This is usually best achieved using a word processor and setting different margins for odd/even pages, but not every app can do that, so it sounds like a good idea for CUPS to implement. CUPS can certainly apply the shrink, and it can apply the paper margins, but I don't think it can currently vary the margins based on page being odd/even. - Is it possible to print an A5 document on A4 paper centered with optional with crop marks at the border? I've think I've seen Adobe Acrobat do that on Windows? It would be a nice CUPS option, but something the dialog could generate too with a filter. - Will the applications be able to change the document and send a new preview as soon as the options change? Yes, that's part of the protocol, as soon as any option that affects the document layout changes (as opposed to affecting the printed page layout), then the dialog tells the app and requests a new preview. It will be interesting to see what performance lag there is as a result. - If one prints more than one document page on a paper sheet it should be possible to specify the horizontal and vertical gaps. That's definately a new CUPS setting, as it's CUPS that processes the n-up stuff. - One advanced option I would like to see: I do not know of any duplex printer that is able to print the front and back page such that for example crop marks exactly match. Often there is an offset one has to apply. It would be nice if one could do this independently for the front and back page in the dialog. Oooo, tricky. Again probably a CUPS thing? I'll ask anyway. It's good to know we have some advanced printer users about, I have very limited needs and resources myself so there's stuff I just won'think of. Cheers! John.
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Sunday 20 Mar 2011 16:50:22 todd rme wrote: In general it would be nice to see screenshots of the available options and how they are laid out. -Todd I'd post some but for two problems. 1) It segfaults on my machine right now, some Qt issue 2) The ui interaction is really not close to being finished. At the moment it's mostly the backend and basic dialog that's done, finishing the dialog is this years GSoC project which is why it's the perfect time for us to jump in and influence things. The interaction has actually been designed by professional usability designers and tested in usability labs, so it should turn out good if we can get the same results in code. Cheers! John.
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Sunday 20 Mar 2011 17:48:09 Christoph Bartoschek wrote: Hi, do you refer to the dialog I see for one of our printers? Which options do you want to see? The General tab? By the way, is there any reason to prevent resizing of the dialog? I've disabled this and made 3 screenshots showing the general dialog. http://www.pontohonk.de/screenshots/cpd-1.png http://www.pontohonk.de/screenshots/cpd-2.png http://www.pontohonk.de/screenshots/cpd-3.png Christoph Wow, thats some set of printer options :-) Definately too long. As I've said earlier, the dialog still needs polishing, and the options filtering looks to be one of those things needing work. Cases like this will be a good test of the usability design. I think the big problem is people will need to unlearn that those are tabs with fixed groups of settings, but rather filters that can be mixed and matched to produce dynamic results. John.
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Sun, Mar 20, 2011 at 4:02 PM, John Layt johnl...@googlemail.com wrote: On Sunday 20 Mar 2011 17:48:09 Christoph Bartoschek wrote: Hi, do you refer to the dialog I see for one of our printers? Which options do you want to see? The General tab? By the way, is there any reason to prevent resizing of the dialog? I've disabled this and made 3 screenshots showing the general dialog. http://www.pontohonk.de/screenshots/cpd-1.png http://www.pontohonk.de/screenshots/cpd-2.png http://www.pontohonk.de/screenshots/cpd-3.png Christoph Wow, thats some set of printer options :-) Definately too long. As I've said earlier, the dialog still needs polishing, and the options filtering looks to be one of those things needing work. Cases like this will be a good test of the usability design. I think the big problem is people will need to unlearn that those are tabs with fixed groups of settings, but rather filters that can be mixed and matched to produce dynamic results. John. Just out of curiosity, what widget style is being used for the screenshots? -Todd
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am Sonntag 20 März 2011 schrieb John Layt: Hi, Some very good points, some definately belong in the dialog, others belong in CUPS itself, but I'll take them all with me as everyone will be at the summit. For me as user it does not matter where it is implemented. However I think this all should be controlled by the print dialog. I do not want to have some options in the cups configuration and some options in the print dialog. There will definitively be conflicts between the options and users will be confused. I would like to compare it with the mess one has with volume control. There are about 5 levels on which I can control the volume on my system. This are 4 too much. For printers a similar issue is the portrait/landscape mode. This can sometimes be specified in the application, the print dialog and the cups system. It never works as expected. - My biggest wish for a printing dialog is that the preview exactly matches the output. All current print dialogs that I know on linux have the problem that the output is not really predictible if one goes away from the default: printing A4 portrait to an A4 portrait printer. This is actually a very hard thing to do, basically it would involve asking the print system (in our case CUPS) to process the print job right up to the point of sending it to the printer, then to give us back the processed job to use for the preview which would be close, but there's always a conversion process from the job format (was ps, soon to be pdf) into the printer format (e.g. PCL) as there's very few printers that speak ps or pdf natively. So there's always a chance something will still not look right. All this back- and-forth of course adds overhead and slows the process down. I know there's a wish for this in the CUPS bugzilla. At the moment the CPD uses poppler to render the pdf print file as the preview, and then does manipulations on that pdf to simulate what CUPS would do. I assume the filters it applies to the preview pdf are the same ones used in CUPS so it should be fairly close. If one only uses poppler to simulate the processing of CUPS then the dialog is a failure. There will definitively be differences which lead to confusion. In my opinion CUPS should not do any processing but just convert a PDF to the printer`s language and send it to the printer. The print dialog can then apply all necessary filters to get the desired output. This is the only way to ensure that the output is as expected. - The choice of the output paper size and tray should be more prominent. I have one printer where I can find the paper size only in the General tab at the last position of 50 options. The design of the CPD is that all the options will appear in the one area, no more tabs or separate Properties dialog. To control what options appear at any one time there will be a number of filters you can apply and even a search box. You'll also be able to save groups of presets. The default should be the most commonly used options. It's the polish on this stuff that the dialog is currently lacking and is planned for this years GSoC. It will be interesting to see if this works as well in practice as the usability engineers designed it to. - There should be visual feedback how the document applies to the paper. What happens if I print an A4 document and select an A5 paper? How can I specify that the document has to be shrunk to fit? - For duplex printing I would like to see a left and right page or top and down page side by side in the preview. - The preview should optionally show the media borders, the printable area borders and the document borders on the media. These should all be part of the dialog preview, I'll see if it's in the design or not, it could be one of the unimplemented things. - Is it possible let the dialog shrink the document by a given percentage and to align the document on the paper to have more empty space on the left for a hole-puncher This is usually best achieved using a word processor and setting different margins for odd/even pages, but not every app can do that, so it sounds like a good idea for CUPS to implement. CUPS can certainly apply the shrink, and it can apply the paper margins, but I don't think it can currently vary the margins based on page being odd/even. I have the problem when I am printing scientific papers. Printing documents that are designed for letter on A4 printers results in very small margins. - Is it possible to print an A5 document on A4 paper centered with optional with crop marks at the border? I've think I've seen Adobe Acrobat do that on Windows? It would be a nice CUPS option, but something the dialog could generate too with a filter. - Will the applications be able to change the document and send a new preview as soon as the options change? Yes, that's part of the protocol, as soon as any option that
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Sun, Mar 20, 2011 at 5:41 PM, Christoph Bartoschek bartosc...@gmx.de wrote: Am Sonntag 20 März 2011 schrieb todd rme: Just out of curiosity, what widget style is being used for the screenshots? This should be oxygen from KDE 4.4 Is it a problem that the dialog doesn't look like a native dialog? It doesn't really seem to match with anything else in KDE. -Todd
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Thursday 17 March 2011 Mar, Christoph Feck wrote: Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. Kai-Uwe Behrmann (maintainer of KDE color management applications) can help you here. Grab him on http://www.oyranos.org/ and make sure he attends the meeting ;) Well... Kai-Uwe and Richard Hughes have had huge discussions on colord on the openicc mailing list (http://lists.freedesktop.org/mailman/listinfo/openicc) -- too huge for me to follow them. This list might be a good starting place for more info. For what I got out of it, colord seems to be, like so many generic libraries be focussed on gnome/gtk-first, while oyranos (Kai-Uwe's system) is burdened by using a config system that nobody packages. But that impression might be outdated and is certainly over-simplified. -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am 17.03.11, 00:27 +0100 schrieb Christoph Feck: On Wednesday 16 March 2011 18:44:31 John Layt wrote: Hi, I'll be attending the OpenPrinting Summit [1] to discuss how to complete the Common Printing Dialog [2] and integrate it into KDE and Qt. I'm looking for any feedback people may have about the CPD, and any questions you want me to ask while I'm there. Many thanks, John, for never giving up with improved printing in KDE! There a two main issues I see with the current approach of the CPD, and if possible, you could bring them up in the discussion. First, regarding the common part of the printing dialog, I hope that using a common denominator of features offered in all operating systems does not reduce the feature set again; we already went through it. (I guess you know the existing bug reports. It boils down to the major feature loss that we got when killing KDE 3.x printing system.) The new printing dialog should not be shy on options, such as pamphlet printing, customizable filters, and (most importantly) application specific options with the ability to allow saving settings in global or application specific profiles. The second concern is about the D-Bus API. I hope that it will still be possible to get a fast in-application preview with it when using the native API. For example, I love how the current Qt printing preview dialog just copies image pointers in the QtPrinter painting engine, so that the preview renders literally the same images as the application has in memory, without copying the actual data. The Qt printing preview is also very fast in scrolling and zooming, I doubt it would be possible with a program that effectively just tries to parse PostScript or PDF printer files just to generate the preview. Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. Kai-Uwe Behrmann (maintainer of KDE color management applications) can help you here. Grab him on http://www.oyranos.org/ and make sure he attends the meeting ;) It would be really cool to have joined you to talk about colour management with KDE. However I am very likely to be swamped with work during this time. With the help of OpenICC[1] some work has been done inside the Oyranos project about printing. The Kolor Manager configuration panel[2] shows some of these. It would be cool for CPD to deploy Oyranos device ICC profile configuration to create a good user experience. I am about preparing some schematic diagrams, which can give some condensed input from the latest OpenICC discussions around linux colour managed printing. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org [1] http://www.freedesktop.org/wiki/OpenIcc [2] http://www.oyranos.org:443/wiki/index.php?title=Kolor-manager
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am 17.03.11, 07:29 +0100 schrieb Boudewijn Rempt: On Thursday 17 March 2011 Mar, Christoph Feck wrote: Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. Kai-Uwe Behrmann (maintainer of KDE color management applications) can help you here. Grab him on http://www.oyranos.org/ and make sure he attends the meeting ;) Well... Kai-Uwe and Richard Hughes have had huge discussions on colord on the openicc mailing list (http://lists.freedesktop.org/mailman/listinfo/openicc) -- too huge for me to follow them. This list might be a good starting place for more info. For what I got out of it, colord seems to be, like so many generic libraries be focussed on gnome/gtk-first, while oyranos (Kai-Uwe's system) is burdened by using a config system that nobody packages. But that impression might be outdated and is certainly over-simplified. Agreed, the discussion threads are very long. But we are about to extract important ideas[1][2] and turn them into proposals[3]. Oyranos ships with the needed configuration code inside its source tree since the last release at begin of this year. The library comes with a CUPS module for printing, and further SANE (which needs patches), Xorg, Quarz monitor and CameraRAW modules. What would be cool to have are a Quarz module for printing and make the library fit for Windows' WCS. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org [1] http://www.freedesktop.org/wiki/OpenIcc#LINUXcolormanagementaproposalforimplementation [2] http://www.oyranos.org:443/wiki/index.php?title=Device_Settings#Printing [3] http://www.freedesktop.org/wiki/OpenIcc#PPDcolouring
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Thursday 17 March 2011 Mar, Kai-Uwe Behrmann wrote: Am 17.03.11, 07:29 +0100 schrieb Boudewijn Rempt: On Thursday 17 March 2011 Mar, Christoph Feck wrote: Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. Kai-Uwe Behrmann (maintainer of KDE color management applications) can help you here. Grab him on http://www.oyranos.org/ and make sure he attends the meeting ;) Well... Kai-Uwe and Richard Hughes have had huge discussions on colord on the openicc mailing list (http://lists.freedesktop.org/mailman/listinfo/openicc) -- too huge for me to follow them. This list might be a good starting place for more info. For what I got out of it, colord seems to be, like so many generic libraries be focussed on gnome/gtk-first, while oyranos (Kai-Uwe's system) is burdened by using a config system that nobody packages. But that impression might be outdated and is certainly over-simplified. Agreed, the discussion threads are very long. But we are about to extract important ideas[1][2] and turn them into proposals[3]. That's so cool! Oyranos ships with the needed configuration code inside its source tree since the last release at begin of this year. Great! The library comes with a CUPS module for printing, and further SANE (which needs patches), Xorg, Quarz monitor and CameraRAW modules. What would be cool to have are a Quarz module for printing and make the library fit for Windows' WCS. -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Wednesday 16 Mar 2011 23:27:04 Christoph Feck wrote: Many thanks, John, for never giving up with improved printing in KDE! Thanks, I may not be the most effective hacker around, but I am persistent :-) Just to be clear, I'm not saying we will go with the CPD, that's not a decision I can make, but I want to make sure we've fully explored the option as this is one Linux infrastructure project that is wanting our involvement and actively working to ensure we get equal treatment. First, regarding the common part of the printing dialog, I hope that using a common denominator of features offered in all operating systems does not reduce the feature set again; we already went through it. (I guess you know the existing bug reports. It boils down to the major feature loss that we got when killing KDE 3.x printing system.) Ah, actually the CPD isn't cross-platform, it's cross-desktop meaning the same dialog design and back-end code used in both Gtk and Qt apps. If you're running a KDE app on a Gnome desktop you'll get the Gnome dialog pop up for consistency with the rest of your Gnome apps, but using the same common backend. Personally, I'm not sure it is consistent to have a KDE app pop up a Gnome dialog, but we'll see. It's all CUPS based and supports the full set of CUPS features, and will also magically support all the extra settings that the printer has via an enhanced set of PPD definition files. In fact a big driver behind the CPD are the printer manufacturers who want full support for their products in the dialog. In theory, porting it to OSX wouldn't be a problem as OSX uses CUPS as well, but the native OSX dialog provides all the needed features anyway so it seems a little pointless. Windows would be next to impossible to support. So a major point of mine will be that any implementation needs to degrade gracefully to the standard Qt print system, and to gain client apps in the wider Qt world they will need to address the issue. Actually, I am a little concerned about the Gnome side of things, OpenPrinting missed the boat with the Gtk3 release, and there's noises now coming from a certain Gnome dev that he doubts it will get adopted, especially as the dialog design breaks their HIG. Worst comes to worst, we may not get a common backend or look-and-feel, but we'll get agreed standards on the PPD and colour management integration into the dialog which we can implement in Qt. The new printing dialog should not be shy on options, such as pamphlet printing, customizable filters, and (most importantly) application specific options with the ability to allow saving settings in global or application specific profiles. Yep, the settings management comes built-in to the dialog, if you've ever used the OSX dialog it's clearly inspired by that. As for pamphlets and filters, I don't think they are supported as yet, but as it is an entirely pdf/ps based workflow adding them is definately an option, unlike with Qt. The best place for pamphlet support is in CUPS itself, but it's proving difficult to get in there so a filter remains the best short-term option. The second concern is about the D-Bus API. I hope that it will still be possible to get a fast in-application preview with it when using the native API. Yes, I have some concerns about the whole D-Bus thing, there's argments for and against doing it that way. What I'm hoping is whatever API and library gets implemented abstracts away the backend implementation so we have the option of pulling it all back in-process if it proves too inefficient or Gnome doesn't play along. For example, I love how the current Qt printing preview dialog just copies image pointers in the QtPrinter painting engine, so that the preview renders literally the same images as the application has in memory, without copying the actual data. The Qt printing preview is also very fast in scrolling and zooming, I doubt it would be possible with a program that effectively just tries to parse PostScript or PDF printer files just to generate the preview. The current KPrintPreview and QPrintPreviewDialog will still be an option, but they won't integrate well with CPD. QPrintPreview in particular will know nothing about the CPD unless Qt adopts it. For most apps the CPD preview using poppler would be fast enough, will reflect the full set of page manipulation options available, and be a simpler workflow. I do like how smoothly QPrintPreview works, I just wish Qt had finished the job by merging it more with QPrintDialog and supporting all the CUPS options in a cross-platform way. Another issue with QPrintPreview (and QPrinter in general) is the Okular case, where what is rendered by the app on screen is a far lower resolution version of the actual document than what you want printed. If QPrinter supported taking a print file then it could be worked around. The CPD does allow you to pass separate preview and print
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Thursday 17 Mar 2011 06:29:16 Boudewijn Rempt wrote: For what I got out of it, colord seems to be, like so many generic libraries be focussed on gnome/gtk-first Aye, there are a lot of those system libraries coming out from Red Hat / Gnome that give no thought to KDE integration, or even make decisions that make KDE support harder. I drafted an inflamatory blog about it during the latest brouhaha but decided not to pour more petrol on the fire. It's something we need to address and figure out how to get them to think about us more. We certainly need to be more proactive about spotting these things early and jumping in to try influence them. I haven't read the icc list yet, but would I be right in thinking colord is a far more recent than oyranos, so another NIH effort? Working together on a common solution seems so much more sensible in such an esotoric area, especially if users have to configure two separate CM systems for their Gtk and KDE apps, but at least we have an alternative this time. John.
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Thursday 17 Mar 2011 06:30:50 Kai-Uwe Behrmann wrote: Am 17.03.11, 00:27 +0100 schrieb Christoph Feck: Kai-Uwe Behrmann (maintainer of KDE color management applications) can help you here. Grab him on http://www.oyranos.org/ and make sure he attends the meeting ;) It would be really cool to have joined you to talk about colour management with KDE. However I am very likely to be swamped with work during this time. With the help of OpenICC[1] some work has been done inside the Oyranos project about printing. The Kolor Manager configuration panel[2] shows some of these. It would be cool for CPD to deploy Oyranos device ICC profile configuration to create a good user experience. I am about preparing some schematic diagrams, which can give some condensed input from the latest OpenICC discussions around linux colour managed printing. Hi Kai, It's great to know we have someone working on this, it's a shame I didn't know earlier when first discussing attending the summit with the OpenPrinting guys, it would have been great to have someone there who knows what they are talking about :-) I guess I have a lot of reading to catch up on to understand how this all works and hangs together, then hopefully I can make some meaningful comments at the summit on what KDE would like to see happen. Something I think I'll need to understand is why the CPD (or any print dialog) would need to have direct support for different colour management systems (Oyranos, colord), is there a way to abstract it via a common standard? Thanks for your work! John.
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am 17.03.2011 12:11, schrieb John Layt: On Thursday 17 Mar 2011 06:30:50 Kai-Uwe Behrmann wrote: Am 17.03.11, 00:27 +0100 schrieb Christoph Feck: Kai-Uwe Behrmann (maintainer of KDE color management applications) can help you here. Grab him on http://www.oyranos.org/ and make sure he attends the meeting ;) It would be really cool to have joined you to talk about colour management with KDE. However I am very likely to be swamped with work during this time. With the help of OpenICC[1] some work has been done inside the Oyranos project about printing. The Kolor Manager configuration panel[2] shows some of these. It would be cool for CPD to deploy Oyranos device ICC profile configuration to create a good user experience. I am about preparing some schematic diagrams, which can give some condensed input from the latest OpenICC discussions around linux colour managed printing. It's great to know we have someone working on this, it's a shame I didn't know Thanks for your work! John. earlier when first discussing attending the summit with the OpenPrinting guys, it would have been great to have someone there who knows what they are talking about :-) I hope Hal V. Engel from OpenICC, who comes with many experience in printing, will join the OpenPrinting meetings. He lives only some miles away from the location. I guess I have a lot of reading to catch up on to understand how this all works and hangs together, then hopefully I can make some meaningful comments at the summit on what KDE would like to see happen. Something I think I'll need to understand is why the CPD (or any print dialog) would need to have direct support for different colour management systems (Oyranos, colord), is there a way to abstract it via a common standard? We think already since quite some time how to converge for CMS settings. Graeme Gill, the author of a pre dominant cross platform CMS, has signaled high interesst for ArgyllCMS in such a standard, and we both agreed to give that some meaning during this year. We feel settings in one UI should not get irrational lost after switching to an other standard supporting CMS. kind regards Kai-Uwe
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Thu, Mar 17, 2011 at 6:36 AM, John Layt johnl...@googlemail.com wrote: Ah, actually the CPD isn't cross-platform, it's cross-desktop meaning the same dialog design and back-end code used in both Gtk and Qt apps. If you're running a KDE app on a Gnome desktop you'll get the Gnome dialog pop up for consistency with the rest of your Gnome apps, but using the same common backend. Personally, I'm not sure it is consistent to have a KDE app pop up a Gnome dialog, but we'll see. Does this work the other way around as well? If you are running in a KDE desktop and you open the dialog in a KDE application, do you get the KDE version? -Todd
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Thu, Mar 17, 2011 at 6:54 AM, John Layt johnl...@googlemail.com wrote: On Thursday 17 Mar 2011 06:29:16 Boudewijn Rempt wrote: For what I got out of it, colord seems to be, like so many generic libraries be focussed on gnome/gtk-first Aye, there are a lot of those system libraries coming out from Red Hat / Gnome that give no thought to KDE integration, or even make decisions that make KDE support harder. I drafted an inflamatory blog about it during the latest brouhaha but decided not to pour more petrol on the fire. Why not? I think the best time to bring this up is when the issue is already on peoples' minds. If you bring this up later then I suspect it would be interpreted as an isolated problem. Bring it up now, on the other hand, when several other issues already being discusses, I would think would make it more likely for it to be interpreted as a manifestation of a larger problem, and thus hopefully get more attention. At least that is my armchair psychoanalysis view of it ;) -Todd
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am 17.03.11, 12:17 - schrieb John Layt: On Thursday 17 Mar 2011 11:36:08 Kai-Uwe Behrmann wrote: I hope Hal V. Engel from OpenICC, who comes with many experience in printing, will join the OpenPrinting meetings. He lives only some miles away from the location. Yes, I believe Hal will be there, in fact I've been talking to him about the Qt version of the dialog. We think already since quite some time how to converge for CMS settings. Graeme Gill, the author of a pre dominant cross platform CMS, has signaled high interesst for ArgyllCMS in such a standard, and we both agreed to give that some meaning during this year. We feel settings in one UI should not get irrational lost after switching to an other standard supporting CMS. That's good to hear, hopefully you work something out that colord uses as The author is as well on OpenICC and can simply comment on he data base fundamentials and structure, as he did in the past. well, I'd hate to see/implement/support integration code for every different CMS :-) At least Oyranos targets verbaly at cross platform, if thats of relevance for osX and Windows. The Oyranos library API is basic C. ArgyllCMS comes with pure CLI and colord with only DBus. Not sure what you exactly expect out of this mixed concepts for code integration. At least there are two C APIs. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Thursday 17 Mar 2011 15:42:23 Kai-Uwe Behrmann wrote: well, I'd hate to see/implement/support integration code for every different CMS :-) At least Oyranos targets verbaly at cross platform, if thats of relevance for osX and Windows. The Oyranos library API is basic C. ArgyllCMS comes with pure CLI and colord with only DBus. Not sure what you exactly expect out of this mixed concepts for code integration. At least there are two C APIs. Well, I see rhughes on the OpenPrinting list talking about integrating colord directly into the CPD, and then we'll integrate Oyranos, and then I'm sure someone will want ArgyllCMS support as well... But I'm talking from a postition of ignorance here, I need to make time to read all the doco and mailing lists and understand what it actually means. Cheers! John.
OpenPrinting Summit - Print Dialog and Colour Management
Hi, I'll be attending the OpenPrinting Summit [1] to discuss how to complete the Common Printing Dialog [2] and integrate it into KDE and Qt. I'm looking for any feedback people may have about the CPD, and any questions you want me to ask while I'm there. The CPD is a common print dialog implementation in Qt and Gtk that gets called via DBus. The dialog includes a preview image, more user-friendly options, better driver integration, and settings management. Most programs will simply print their entire document to PDF and pass the file to the CPD and not have any more involvement, but there is a callback mode for longer multi-page documents to use. We will obviously need new API to wrap the new workflow and functionality, which I think should be a stand-alone Qt-based library until such time as Qt can be convinced to integrate it natively. This library will also need to provide fallback functionality to use the native Qt print dialog for when the CPD is not present, such as on Windows and OSX. Otherwise apps will need to code for two different print paths depending on the platform which is not desirable. You can have a play with the dialog in its current rough and ugly state at [3]. OpenPrinting have a GSoC project to finish the dialog this year which I've promised to help advertise. It would be great if we could find a good Qt gui hacker to make it really shine. Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. The OpenPrinting Summit is part of the Linux Foundation Collaboration Summit immediately following Camp KDE, so if you're attending and want to be involved in either of these areas please let me know, backup on the more technical aspects would be welcome. Cheers! John. [1] https://www.linuxfoundation.org/collaborate/workgroups/openprinting/openprinting- summit-san-francisco-2011 [2] http://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonprintingdialog [3] http://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonprintingdialog/testdialogfrombzr [4] http://blogs.gnome.org/hughsie/ and http://colord.hughsie.com/
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Wed, Mar 16, 2011 at 1:44 PM, John Layt johnl...@googlemail.com wrote: Hi, I'll be attending the OpenPrinting Summit [1] to discuss how to complete the Common Printing Dialog [2] and integrate it into KDE and Qt. I'm looking for any feedback people may have about the CPD, and any questions you want me to ask while I'm there. The CPD is a common print dialog implementation in Qt and Gtk that gets called via DBus. The dialog includes a preview image, more user-friendly options, better driver integration, and settings management. Most programs will simply print their entire document to PDF and pass the file to the CPD and not have any more involvement, but there is a callback mode for longer multi-page documents to use. We will obviously need new API to wrap the new workflow and functionality, which I think should be a stand-alone Qt-based library until such time as Qt can be convinced to integrate it natively. This library will also need to provide fallback functionality to use the native Qt print dialog for when the CPD is not present, such as on Windows and OSX. Otherwise apps will need to code for two different print paths depending on the platform which is not desirable. You can have a play with the dialog in its current rough and ugly state at [3]. OpenPrinting have a GSoC project to finish the dialog this year which I've promised to help advertise. It would be great if we could find a good Qt gui hacker to make it really shine. Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. The OpenPrinting Summit is part of the Linux Foundation Collaboration Summit immediately following Camp KDE, so if you're attending and want to be involved in either of these areas please let me know, backup on the more technical aspects would be welcome. Cheers! John. Are there screenshots of the most recent version available? -Todd
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Wed, Mar 16, 2011 at 3:08 PM, Hugo Pereira Da Costa pere...@hep.saclay.cea.fr wrote: On Wednesday 16 March 2011 19:55:48 todd rme wrote: On Wed, Mar 16, 2011 at 1:44 PM, John Layt johnl...@googlemail.com wrote: Hi, I'll be attending the OpenPrinting Summit [1] to discuss how to complete the Common Printing Dialog [2] and integrate it into KDE and Qt. I'm looking for any feedback people may have about the CPD, and any questions you want me to ask while I'm there. The CPD is a common print dialog implementation in Qt and Gtk that gets called via DBus. The dialog includes a preview image, more user-friendly options, better driver integration, and settings management. Most programs will simply print their entire document to PDF and pass the file to the CPD and not have any more involvement, but there is a callback mode for longer multi-page documents to use. We will obviously need new API to wrap the new workflow and functionality, which I think should be a stand-alone Qt-based library until such time as Qt can be convinced to integrate it natively. This library will also need to provide fallback functionality to use the native Qt print dialog for when the CPD is not present, such as on Windows and OSX. Otherwise apps will need to code for two different print paths depending on the platform which is not desirable. You can have a play with the dialog in its current rough and ugly state at [3]. OpenPrinting have a GSoC project to finish the dialog this year which I've promised to help advertise. It would be great if we could find a good Qt gui hacker to make it really shine. Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. The OpenPrinting Summit is part of the Linux Foundation Collaboration Summit immediately following Camp KDE, so if you're attending and want to be involved in either of these areas please let me know, backup on the more technical aspects would be welcome. Cheers! John. Are there screenshots of the most recent version available? Just made these: http://simplest-image-hosting.net/png-0-cpd Left: Qt Right: gtk Hugo Thanks! -Todd
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Wednesday 16 March 2011 19:55:48 todd rme wrote: On Wed, Mar 16, 2011 at 1:44 PM, John Layt johnl...@googlemail.com wrote: Hi, I'll be attending the OpenPrinting Summit [1] to discuss how to complete the Common Printing Dialog [2] and integrate it into KDE and Qt. I'm looking for any feedback people may have about the CPD, and any questions you want me to ask while I'm there. The CPD is a common print dialog implementation in Qt and Gtk that gets called via DBus. The dialog includes a preview image, more user-friendly options, better driver integration, and settings management. Most programs will simply print their entire document to PDF and pass the file to the CPD and not have any more involvement, but there is a callback mode for longer multi-page documents to use. We will obviously need new API to wrap the new workflow and functionality, which I think should be a stand-alone Qt-based library until such time as Qt can be convinced to integrate it natively. This library will also need to provide fallback functionality to use the native Qt print dialog for when the CPD is not present, such as on Windows and OSX. Otherwise apps will need to code for two different print paths depending on the platform which is not desirable. You can have a play with the dialog in its current rough and ugly state at [3]. OpenPrinting have a GSoC project to finish the dialog this year which I've promised to help advertise. It would be great if we could find a good Qt gui hacker to make it really shine. Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. The OpenPrinting Summit is part of the Linux Foundation Collaboration Summit immediately following Camp KDE, so if you're attending and want to be involved in either of these areas please let me know, backup on the more technical aspects would be welcome. Cheers! John. Are there screenshots of the most recent version available? Just made these: http://simplest-image-hosting.net/png-0-cpd Left: Qt Right: gtk Hugo -Todd
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Wednesday 16 March 2011 19:55:48 todd rme wrote: On Wed, Mar 16, 2011 at 1:44 PM, John Layt johnl...@googlemail.com wrote: Hi, I'll be attending the OpenPrinting Summit [1] to discuss how to complete the Common Printing Dialog [2] and integrate it into KDE and Qt. I'm looking for any feedback people may have about the CPD, and any questions you want me to ask while I'm there. The CPD is a common print dialog implementation in Qt and Gtk that gets called via DBus. The dialog includes a preview image, more user-friendly options, better driver integration, and settings management. Most programs will simply print their entire document to PDF and pass the file to the CPD and not have any more involvement, but there is a callback mode for longer multi-page documents to use. We will obviously need new API to wrap the new workflow and functionality, which I think should be a stand-alone Qt-based library until such time as Qt can be convinced to integrate it natively. This library will also need to provide fallback functionality to use the native Qt print dialog for when the CPD is not present, such as on Windows and OSX. Otherwise apps will need to code for two different print paths depending on the platform which is not desirable. You can have a play with the dialog in its current rough and ugly state at [3]. OpenPrinting have a GSoC project to finish the dialog this year which I've promised to help advertise. It would be great if we could find a good Qt gui hacker to make it really shine. Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. The OpenPrinting Summit is part of the Linux Foundation Collaboration Summit immediately following Camp KDE, so if you're attending and want to be involved in either of these areas please let me know, backup on the more technical aspects would be welcome. Cheers! John. Are there screenshots of the most recent version available? Just made these: http://simplest-image-hosting.net/png-0-cpd Left: Qt Right: gtk Hugo -Todd
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Wednesday 16 March 2011 18:44:31 John Layt wrote: Hi, I'll be attending the OpenPrinting Summit [1] to discuss how to complete the Common Printing Dialog [2] and integrate it into KDE and Qt. I'm looking for any feedback people may have about the CPD, and any questions you want me to ask while I'm there. Many thanks, John, for never giving up with improved printing in KDE! There a two main issues I see with the current approach of the CPD, and if possible, you could bring them up in the discussion. First, regarding the common part of the printing dialog, I hope that using a common denominator of features offered in all operating systems does not reduce the feature set again; we already went through it. (I guess you know the existing bug reports. It boils down to the major feature loss that we got when killing KDE 3.x printing system.) The new printing dialog should not be shy on options, such as pamphlet printing, customizable filters, and (most importantly) application specific options with the ability to allow saving settings in global or application specific profiles. The second concern is about the D-Bus API. I hope that it will still be possible to get a fast in-application preview with it when using the native API. For example, I love how the current Qt printing preview dialog just copies image pointers in the QtPrinter painting engine, so that the preview renders literally the same images as the application has in memory, without copying the actual data. The Qt printing preview is also very fast in scrolling and zooming, I doubt it would be possible with a program that effectively just tries to parse PostScript or PDF printer files just to generate the preview. Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. Kai-Uwe Behrmann (maintainer of KDE color management applications) can help you here. Grab him on http://www.oyranos.org/ and make sure he attends the meeting ;) Christoph Feck (kdepepo)
