BofG

Getting back on topic... Have you seen the ICC documentation for GS? > https://www.ghostscript.com/doc/current/GS9_Color_Management.pdf A quick look shows it has the flag: -dUsePDFX3Profile = 1 "If this option is included in the command line, source device color values (e.g DeviceCMYK, DeviceRGB, or DeviceGray) that match the color model of the output intent will be interpreted to be in the output intent color space. In addition, if the output devicecolor model matches the output intent color model, then the destination ICC profile will be the output intent ICC profile." (no idea why it's referencing only x/3 as I'm sure all the x/ variants specify the output intent. There is also an additional flag to separately set an output profile: -sPostRenderProfile = my_postrender_profile.icc In theory I think it should be possible to get fully accurate output.

Given how well Affinity handles boolean operations it's probably a blessing that it gives up and rasterises these things

The post you linked to is about the displayed values not immediately updating when changing the colour selector. Nothing to do with what you are seeing... The issue you are seeing is that you are using non-colour managed online tools and expecting them to match a colour managed environment in Affinity. Convert your document colour profile and you will get different numbers again. The profile is what defines what the numbers mean, without knowing both the rgb and the cmyk specific profiles all you have are "rough" numbers.

Yep, this is a missing feature. There should be a swatch that preserves black, or an option when converting to map 0,0,0 rgb to 100k. The best you can do now is define a spot colour of 100k and use that, it will survive conversion. It does then result in an extra channel on export to pdf, but any RIP/prepress should be able to handle that and shift it onto the K plate.

@PaulWilliamson when going from one colour space to another (like here where you are going from RGB > CMYK) there is no option to assign, you can only convert hence those options are disabled.

Surpised that it only has one download.. (I will be adding to the tally when I have time to look at it), maybe this is why there aren't a lot of options out there! Looks like a good tool you have put together, I can see it being useful. Is there any way with ghostscript to see what the profile/type of colour setup the pdf is? Like in Reader where it shows the pdf is /x and output intent profile?

Completely agree! Just seems so odd aligning things first to where you don't want them before you can choose the option you want.

Click anything other than 'distribute' and you'll get the 'align to' options active.

You have to pick an alignment first, then those options become available. It used to be possible to set the option first then pick the alignment, but for some unknown reason they decided to enforce this approach.

I was looking for a way to get the bounding boxes of every element on a given layer, couldn't find any libraries that made such a task simple. Most are geared towards creation or editing. I then started reading the PDF specification document, and quickly realised two things 1) it was beyond my ability and 2) why all these tools / libraries are so expensive For compositing the tiffs, maybe ImageMagick could be useful? If you are running on a server, you could then produce the composite images (C|C+M|C+Y etc) and have some simple javascript to toggle them in the browser rather than needing a pdf viewer. I'm expanding the scope of your project, I should be in management

I see, sounds like a good plan. I guess the overall complexity puts people off trying, I've read some of the docs for PDF and it's a complex beast, add in the ICC possibilities and it rapidly gets daunting. I shall be interested to see it when you get something up and running.

Have you seen that the Ghost Script pdf parser is actually written in PostScript? I thought that was quite neat, almost turing-complete Sadly I don't have any working knowledge of PostScript

In the Windows colour management settings (the one where you saw the profile details), the first tab lets you select your printer and apply a profile for it - that profile should then be used when your driver is set to ICM (I think anyway, my language skills fall far short of yours). That would then let you apply the custom profile if the driver itself doesn't allow you to specify it. As for Affinity and printing, like I say, I gave up trying and haven't missed trying to get it to work. If you are new to Affinity you've missed out on: 1. No selection of cmyk print profiles possible. Later fixed as a bug, but it then transpired that actually Affinity cannot apply a cmyk profile and it turns it back into rgb thus messing up the colours. This is not mentioned in the docs. 2. An update that made the print preview always show the red overlay as though the artwork was larger than the page size, even when it wasn't. This persisted for quite a while. 3. The latest 1.9 release making it impossible to print files that contain artboards. The printing side of things doesn't get much care and attention, and it's clearly not on their testing plan given how bugged it has been. I got through a lot of paper and toner trying to get custom profiles to work, honestly the best approach is to print from elsewhere.

You can post it to the suggestions/feedback sub forum. I would strongly recommend against holding your breath for it to be implemented though

Good suggestion! I need to work on my memory... lol

If you see my post I linked above, that is down to the use of transforms - the square has unequal sizes defined, but the scaling transform "fixes" it. Unless the reading program ignores the transform, which some do. It's poor output for sure, but "technically" correct. Flatten transforms in the export options does remove this issue. As I say, clunky and unintuitive but it's still possible.

Figma: fill-opacity="0.03" Affinity: style="fill-opacity:0.07;.." The difference being that Figma is using the property directly on the path, Affinity is setting it via CSS using the style attribute. If you change: style="fill-opacity:0.07;fill-rule:nonzero;" to fill-opacity="0.07" in the Affinity file and try that to see if it works. There's no way that I know of to force Affinity to output that way if it does work, hand editing might be your only option.

Is there no option to leave the file as it is and use the RIP to remove the K channel? I'm pretty sure a RIP for garment printing will be able to handle this.

@johdum If the soft proof looks fine, and that profile works from a different application without issue, then the profile must be okay. That only leaves Affinity as the problem, why it's doing what it's doing I don't know. I've run into lots of issues printing from Affinity, now I just export to PDF and print from Adobe Reader. It's saved me lots of hassle. @AlainP There are ways to get the settings wrong, but with ICM turned off at the driver (as is the case here), or set to application manages colour, the Windows ICM does not get invoked at all. Windows only steps in when the driver or application requests it.

I can't see anything wrong with your set up, Affinity can use RGB profiles which yours is so there's nothing that stands out as being wrong. If you add a soft proof adjustment layer with that profile (as the first layer in the layer panel), does it show the same as it printed? My personal experience is that the colour management for print from Affinity isn't that great, although I've not see it as bad as you have there. As you have seen that you can print correctly from another application, it might save you a lot of wasted paper, ink and time to just go that route rather than try to make Affinity work for you.

The most recent update has a small bug, when exporting to jpeg etc it shows "Affinity" as the file type in the save window, it doesn't affect the actual output though, you still get a jpeg.

I do see your point, it's far from intuitive to get the correct size out. The other side of that though is that this is a "artistic" focused application, not a CAD one, hence why I see that as a feature to be added and not a bug right now. SVG is primarily a graphics format, and it's scalable as the name suggests, so for artistic use the output size doesn't matter. Trying to run CAM from it is certainly a "fun" thing to do though

Can you view the details of the ICM profile to see whether it is defined as RGB or as CMYK?

I must be dim, I never realised those top level headings were links with info. Always just picked the relevant sub forum link

Maybe that should be a sticky, it wouldn't hurt to say that read and take things on board but don't engage here.