CMYK support in PDF export

[Andreasox]

CMYK support in PDF export would enhance the value of QGIS for high-quality printing.
My understanding is:
Qt5 do support CMYK on screen
Qt5 does not support CMYK support in PDF export
Mapper, https://github.com/OpenOrienteering/mapper, also built on Qt, has implemented CMYK support for PDF export by forking some Qt classes.
Mapper's main developer can give guidance from the work he did for Mapper.
My company do have developers that may assist.

[nyalldawson]

There's no support (yet) in qt even for on-screen cmyk

[Andreasox]

On-screen CMYK is not really needed.
Although QColor do support CMYK according to https://doc.qt.io/qt-5/qcolor.html
It should be enough with a config file holding the RGB-CMYK conversion used for PDF export.
In Mapper specified colours are defined as RGB and optionally in CMYK as well.

[nyalldawson]

It is necessary to handle this correctly on screen too - CMYK changes the blending model entirely, so a CMYK based map will look different on screen vs those same colors converted to RGB and using an RGB blending model.

[Andreasox]

I am working with high-quality cartography and there CMYK values are defined by the printing capabilities and/or in standardised specifications (eg. orienteering maps). The screen can only be used as reference if using advanced colour management profiling against selected paper qualities. The users must be aware of screen contra print differences.
As a side note we have realized that Windows 10 RIP is vastly enhanced over W7, and is much better than Adobe standard RIP. Especially for thin lines due too much higher LPI.
I.e. the print workflow can be more important than screen calibration.
I assume Qcolor conversions can be used for colors not defined in a config file.

[SilvioGrosso]

Hello,

Perhaps, you can take a look at Krita [1], an open source software, which relies on the QT toolkit (5.12.X to be more precise...).
With Krita you can take advantage of the CMYK mode. However, I don't know whether they implemented it thanks to the Qt librairies or by way of some internal code...

[1] https://docs.krita.org/fr/general_concepts/colors/color_models.html

[nyalldawson]

@SilvioGrosso Krita uses it's own painting engine -- it doesn't use any of the QPainter API

[nyalldawson]

I am working with high-quality cartography and there CMYK values are defined by the printing capabilities and/or in standardised specifications (eg. orienteering maps). The screen can only be used as reference if using advanced colour management profiling against selected paper qualities. The users must be aware of screen contra print differences.

I realise this. And that's why to do this properly we need to correctly handle CMYK blending for screen as well as outputs, and ensure that a project set to a CMYK color mode never generates or displays colors outside of the CMYK gamut. Otherwise QGIS would be giving a false preview of the results, and you may as well just stick to RGB editing in QGIS and conversion to CMYK as a separate post-processing step outside of QGIS. The value in adding native support for CMYK would be that users could edit and design maps inside QGIS with confidence that the result will color match the output exactly.

[SilvioGrosso]

Hello @nyalldawson

Krita uses it's own painting engine -- it doesn't use any of the QPainter API

Yep. That's what I have thought too but I was not 100% sure...

What I know for certain is that the Krita developers have not used the QT librairies to import and export the SVG vector images because QT is not powerful enough for their needs.
An interesting library for this task might be resvg [1]:
https://github.com/RazrFalcon/resvg

At present, one workaround with QGIS missing printing capabilities might be to take advantage of Scribus [2], another QT open source application. Needless to say, a native support of CMYK would be much better :-)

[1] http://libregraphicsworld.org/blog/entry/introducing-libresvg
[2] https://wiki.scribus.net/canvas/Color_Management_setup

[Andreasox]

I am working with high-quality cartography and there CMYK values are defined by the printing capabilities and/or in standardised specifications (eg. orienteering maps). The screen can only be used as reference if using advanced colour management profiling against selected paper qualities. The users must be aware of screen contra print differences.

I realise this. And that's why to do this properly we need to correctly handle CMYK blending for screen as well as outputs, and ensure that a project set to a CMYK color mode never generates or displays colors outside of the CMYK gamut. Otherwise QGIS would be giving a false preview of the results, and you may as well just stick to RGB editing in QGIS and conversion to CMYK as a separate post-processing step outside of QGIS. The value in adding native support for CMYK would be that users could edit and design maps inside QGIS with confidence that the result will color match the output exactly.

I agree that your description is the ideal but resources ...
We currently uses a Ghostscript-based post-process but see a value in adding the same kind of "pseudo-CMYK" support as Mapper has done.

[mbernasocchi]

@nyalldawson did you ever have a tought about how much work this would require?

[haubourg]

@mbernasocchi that's fun you ask now, I was about to ask the same. At least our customers are interested in.

[mbernasocchi]

same here, we might have something as well

[nyalldawson]

@haubourg @mbernasocchi can we follow up via email? (nyall@north-road.com). I've got a bunch of previous email exchanges relating to this which I'll cc your way and fill you in on the situation...

[mbernasocchi]

great thanks

[llwj0303]

im also facing this problem, I had used GhostScript to change RGB pdf to CMYK color mode, but it is not suitable for me, as something like RGB(0,0,0)->CMYK(0.72, 0.67, 0.67, 0.88), that may waste a lot ink for printing it.
does the https://github.com/OpenOrienteering/mapper, can solve my problem?
you guys if find answer pls info me 479379320@qq.com
thanks a lot~

[AndyFollis]

My problem is perhaps a subset of this - when sending to print on a commercial printing press rather than a laser printer, I need the black to be C0 M0 Y0 K100, otherwise I risk colour fringing and bleed in thin black lines.
I'm happy enough with the screen showing RGB but I need to at least be able to set black as CMYK 'pure black' not this 'rich black' which has other colours (and thus ink!) in it.
At the moment I'm having to export then do a printing prefight in Adobe Acrobat Pro to correct the 4c blacks - and I then need to set the correction for each different 4c black individually.
If anyone can help on this I'd be really grateful.

[vpicavet]

A note on what ArcGIS does with this matter. This item in the FAQ dating back to 2016 adds a note concerning RGB / CMYK :

CMYK output is supported with the following limitations:

· ArcMap raster layers always render internally as RGB colors. This means that even when a raster is defined with the color selector in CMYK mode, it does not internally get marked as CMYK color, and the raster layers stores only the RGB equivalent. On export to a CMYK graphics file, the stored RGB information is converted from RGB back to CMYK, but the CMYK values do not match the user defined CMYK values selected during set up of the raster layer properties.

· Vector layers with transparency render as raster. Thus, any transparent vector layer using CMYK colors are not preserved CMYK numbers during output to a CMYK export file.

· Picture Marker symbols sourced from a vector EMF file always use the colors defined in the EMF. Since the EMF file format does not support CMYK colors, it is not possible to define EMF Picture Marker symbols as CMYK. Instead, use a Simple Marker Symbol or a Character Marker Symbol, and follow the procedure documented above to define the symbol colors in CMYK.

From what I understand, it means that ArcGIS internally handles colors as RGB, but they keep a correspondence table when you input a CMYK value, allowing for CMYK colors exported correctly with the above limitations.

A full CMYK support would be great and better than ArcGIS, but it would need improvements in Qt as it seems.

[senorhesles]

Can we get a feature bounty or something going on the Qt and QGIS end so that this can be implemented? I am very, very willing to contribute as I do not want to have to migrate to ArcGIS or Mapublisher.

[eurojam]

Would it be possible to restrict CMYK support in a first phase on the Layout modules in QGIS to keep the expenses in a limit? Also the blendig mode stuff can stay as it is in the map canvas environment (without CMYK support)...
We are also willing to contribute to this feature with a funding.

[jayaddison]

If anyone waiting on a fix here has Ubuntu focal available to them -- does the resolution of QTBUG-73171 improve the results here?

That bugfix is for an issue where QColor RGB black -- as represented by red=0 green=0 blue=0 -- was converted to cyan=1 magenta=1 yellow=1 black=1, instead of cyan=0 magenta=0 yellow=0 black=1.

It's not clear to me whether the fix corrects on-screen rendering and/or printing pipelines. The fix was added in 5.12.2 of QT, and focal currently distributes 5.12.8.

[nyalldawson]

@jayaddison

No, that doesn't give us the missing functionality yet.

[jayaddison]

Ok, thanks @nyalldawson. I've done a bit more of my homework, and now (think that I) understand that the limitation is in Qt's QPdfEngine, which renders colour-related PDF content in RGB (and using colourspace DeviceRGB). Is that getting closer to it?

[AndyFollis]

Hi, I don’t know the technical details but that sounds to me like the issue: QGIS renders PDFs in RGB colour space. Great for use online and on any form of display. But really irritating for printing because printers use CMYK. The biggest problem as far as I am concerned is the rendering of fine black lines. Most text! RGB colour creates black by using a proportion of all the colours, so an offset litho printer will take four passes to create a fine black line and if there’s the smallest fraction of misalignment, you get colour fringing and a fuzzy line. CMYK has the all-important K (= black). When I create a map in QGIS and export it to PDF I then have to work carefully in post-processing to find all the “RGB blacks” and replace them with plain simple black. It doesn’t look as perfect on screen – 100% K can appear slightly grey on a monitor but my published maps print properly. Just having the ability to chose colour space in PDF outputs would be brilliant. From: James Addison ***@***.***> Sent: 24 July 2022 17:21 To: qgis/QGIS ***@***.***> Cc: Andy Follis ***@***.***>; Manual ***@***.***> Subject: Re: [qgis/QGIS] CMYK support in PDF export (#32754) Ok, thanks @nyalldawson<https://github.com/nyalldawson>. I've done a bit more of my homework, and now (think that I) understand that the limitation is in Qt's QPdfEngine<https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/painting/qpdf.cpp>, which renders colour-related PDF content in RGB (and using colourspace DeviceRGB). Is that getting closer to it? — Reply to this email directly, view it on GitHub<#32754 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQITP7S6FYKFXPI55Y24T3LVVVUQHANCNFSM4JLFTULA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[Andreasox]

Hi We are using Ghostscript for RGB to CMYK conversion - basically as described in https://stackoverflow.com/questions/48936435/convert-pdf-from-rgb-to-cmyk-with-ghostscript Note that conversion to "true black" may depend on input/output color profiles etc. as described  in https://bugs.ghostscript.com/show_bug.cgi?id=698723 May Ghostscript be included as a plugin to QGIS?Our current usage is ad-hoc so we have not invested (yet) in an integrated solution.  Best Regards  Andreas Oxenstierna  Den söndag 24 juli 2022 23:17:42 CEST, AndyFollis ***@***.***> skrev: Hi, I don’t know the technical details but that sounds to me like the issue: QGIS renders PDFs in RGB colour space. Great for use online and on any form of display. But really irritating for printing because printers use CMYK. The biggest problem as far as I am concerned is the rendering of fine black lines. Most text! RGB colour creates black by using a proportion of all the colours, so an offset litho printer will take four passes to create a fine black line and if there’s the smallest fraction of misalignment, you get colour fringing and a fuzzy line. CMYK has the all-important K (= black). When I create a map in QGIS and export it to PDF I then have to work carefully in post-processing to find all the “RGB blacks” and replace them with plain simple black. It doesn’t look as perfect on screen – 100% K can appear slightly grey on a monitor but my published maps print properly. Just having the ability to chose colour space in PDF outputs would be brilliant. From: James Addison ***@***.***> Sent: 24 July 2022 17:21 To: qgis/QGIS ***@***.***> Cc: Andy Follis ***@***.***>; Manual ***@***.***> Subject: Re: [qgis/QGIS] CMYK support in PDF export (#32754) Ok, thanks @nyalldawson<https://github.com/nyalldawson>. I've done a bit more of my homework, and now (think that I) understand that the limitation is in Qt's QPdfEngine<https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/painting/qpdf.cpp>, which renders colour-related PDF content in RGB (and using colourspace DeviceRGB). Is that getting closer to it? — Reply to this email directly, view it on GitHub<#32754 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQITP7S6FYKFXPI55Y24T3LVVVUQHANCNFSM4JLFTULA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>> — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[arx-e]

I have confronted this issue when given a large amount of distribution maps destined for offset printing. the maps were in RGB of course and most of the black lines and texts were being converted as rich blacks. So I created an Illustrator script that looks inside an illustrator file for rich black colors and replaces them with 100%K and also sets their overprint setting to "true".

The script can be used to batch process pdf files and of course can be modified in order to do more clean up. For example I have used conditions to locate and replace reds, yellows, the maps' background etc

The script can be found here: https://github.com/arx-e/pdf-to-cmyk-and-replace-rich-black

[janvda]

I am interested in this feature.

It would also be nice in the absence of this feature if there is a free postprocessing step that does this and which is properly documented.

I think that the "Adobe" post processing solutions are not free (apart from the 7 days free trial period).
The best free approach seems ghostscript. This is a nice link but I haven't tried it:

• https://stackoverflow.com/questions/35596346/ghostscript-convert-pdf-into-cmyk-preserving-pure-black-for-text

[frspp]

@senorhesles Arcgis does not support CMYK. You can use CMYK sliders to choose RGB color. So when exported the "CMYK" colors are actually RGB and won't match chosen CMYK values at all anymore. What a mess 😕 (have tried it). See full explanation in #32754 (comment)

[frspp]

Just throwing out a wild idea: As LAB/RGB gamut is much wider than CMYK gamut what if QGIS would continue to use RGB like it does now and feature/option "Limit to CMYK gamut" would be added to the color selector. This feature would limit the color values to those which are available in some widest CMYK profile, for example in Coated Fogra39. By doing this the on screen view would be much more accurate as it would not include most vivid RGB's, those which cannot be printed in CMYK.

Of course the rich black would still be an issue (=in CMYK graphics black/grey should contain only K and no other colors). If a printing press have a modern workflow they can/will handle converting CMYK rich black to CMYK K only. Imo seeing too vivid colors while designing map is bigger issue than having rich black.

Would this make any sense?

[Ricmokodo]

Just my two cents, having a "convert RGB black to 100K black" checkbox on PDF export would get us 80% there as far as utility. From my experience and in other comments, PDF is the most common export format going to print. I agree with other comments about doing it the right way long term. Maybe this narrow solution is a way to plant the seed for future development.

[andreasneumann]

The good news that upstream we are working with Qt developers to improve Qt to support CMYK in their color models and conversion, focusing on PDF and TIFF formats ... Also, QGIS needs to be changed then to take advantage of the new classes and methods.

It probably will take a while until this ends up at the users desktop (because first this needs to end up in our libraries), but it will come ...

[dg0yt]

The good news that upstream we are working with Qt developers to improve Qt to support CMYK in their color models and conversion, focusing on PDF and TIFF formats ... Also, QGIS needs to be changed then to take advantage of the new classes and methods.

Are the changes visible?
And AFAIU a key desire is to preserve original CMYK while QColor is passed through painting on a PDF.
Instead of "conversions".

[andreasneumann]

Are the changes visible?

Not sure yet. Probably there won't be an exact color match that shows the colors exactly as they would be printed (that would also require a calibrated monitor - most people don't have that).

The developer proposes to integrate https://www.littlecms.com/

And AFAIU a key desire is to preserve original CMYK while QColor is passed through painting on a PDF.
Instead of "conversions".

Yes, the original CMYK values would be preserved when rendering to PDF and TIFF files. That's the goal of the whole exercise. Cartographers will be able to choose between CMYK and RGB color models in the color choice. If they go with CMYK, then the original CMYK values will be preserved in the QGIS project file and also be used during the export.

As stated previously - it will take some time until CMYK will be available for QGIS users. Probably 2025. Some early experiments may show up earlier.

Early versions also may not support opacity and blend modes. They probably will be added later on (hopefully).

[AndyFollis]

I would second this suggestion. Whilst it will be helpful to have full CYMK colour option, the most common problem for me with taking a QGIS project to commercial printing is having to work in Adobe Acrobat to convert all the “rich black” text and fine lines into 100% K to avoid fringing effects and lack of clarity in the finished product. A “convert RGB black to 100K black" option would solve way over 90% of my problems. But CMYK without opacity or blend modes would be a big step backwards for me – I would have to stay in RGB and continue to do post-production conversions of the RGB black because the rest of the map has a lot of blending. From: Ricmokodo ***@***.***> Sent: Thursday, January 11, 2024 3:37 AM To: qgis/QGIS ***@***.***> Cc: Andy Follis ***@***.***>; Manual ***@***.***> Subject: Re: [qgis/QGIS] CMYK support in PDF export (#32754) Just my two cents, having a "convert RGB black to 100K black" checkbox on PDF export would get us 80% there as far as utility. From my experience and in other comments, PDF is the most common export format going to print. I agree with other comments about doing it the right way long term. Maybe this narrow solution is a way to plant the seed for future development. — Reply to this email directly, view it on GitHub<#32754 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQITP7WIV5JHW2ZOD5LMFKTYN5M67AVCNFSM4JLFTULKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBYGYYTOMRRGA3Q>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[dg0yt]

Are the changes visible?

Not sure yet. Probably there won't be an exact color match that shows the colors exactly as they would be printed (that would also require a calibrated monitor - most people don't have that).

I actually meant the source code and API changes.
QGIS is not the only consumer.

[SilvioGrosso]

I actually meant the source code and API changes.
QGIS is not the only consumer.

Yep. It would be interesting to get this final development useful for other softwares, QT based, as well (Krita, FreeCAD, LibreCAD, QCAD, Scribus etc).

I suppose this is already taken into account right now (hopefully...) by the QT developers.
Probably, it also goes without saying since it is in the future interest of everyone.

[troopa81]

I proposed a QEP regarding the support of CMYK into QGIS. Please let me know if you are interested in testing or even funding part of the developments.

[eurojam]

Hi Julien, I will forward this to our CEOs hoping they - or one of our customers - will be part of the funding process. I personally will be interested in testing and comparing it to products done with ArcMap (in my former GIS-Live;-) Best regards Stefan Am Di., 27. Feb. 2024 um 10:20 Uhr schrieb Julien Cabieces < ***@***.***>:

…

I proposed a QEP <qgis/QGIS-Enhancement-Proposals#283> regarding the support of CMYK into QGIS. Please let me know if you are interested in testing or even funding part of the developments. — Reply to this email directly, view it on GitHub <#32754 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALBUG2OOY5KDQWFKJCYRI7DYVWQNLAVCNFSM4JLFTULKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJWGYYTCMRXHE2Q> . You are receiving this because you commented.Message ID: ***@***.***>

[AndyFollis]

I’d be interested in testing it too. But as a private individual doing mapping for a cycling group, I’m afraid I have no funds to contribute ☹ Cheers Andy From: Julien Cabieces ***@***.***> Sent: Tuesday, February 27, 2024 9:20 AM To: qgis/QGIS ***@***.***> Cc: Andy Follis ***@***.***>; Manual ***@***.***> Subject: Re: [qgis/QGIS] CMYK support in PDF export (#32754) I proposed a QEP<qgis/QGIS-Enhancement-Proposals#283> regarding the support of CMYK into QGIS. Please let me know if you are interested in testing or even funding part of the developments. — Reply to this email directly, view it on GitHub<#32754 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQITP7SBPFBLCBFKQB4KAXDYVWQNNAVCNFSM4JLFTULKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJWGYYTCMRXHE2Q>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>