BofG

I see, that sounds like a pain! I've not tested those tools mentioned, but check to see if they use the profiles you need, otherwise you will be getting values that aren't accurate.

Have you tried ungrouping first, so nothing is nested? Just a thought, I've not tried it myself.

Mystery solved. Embedded browser. Maybe this can be changed in the future to a native interface?

I think the key part is the "JIT" mentioned, it seems the Affinity apps are packaged in a way that requires some "Just In Time" compilation - executable instructions written at run time. Understably the Apple malware checker freaks out a bit about that * * this is all just based on my own assumptions about what has been stated. I don't know for sure about this.

That was my point, a pdf is the standard format for print work so those people wouldn't be looking to export a mm-unit svg. What specific software are you loading your svg files in to? Unless it refuses to load files defined in pixels then you should be able to work directly with the files from Affinity without having to convert them with other software first. This point about units in the export has been raised a few times before, it's on Serif's radar. I wouldn't pin your hopes on anything happening with it soon. If you have as you say loads of files that you have to work from then you just need to find the way of exporting that works. My earlier linked post might help with that.

Rather than inspecting and copy-pasting values, can you not create a custom palette to match the brand guidelines and work using that?

It's going to be painful, but you can load your svg files into Inkscape (which is free) and export from there to have your mm units. Your export settings from Affinity need to be correct to load in at the proper sizes: https://forum.affinity.serif.com/index.php?/topic/109961-export-svg-wrong-size/&do=findComment&comment=727443 In fairness to Serif, you are using the wrong tool for the job - it's a vector art package, not a CAD drafting program.

Do you still have the source documents from 2019? If so you could check the colour setup of those to see if there is some difference versus your new file.

This happens a lot when opening / creating a new document when previously working in a different one. The last tool used in the previous document shows as selected with the cursor icon for it, but it acts like the move tool (the default for a new/opened doc).

The argument made that blend modes aren't used as they are only supported via CSS is a bit weak when their current export uses css for the fill colour, stroke, font-family etc. when these are things that can be set as native properties of an SVG element.

Yep something is definitely not quite right about how it's operating. I used an RGB source document and had the same results as you did above. Proofing to an rgb profile from any source doesn't seem to work properly from what I've tried, especially from a cmyk document as it will refuse to display rgb within it. Going back to the 300% profile - what purpose does it serve if when I create a document using it I can happily export a pdf with that as the output intent, but have >300% colours within it? That has me stumped and you seem to know your stuff, hoping you can shed some light on that one.

I'm begining to think the soft proofing isn't quite right - if I have an sRGB document with the gold from their screenshot and soft proof it to v2_300, the result is pretty close to their pdf. Yet if I convert that file to that profile, the colour barely changes. The OP said they had set the document to that profile, which I read to mean they had started in a different one so was thinking a conversion had taken place. If they had started a new document in v2_300, what good would that do as it apparently doesn't limit the cmyk makeup in any case...?? I'm beginning to wish I'd decided to learn about quantum mechanics rather than colour management, would have been easier

A quick test - I created a ISO v2 document, one block 400% black, one block 300% black (75% each channel) and one 100%k. Exported to pdf-x1 ISO v2 300% perceptual. The 400% black became 300%, the 300% black became 270% and the k became four colour 272%. To me that is what I would expect - if the profile is bringing the upper bounds towards less saturation, should it not be bringing everything "in" with it - especially when perceptual intent is used? One thing I did learn, which is now confusing me, if I use a v2_300 document and create the same as above (v2_300 output intent), the pdf comes out with the original values - nothing is altered, so there is a 400% black in there. What use is the profile in this case?

That was an RGB document (I defined the objects using the CMYK sliders) I can see how my cmyk value labels could cause confusion I'm maybe misunderstanding, but from what I see that TAC is being shown as in effect on the soft proof. The more I learn about colour management the less I seem to know - how would that work? If the document is in v2_300, can I define a colour that is really 400%? Is the colour range not bound to the profile in use? I was under the impression it's down to what is set here in the prefs:

Maybe Affinity's soft-proof isn't correct, but for me I see a shift in saturation across the board using that 300% profile. It's what I would expect though (especially on the "perceptual" intent). Am I missing something?

The whole point is that you cannot, as @loukash pointed out, that profile is intended to limit the amount of ink that physically gets laid down - it's literally reducing the saturation. What colour profile is your source document in? You might be able to soft proof it and make some adjustments to get something you are happier with, but that 300% TAC limit will still be there.

Yep. He did a better job of explaining it.

You have to draw a line (of any length) first, then in the bottom right of the screen you can type in the actual desired length.

It is unlikely that a major version without any implementation bugs will be released. And instead just with older features and stability issues.

I can understand the current approach given that all the v1.x are technically available to all (although there are good reasons for avoiding the new releases). If there's no back-saving in v2 though there is the potential to reduce the practical use of their suite.

PDF will preserve most of the file "as is" unless you have things like pressure strokes. Only way to see is to try it. I'd go with the "for export" preset. It does make me wonder what Serif will do when v2 lands as a paid upgrade. I'm hoping they will have some form of export option for compatibility with the v1.x apps.

Pretty sure you can't. Only option would be to export to something like pdf to then load into the older app.

You need to have a cmyk document, and export to a pdf-x preset using the same profile as the document (I think it defaults to that). If your source document is in RGB then you will have to convert it first in the document settings, and then check (and possibly change) the colours as if they were defined in RGB they stay that way and will get converted on export which will result in four colour black again. Also, as others have mentioned it's possible your driver might not support CMYK. The only way to really know is to ensure your pdf is correct and then try it. If you can find a PostScript (PS) driver for your model that would have the best chance of working.

From the looks of it the whole thing is four-colour black, just that where it is less dense the difference shows more. Having said that, it could be that the solid black is being rendered by the driver as k only, and the less saturated areas (where thr brush "flow" isnt 100%) are turning four-colour - I've seen this happen in my testing as have others. If the document is in a cmyk colour space, you should be able to just export to one of the pdf-x presets and print from Adobe Reader. Edit - one of the users on here made a tool where you can check separations, might be worth using prior to printing to save wasting print.