<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'DejaVu Sans'; font-size:12pt; font-weight:400; font-style:normal;"> On Monday, February 28, 2011 06:22:29 AM Cyrille Berger Skott wrote: > On Friday 11 February 2011, Hal V. Engel wrote: > > I had a closer look at the PDF files produced by the Qt print dialog. I > > see the following: > > > > 1. The first line is > > > > %PDF-1.4 > > > > So these are NOT PDF/X. > > > > 2. All image objects are either DeviceRGB or DeviceGray even when using a > > color managed app like Krita with a color managed image. Looking at the > > code in QPdfEnginePrivate I see that that this is hard coded. > > > > 3. Images are always 8 bits/channel or less. QImage limitation. > > > > So the Qt PDF print work flow will need a lot of work done to it to be > > fully useable. Has anyone here who works on Qt or KDE based imaging apps > > like krita or Scribus have any work arounds for this? > > As far as I know Scribus uses its own PDF generation code. I guess I knew this already. In fact, if my memory is correct, the PDF code in Scribus is able to handle creating fully formed correctly color managed PDFs. And it is one of the few open source apps that will do this. > > As for Krita, by default, the image is converted to sRGB 8bit for printing, I guess this is about all that can be done with the current printing software stack and the limitations currently imposed by Qt short of writting a printer interface. Converting to sRGB is more than most apps are doing at this point. > there is a configuration option (with no UI) to set a different profile for > the printer. > > It is worth to note that for Krita, we do not consider printing as part of > our important features. IE, we consider that the artists job stops in > Krita at creating the image. He can print it on his 30¤ printer, but if > the user is running a shop with 30000¤ printers, he should use other > software to print the image (after drawing it with Krita, of course ;P ). > This is why Qt not supporting the color profile in PDF, and having to > convert to sRGB 8bits, is not considered a critical issue for Krita. Of > course, if at a latter stage, the API allows better support for color > profiled printing, we will make sure that Krita makes the best of them. The Qt PDF printing flow actually looks worse than I had originally thought. The app opens a logical paint (QPrinter) device that it paints the output to and it has no idea if that device is using a PDF or some other format for the spool file (this is set by the user in the QPrinterDialog) and the paint engine hides this detail from the app. doing the painting. So the app. has no way to take advantage of PDF features such as color management or the ability to handle higher bit depths. In other words it acts like a generic Qt paint device and is limited to what can be done to a QImage or a QPixmap (8 bits/channel RGB, gray only and no metat data). At a minimum the Qt PDF engine needs to tag images with either good default ICC profiles or with good default CalRGB and CalGray tags instead of using deviceRGB and deviceGray for all images. The underlaying issue is that the paint engine should allow apps to paint images in formats other than QImage (IE. a jpeg or tiff) and the backend should parse the image for things like ICC profiles and it should use those as part of the output stream if the actual paint device support these like a PDF device can. Or QImage needs to be extended to support this meta data and higher bit depths. I suspect that the Qt folks would argue that you can open most image formats as a QImage so is unnecessary to allow painting in native file formats but this ignores that fact that the process of opening a tiff or jpeg image as a QImage discards almost all of the meta data that is part of that image including ICC profiles. In addition it flattens the image to a max of 8 bits/channel. Hal</body></html>