I teach high school and I have a student creating a book cover for an assignment I give my Intro to Design students. In the seven years I have been teaching, this is the first time I have had a student have troubles with how colors appear on screen. I have been looking at her file and can't figure out the issue. I made a new file from scratch and I'm not having the same troubles with mine, so it's something about her file in particular.
She was not importing any photos to her project, just using the shape tool to set a background color. My students set up their files with the intent of Print. I know this will give them a CMYK color space but I have told the students that they can use the color picker and as long as they "save RGB swatch" the brighter color they want will show on screen. We don't actually print these projects, I view and grade them on screen. When she creates and saves an RGB swatch it shows up super dull. She's trying to create R 0, G 0, B 255 and it always shows up this very washed out looking color. Oddly, when she extends her shape beyond the page border and out to the bleed, the color looks darker over the gray pasteboard than it does over white page. It does not do this on the document I made.
Both are the same RGB value. Both documents are GPU preview. Both are in a proof set up of Document CMYK U.S. Web Coated (SWOP) v2
Does anyone know what to do? I've been looking up info on color spaces and not finding anything helpful. I apologize if this seems really elementary, I am self taught on Graphic Design (my background is painting and printmaking) so when odd issues like this come up, I can't seem to figure out the trouble. I appreciate the help!
You say this happens while in Soft Proof, however I doubt that very much! I guess what you mean is the profile used in your setup, that's something different!
What you see is normal, it is the difference between the RGB Gamut and the CMYK gamut in print.
Try softproofing on both machines.
Also, on proofing: it could be that one machine is setup with a RGB blend transparency blend space and the other with CMYK document blend space (this is something different than the profile setup!), that means that, as soon as there is any transparency on the age (a shadow but also when there is transparency in an image!) the CMYK rendering will kick in on screen, unless of course the blend space is setup as RGB.
So lets first check the document Transparency Blend space...
There are a number of ways an RGB color will preview inside of the document's assigned CMYK profile.
This document has no transparent object on the live spread, has Overprint/Separation Preview turned off, and has Proof Colors turned off
Here I've turned on Overprint Preview, which shows how the out-of-gamut RGB color is expected to print in the document’s CMYK space:
Here I've turned on Proof Colors with the Proof Color Setup set to custom US Web Coated SWOP:
And here I've applied the Multiply transparency Effect with my document‘s Transparency Blend Space set to CMYK—the transparent object changes the preview of the entire spread:
Can someone just speak plain english here, pls? I've been struggling with this issue a lot and don't really understand why Adobe cannot fix this permanently.
don't really understand why Adobe cannot fix this permanently.
Because there is nothing to fix.
Simply put: if you design for screen or want to see vibrant colors which never can be produced in CMYK due to physics set your transparency blending space to RGB (under Edit) and use high quality view setting instead of Overprint preview (which always assumes CMYK output).
If you actually want to print you have to accept that vibrant colors can only be produced (and viewed) if you use special inks/spot colors, e.g. PANTONE.
Most users are unaware of the 'connection' between document 'Mode', in the New document dialog box, their choice of 'Print' vs 'Web' vs 'Mobile' and the Transparency Blend space. If the original poster's student chose 'Web' or 'Mobile', that would have set the Transparency Blend space to RGB, automatically.
This 'feature' deserve better documentation, in my view.