BofG

I have an entire ream of 350gsm silk coated (expensive!) paper with calibration charts on - I literally tried every single setting on the printer trying to correctly profile it. I remember checking the website and seeing it stated cmyk support, so I persevered. Grrr.

One of the serif staff first said cmyk is not possible at all, they then edited their post to say that was only true on Windows having been "reliably informed" cmyk worked on MacOS. A few MacOS users tested things and found it to be the same situation as on Windows. From page 2 of this thread there is some testing done: And here's the thread where one of the staff goes from saying cmyk isn't possible, and then contradicting themselves a bit but without any real clarity.

A quick Google shows there are models that have PostScript drivers, so it's at least a possibilty the OP can use cmyk as they want. It's entirely impossible to do so when printing from Affinity, which is something that should be made clear rather than letting them continue to waste ink and media trying. It's something that drives me slightly crazy as I've been the person wasting toner and paper - I think Serif should be more up front about this limitation, instead their sales copy makes a song and dance about having "end to end CMYK".

What @Lee D didn't mention (and what the sales copy also neglects to point out) is that you cannot send CMYK data to a printer directly from Affinity. It will convert it to RGB (most likely sRGB but no one has confirmed that aspect). If you are getting some parts out as 100%k that is just down to your driver interpreting the RGB. Some drivers are good at this, and may include an option to treat black as k only (or even all greys as k only). Check your driver to see. The file makeup will also affect things, but if everything is defined using only the k slider then it should be fine. The only way to send actual CMYK values to a printer is to export first to pdf and print from elsewhere, like Adobe Reader.

@m8thy are you printing directly from Affinity or exporting the file and printing from a different app?

If you use the actual picker tool (select it from the tool menu, not the colour window) and then without having any object selected click on part of your text you should see the colour values as they are being drawn on screen - so it will take into account any layer opacity etc.

Use the colour picker tool - the layer of that text must have something altering it's colour (maybe just lower opacity). The picker will give you the displayed colour rather than the base colour of the object.

You are as you have discovered free to block the screen recording permission. Problem solved. I don't think it records anything in any case, just a frame buffer to pick the colour value from. Turn the permission on and monitor you disc use/network traffic. Pretty sure you will not see anything happening.

Ha, yeah if you have a window from another app in the background you can pick colours from it for example. So affinity needs to "see" the full contents of your screen.

It's for the colour picker function from what I understand. Just don't pick colours from your bank login

I'd like to see this too. In the mean time, if you don't already know the hidden shortcut to change the units - right click the corner where the two rulers meet.

The SVG support in Affinity is the bare minimum right now and is a bit scrappy, maybe it will get some polish in the future.

https://jakearchibald.github.io/svgomg/ This does a very good job of optimising SVG files.

@v_kyr interesting insight, MacOS isn't something I've ever developed for. Given what you've said, what does the "JIT" mentioned by Patrick refer to? Is it possible to include a library as a source (or some intermediate form) and have it compiled to the target architecture at run time? Can't imagine what JIT would mean unless it's along those lines.

I'm not 100% on this, but generally "JIT" in computing means that there is some form of compilation of the "code" immediately prior to execution. In Java for example you would distribute a byte-code package that is then compiled at run time to the target system (allows one code base to run on any system). If that's something along the lines of what is happening here, then I can understand the security check - the app contents need checking to ensure that nothing out of place is there, as it's not a "fixed" piece of software, but is built on the fly. I'm not sure how Apple could mitigate this, if at all. Other apps are pre-compiled to the destination architecture so don't have anything that requires this security check. Just my guesses based on some prior use of JIT code, not saying this is any any way correct though.

There was a passenger aircraft once that during testing happily lifted the landing gear if the button was pressed whilst sitting on the ground. Should that have been left as it was and gone into commercial service? Maybe the help file just needs updating to state the program will crash if the wrong objects are selected...

Well, we used to be able to have a preference lol

Good point, I don't use anything other than Acrobat Reader and didn't realise there are others that ignore the colour management. The pdf spec requires a "conforming reader" to properly respect the profiles, yet having tested the embedded viewers in a few browsers they clearly don't. Colour is a can of worms!

Try here: https://www.epson.eu/en/viewcon/corporatesite/cms/index/10471 Edit - not sure if your model is on there actually. A bit of Googling though and you should find profiles available. If the manufacturer doesn't do them, have a look at paper brands - you might find they have profiles specific to the printer with their photo paper.

Generally speaking the printer / paper manufacturer makes the profiles available for download (will be a .icc file). You then install that to the OS (not sure of the specifics of this on MacOS). Once installed the profiles will then show up in Affinity for soft proof etc.

This is pretty much what pdf files are intended for, if your users are happy to receive them in that format. Even if you rasterise the whole document so it's essentially just an image, you'll still benefit from the colour management of the file/reader.

@Develli you're not the only one to struggle with this confusing aspect of the UI...

I just use Adobe Reader, I don't really print photos but I would imagine it will work just as well for those embedded in a pdf. It's robust and handles colour profiles correctly.

There are bugs and issues, it's often not straightforward. Printing functionality is only basic, it's all handed off to the OS. You are better off printing from a different app, there's little to gain from trying to get it to work and paper and ink will get wasted.

On the swatch/colour panel there is a small padlock icon - turn this off (whilst having nothing selected) and then when you select an element the colour panel will change to match the colour space that element is defined in. There is a "but..." (this is Affinity after all ). The colour values may not be correct in terms of how they were defined - if your colour preference defaults are not the same profile as the element was defined in then there will be a conversion in the values displayed