PDF export must support CMYK

[dg0yt]

agnar reported on Sourceforge [tickets:#482]:

Current Export to PDF is in RGB. Hence, I have problems getting the green colors correct on printouts via vector PDF.

In the colour window, the basic PMS colours are already defined as CMYK, which should be the default colour model for export to PDF.

[dg0yt]

• labels: --> Colors
• Category: Bug_Report --> Feature_Request
• Milestone: - bugs - --> 1.0

[dg0yt]

The PDF export is based on the features provided by Qt where CMYK is currently not supported. So it may be much more effort to provide CMYK than it was to provide PDF at all.

On the other hand, CMYK is not a device-independant color space, i.e. you must know your printer in order to determine correct color values. It was a mistake to define CMYK values in the ISOM 2000. What is really needed, that is definitions in a true color space, and Mapper needs to get proper color management support.

[dg0yt]

agnar posted on Sourceforge:

Well, since all printers are CMYK, CMYK is much more predictable than RGB.

Thats why the entire graphics/printing industry uses CMYK, not RGB nor other color model. And since orienteering maps are made for print, they should also adhere to the CMYK color model.

Yes, there may be some variations depending on printer and type of paper used. But, that's what ICC colour profiles are for.

The problem in the case of OOM, is that the green colours are far out of gamut and is not reproducible in print. Try to open a vector PDF-export in Adobe Illustrator and change the color model from RGB into CMYK. You will be shocked how much the green colours change. In some cases, you will not be able to see the difference between 60% green and 100% green in print, while the 30% green will be much darker than it should.

Agnar

[dg0yt]

You seem to assume that C, M, Y and K are the same colors on all printers. That's wrong. CMYK is a device-dependant color space (and so is plain RGB).

You seem to assume that printer drivers would always really accept CMYK. That's wrong, too. AFAIK many printer drivers require RGB input.

And even if they accept CMYK, I would doubt they pass it on unmodified. They may wish to replace mixed gray with black or to limit the amount of color on each spot.

ICC colour profiles are part of color management, and color management is to take care of making sure that the same color - may it be defined in sRGB or what ever absolute color space - comes out the same on each (supported) device.

Whatever you do in Mapper, the colors are device dependant at the moment. (Apart from the spot color separations.)

[dg0yt]

oskarlin posted on Sourceforge:

It's not just about which color space is the best.

This is what's important: When I have a line which is 50% black, it comes out as like 52% Cyan 42% Magenta etc etc which means my printer will use all CMY colours to print gray instead of printing from the K cassette. This makes the printed lines horrible because they are made of three colours instead of one.

At the moment I have to export the file to PDF and then open in Illustrator, change all the colours to the right CMYK values and then print it. NOT good workflow.

Also, this problem occurs not only on PDF export but also when printing from Mapper. (on Mac)

[dg0yt]

I'm not discussing about what is the best color space. I try to find out what is the problem which we need to solve. And again, the PDF export is based on the features provided by Qt where CMYK is currently not supported. So it may be much more effort to provide CMYK than it was to provide PDF at all.

With Mapper's current way of defining colors, 50 % black is CMYK 0/0/0/50 and RGB #808080 (or #7F7F7F). This is what I would expect. Thus it must be some step outside Mapper which turns #808080 in 52/42/... So does it mean RGB #808080 was wrong in the first place? I really don't know.

[dg0yt]

oskarlin posted on Sourceforge:

Well my printer interpret 50% gray as a mix of all colours when printing from OOM. Also if I open an exported PDF (or a PDF made from print->save as PDF) in Illustrator, the gray is not gray, it's all these mixes of colours too.

So there's definitely something about the conversion from RGB to CMYK etc.

[dg0yt]

Somebody posted on Sourceforge:

When ckecking a PDF created from OOM 0.5.96 on Mac OS 10.10 in Affinity Designer, RGB values seems to be correctly transformed to CMYK, i.e. #7F7F7F is shown as 0-0-0-50 etc. CMYK-RGB conversion is just an approximation, eg. RGB #7F7F7F may also be converted to CMYK 51-44-44-8. Note also that K is not really black, https://en.wikipedia.org/wiki/CMYK_color_model, which various drivers handles with sometimes surprising effects. As long as Qt does not support CMYK, then my guess is that rasterizing is the only possibility to fully avoid driver/printer specific behaviour. I would also investigate EPS output.

Andreas Oxenstierna (thanks for a really good software!)

[dg0yt]

Somebody posted on Sourceforge:

I had to check ... Qt seems to support CMYK according to http://doc.qt.io/qt-5/qcolor.html, or ?....

Andreas Oxenstierna

[dg0yt]

You confirm my findings. But you also miss the point that any new output option means to full implement from scratch something which is otherwise done by Qt (if we cannot cleanly extent Qt, but see my next comment.)

[dg0yt]

QColor supports CMYK, and we use it. But QPdfEngine and friends don't support CMYK. QPdfEngine::setPen() always writes RGB values, even in grayscale mode. If we would like to extend this, we would need to fork that part of Qt, and maintain it in a way which works for own packages (Windows, OS X) as well as for Linux packages (with the distribution's Qt which might be a little bit different).

Another option I considered so far was postprocessing the PDF stream, replacing color commands as they pass by. But this could easily go wrong if not done properly.

[dg0yt]

agnar posted on Sourceforge:

The choices made in the implementation is quite understandable; I respect that. It enabled you to get something working very fast.

There is another issue that needs to be taken into account here too: Course planning and course planning software. Most maps printed today are printed only for a specific race, with courses. They might come from Ocad's course planning module or PurplePen.

Today and yesterday, my club is organizing Trondheim Open. We decided to make the maps in OOM, and after some experimentation, we exported the maps as BMPs. Then we did the layout in Adobe Illustrator (staying in RGB-mode), and exported the final map with layout to another BMP (still in RGB). On the sprint yesterday, we used Ocad as course planning software, and today we use PurplePen.

Printing the maps and course on my home deksjet, and the office laser printer, the maps looked OK. With a distinct difference between 50% green and 100% green. But when the maps came back from the printing shop, the two shades of green were hardly distinguishable. This is because the two colours are both far outside printing gamut. They are well apart in the RGB-space, but end up very close in printing colour space.

But, because OCAD and PurplePen doesn't not support CMYK images as input (very little software do), we are going to be stuck with RGB a little longer, until PurplePen starts supporting omaps directly. Possibly, the best option today is to export the map as Ocad and do course planning from there. PurplePen has a very good Ocad renderer. My only worry is whether the Ocad file is rendered identicly to the Omap file.

I think the best way in the short term is to have a closer look on how to convert the CMYK/Pantone color specifications and the various tints into RGB colours that are within printable gammut, as this will give a more predictable result on the final map. Then use that RGB in both screen and file export. It will not be perfect; it will not be until course planning has a better support for CMYK on the input side. But that's where we are today...

Agnar

(Edited for Web by Kai Pastor)

[dg0yt]

Somebody posted on Sourceforge:

Especially green shades needs to be adjusted dependent on output workflow (direct (EMF) printing, EPS, PDF, ...) and used printer. For example I use CMYK 20-0-35-0 for 30% green and 33-0-51-0 for 60% green when printing with EPS to a HP M551 printer. Printing directly from OCAD I need to use 12-0-28-0 resp. 23-0-45-0. So this has not much to do with RGB or CMYK, it is more the device-dependencies and lack of homogenous color management between screen, softwares and output devices.

Andreas

[dg0yt]

Somebody posted on Sourceforge:

Qt seems to support PostScript, http://doc.qt.io/qt-4.8/qprinter.html#OutputFormat-enum, at least on X11. But I cannot find if it supports CMYK.

Andreas

[dg0yt]

Attached are PDF exports of an example map in the current implemenation (DeviceRGB) and an experimental implementation (a fork from Qt) which uses DeviceCMYK for pens and brushes. I don't know yet

• how to handle image layers
• how to manage this implementation for a wide range of Qt versions (esp. Linux distributions).

As an alternative to DeviceCMYK and DeviceRGB, someone is proposing sRGB ICCbased color space.

DeviceRGB.pdf DeviceCMYK.pdf