CMYK is automatically converted to RGB if pdfa=true

[zhtaihao]

The color codes (1a, 2c, etc.) specified in the Corporate Design manual are not working properly, perhaps related to 8c3485c and #283. This can be fixed by manually adding back \PassOptionsToPackage{RGB}{xcolor}, however the average user probably does not know this.

Without \PassOptionsToPackage, the resulting colors are much brighter and more vibrant than what the CD specifies. This issue started occurring just right now (in the past ~1 hour) on Sharelatex.

[TeXhackse]

I assume, they Work properly, you Just can't see it. But I will check all colors to ensure.

Your monitor ist using RGB colors, by default TUDaPub ist using CMYK. They were converted to RGB with pdfa=true until the Last update. Because this had been a requirement to create valid PDF/A.

If you are producing a document which should not be printed, you can use the RGB conversion yourself.

I am currently preparing some more information on this for the docs.

[zhtaihao]

While I do not pretend to know how color spaces work in detail, I can assure you that the inclusion (or omission) of \PassOptionsToPackage{RGB}{xcolor} alone makes a visible difference in the created PDF, tested on both PC and mobile.

Are you saying the brighter appearance is intended and in print, it will look darker? Maybe I am totally misunderstanding.

To me, it seems out of place to change this behaviour. Irrespective of print or not, the resulting PDF (without \PassOptionsToPackage) looks weird at the very least, and it hadn't been the case up until a couple hours ago.

[TeXhackse]

Yes. because until a couple of hours ago the in the case you used pdfa=true the default was converted.

RGB colorspace is usually used for displays, CMYK for printing. Now the document is CMYK and your device internally ports this to RGB. This is why you see the difference.

If you send a RGB PDF to the printer you will see the same result about color differences.

I will add documentation on the color options. But you are always free to use \PassOptionsToPackage{RGB}{xcolor} before loading tudapub. Then you will get the same result as before, but you should not print it, without removing because you then will get weird colors on the paper.

[zhtaihao]

So is this an inherent problem with color spaces? Either CMYK (now default) looks too bright on screens -- or RGB looks weird in print, if I'm understanding correctly.

Would my best option be to compile with RGB if I want to share digitally and to only compile with CMYK when I'm at the copyshop? Correct me if there is another way to always get the "right" color.

This may be a whole new topic, but I feel RGB should be (stay) the default option of tuda, seeing how we're moving more and more towards digitalisation and physical prints are becoming rare especially with Corona. Most of the time, I'm not physically printing out anything, so I'd expect CMYK to be the option instead (either with \PassOptionsToPackage or directly as \documentclass[cmyk] maybe). Just my two cents, maybe there are other reasons I'm not seeing.

[schoeps]

Either CMYK (now default) looks too bright on screens -- or RGB looks weird in print, if I'm understanding correctly.

The color handling for pdf/a documents has changed. I was always using pdfa=false for my documents and they are not affected (and I never found the colors strange, it's probably a matter of getting used to).

compile with RGB if I want to share digitally and to only compile with CMYK

The problem is even more complex since you have to take care about RGB and CMYK color encoding also in the images that you include in your document to make everything consistent. If you are using black/what images or tikz images (based on the TUDa colors) then recompiling would be an option. Otherwise there will be another conversion...

[TeXhackse]

@zhtaihao you can directly add it as a global option of course. This just did not work as long as tudapub itself passed the option.

They option passing mechanism will completly change soon, because of some fundamental changes in the LaTeX-Kernel I will take your feedback into the process of redesigning for newer LaTeX formats.

[chrstmnn]

Same issue here. I am close to finish my thesis and the colors don't work properly.

I am writing my thesis in the overleaf instance of TUD. Any suggestions on where to put the command in order to get the correct colors visible on screen?

[schoeps]

Have you tried what is described in the first post, i.e.,\PassOptionsToPackage{RGB}{xcolor}?

[TeXhackse]

@chrstmnn You can add the option passing like described before, but this will lead to strange colors when printing. (at least different htan expected.) Just that you know. this is nothing tuda-ci specific but a natural problem resulting from the difference between the two color mixing models,

[TeXhackse]

Oh I just wanted to take care of this and found that there's a difference between TeX Distributions, I will take a closer look and probably solve everything during the day. but to return to the behaviour still switching to RGB will do it.

[TeXhackse]

Okay, I found it. It's a bit more complicated because there are some interactions, the false display is only archieved if one is creating PDF/A. I ensured that I can create a cmyk-PDF/A which is possible, but pdfx is automatically setting this conversion backwards. because my monitors are calibrated, I did not realize the difference earlier. I am really sorry for this misstake.

Anyway passing the option RGB will help with pdfa= true for printing one would need to set pdfa=false.

I will now try to disable the auto conversion and extend documentation for all document variants on the coloe models, because this is important knowledge, even if it works,.

Btw. the optiom passing is already implemented that way, so directly using the RGB option to tudapub should also work.

[TeXhackse]

I added a note to myself to always check color depending issues on all systems… I hope this helps for you to not get too mad a me. I'm really sorry.

It's fixed and CTAN upload is done (should be available via the installers tomorrow if everything works as usual). I also added additional information at the pdfa-ode description as well as some extra info on the color models.

[chrstmnn]

Sorry to ask again. The templates in the Sharelatex instance of the HRZ have been updated today.

When insterting \code{RGB} to the document class, I can now see the correct colors again:

\documentclass[
    \code{RGB},
    ngerman,
    ruledheaders=section,%Ebene bis zu der die Überschriften mit Linien abgetrennt werden, vgl. DEMO-TUDaPub
    class=report,% Basisdokumentenklasse. Wählt die Korrespondierende KOMA-Script Klasse
    thesis={type=bachelor},% Dokumententyp Thesis, für Dissertationen siehe die Demo-Datei DEMO-TUDaPhd
    accentcolor=3b,% Auswahl der Akzentfarbe
    custommargins=false,% Ränder werden mithilfe von typearea automatisch berechnet
    marginpar=false,% Kopfzeile und Fußzeile erstrecken sich nicht über die Randnotizspalte
    %BCOR=5mm,%Bindekorrektur, falls notwendig
    parskip=half-,%Absatzkennzeichnung durch Abstand vgl. KOMA-Script
    fontsize=11pt,%Basisschriftgröße laut Corporate Design ist mit 9pt häufig zu klein
%   logofile=example-image, %Falls die Logo Dateien nicht vorliegen
]{tudapub}

If I insert the code, I get the following error: Undefined control sequence.

Any idea on this?

[TeXhackse]

Yes, and it's a bit funny, because \code{RGB} is used to print this one using the codefont in the documentation. You should only insert RGB. I will try to make this more clear, sorry for the confusion.

[chrstmnn]

Works now. Thanks a lot!