On Jan 29, 2013, at 11:10 AM, Benjamin De Kosnik <b...@redhat.com> wrote: > > This is just scratching the surface. How are you going to evaluate > quality? I'm concerned about the rasterization changes, the filter > changes. Hopefully 1.6 may solve some of the image-quality regressions > I've been seeing.
Quality evaluation needs test targets/documents, and eyeballs. Many test targets are free or easily produced and could be CC0 licensed or something reasonable. This is something I've briefly discussed with Richard Hughes, and also participants in OpenICC, that are needed not just for print, but also for display. Perhaps some OpenICC and OpenPrinting collaboration is appropriate for acquiring test metrics. Since CUPS itself doesn't rasterize, I don't expect you'd see changes in this area; but if there are filter changes, or an application decides to produce PDF job instead of PostScript, then it's possible, but probably not intended. If there are features or effects that need to be performed on a job after the application has produced the job, there are advantages to doing this on PDF than PostScript. But my expectation is even applications that today still use PostScript, they would be subject to the pstopdf filter, which in turn defers to Ghostscript on linux (Quartz2D by default on OS X) to turn it into a PDF. Such normalization of postscript to pdf is something that's been going on for many years, and is well tested (with many bug carcasses along the way). > > 4) In the past, I've found it difficult to debug cups filters step by > step. Especially with so many rasterization/filter changes. Yes this is tedious. Figuring out the sequence for a job isn't so difficult. But in case of problems, it would be useful to break the sequence, i.e. get access to the print job in a particular state in between filters. I've got some material on how to do this, for the purposes of troubleshooting the OS X print pipeline which of course uses CUPS, but different print drivers, raster engine, and color management philosophy. > be updated? I would love it if issues like "what driver am I using" > could be re-integrated into the UI, or perhaps an admin level of the > ui. Also, "what filters did I run to get to this point of output" in a > log file. This is useful. At least on OS X each PDF print job also has a job ticket. I think this is a CUPS thing. Even once the job is complete, and the original document and raster files are deleted, the job ticket remains and it should contain all of this information. Making it more readable somehow might be useful. > > 5) integration with common printing dialog. (IMHO localhost:631). > I think integrating Fedora's print dialogs with the wider user > communities on macos and ubuntu would be very useful. I'm not sure what common printing dialog refers to here. If it's the CPD, that's dead as far as I know, unless it's been raised in the last 2 months. As for using Mac OS as a model for print dialogs, I'm happy to discuss exactly what areas I think this is useful and areas it's to be avoided. OS X for professional printing is nothing short of a clusterf|ck. It has been a huge PITA for me for ~8 years. Central to this problem is color, but also rather significantly is the UI/UX. We get *two* print dialogs for every print job with such applications due to lack of integration between the OS dialog and the application dialog. So we get an application dialog, and then later get an OS dialog, and they each contain mutually exclusive features, or settings that conflict between application and the OS. And the arbitration and assumption for this is not great, and not well documented. And this is aside from the separate interactions that occur with the print driver which does integrate with the OS dialog, but can itself have settings that conflict with the OS, or the application. The UI/UX part isn't much different on Windows, but the color management ideology is, and that actually helps rather significantly for those who actually care about such things. So the hopeful idea is to mimic the successes of these companies, and avoid the mistakes. Should be easy. Ha! Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
