BofG

If you have a calibration device that can read the ambient light levels, it's possible to adjust screen brightness to match and you then get pretty accurate viewing. It can take a bit of getting used to as most screens default to high brightness levels, so that's what most people see as normal, even though it's usually way too bright for accuracy. I'd be interested to know which profile you opt for, and on what criteria you select it.

I'd go sRGB and put a soft proof on from the get go. The thing is that CMYK on a screen looks worse than it does on real paper output. You don't get the same reflectance, diffusion etc. so it always looks "flatter" on screen. If you opt for a CMYK document, then you straight away compromise whatever you produce for use on screen, if you go for RGB then at least you are fully in control of the compromises that are made between screen and print.

Oddly the nozzle check looks fine though, slight reflections on the black channel but nothing too bad. It's clearly the magenta not working on the actual print, and given it was showing as empty then maybe it's a defective cartridge. Do you have a spare new one to put in?

Nozzle checks look fine, which is good news. So it's either genuinely out of magenta, or as @firstdefence said it's a bad contact with the cartridge chip. Try refitting it and see.

Do this: https://files.support.epson.com/docid/cpd5/cpd53888/source/printers/source/ink_functions/tasks/wf7710_7720/checking_nozzles_lcd_wf7710_7720.html Take a photo of what comes out and post it here.

If you have genuinely not changed anything on your software, then it's likely a hardware issue. I'd say it looks like maybe your magenta channel not firing. Have you run a nozzle check?

It could be down to the images getting assigned a different profile when you put them in your Publisher document. The "press ready" default doesn't convert image colour spaces by default so if they were getting altered they would stay that way. I would say it's definitely profile related as that handles the ink limits, so it's either incorrect assignment on the way in or on the way out (or both).

What ICC profile was the InDesign document set to? What profile did you use on export? Does your Publisher setup use the exact same profiles as you tested in InDesign?

Is the issue that you are not getting the colours you expected, or is it lines in the printed output? Is the issue only on your office printers or also on the output you've had back from a print shop?

If you don't know what profile the printers will use, or if your document is in RGB, then you could set up a spot colour as 100%k for those elements. That would survive profile changes. If you have your document already set up in CMYK already, then you can "assign" the profile when told by the printer which one, and then output in pdf/x. Without knowing what your document is set up like it's hard to give more detail.

What colour mode is your document? Are you exporting this and need to preserve it in the export? If so, what format are you exporting to?

I'm going to assume these should be "Ellipse". Although I guess you could argue the "Crescent" tool is an eclipse of sorts

If there's no CLI to do what you need, you might be able to still do it using something like Auto HotKey. It would be a bit of a fudge, but technically you can programmatically do anything in AP and the host OS that you want to.

No, but the beta checks for a valid install (either app store or direct version) in order to activate.

As you don't know who will be printing your files or on what device, you should just keep to sRGB. Any CMYK space will be "smaller" than your original, and they are not all equal, so if you pick one and the customer then has it printed somewhere that uses a different profile there will be further loss of colour compared to the original.

This is something that could be easily offered by Serif. All they have to do is provide the older version in the same way that they do the beta.

Just stick with the default sRGB as in the "For print" templates you highlighted. There's absolutely no point using CMYK if you are directly printing to your printer as Affinity doesn't support sending CMYK print data.

I see, it's just a limitation of the scheme. Have you tried looking at the L,a,b - the lightness (L) might give you a better reading. This will be calculated through whatever profile you have your document in so bear in mind if you are trying to compare between images.

I think I've got my head around the HSL scheme, I'm not quite sure though what part of it you are referring to as the issue. Can you dumb it down for me?

The values here for min & max in HSL are defined as [0,1]. Having max as 2 in your example is out of range. I've not read fully through the rest yet, interesting topic though.

If the SVG has the fill-rule defined as non-zero then why should Affinity discard that? Just because in this case you wanted the inner curve unfilled doesn't mean that's the correct way. If the SVG was one where it needed to be set to non-zero to display as intended then discarding that would break it. I'd be interested to see what Illustrator/Corel do when the non-zero rule is needed to be preserved - do they still discard it?

The profile has already taken these properties into account. Converting between profiles doesn't require any further measurement.

I think little cms is what Affinity actually uses under the hood.

For proper conversion, you need to be able to read ICC profiles. They are essentially look up tables, to go to/from CIE Lab or CIE xyz. Trouble is they are not plain text, so you need to know the encoding details: http://www.color.org/icc34.pdf There are some code libraries out there, one called Argyll cms seems to be quite popular. Their website is like travelling back to 1990, but it has a lot of technical information on it.

The worring thing is it still took me ages to spot that!! How technical are you? It's a pretty deep rabbit hole....