BofG

That's the "memory pressure". I think it's safe to assume that this memory efficiency measure serves no real purpose given that no one has any idea what it is

It's the memory though, not CPU usage. It might be some measure of compression? Does it show a lower percentage when dealing with a compressed jpeg versus a RAW file?

I love the help description: "how well Affinity Photo is dealing with redundancy in its internal representation of open documents" There's no details on what the internal representation is, or what in there can be considered redundant. Maybe the app is creating the redundant data in the first place If I was coding a score for how well my own app was doing I'm sure I'd make it start at a million percent and go up from there

Did you use the corner tool with those? Depending on the usage, you might be able to just leave the file alone and set the resolution on export.

I'm not at a computer so I can't check, but look for the following: Any layers using a blend mode Any layers using layer effects (will have a small "fx" icon on the layer) Vector brushes being used (most are actually bitmap based) Those things can cause rasterisation and result in the svg just being basically a wrapper for a bitmap image.

I don't have either program, but I would think those profiles must be what is being used to render the image preview. As @walt.farrell said, there's no profile for the RAW data, but you do need a profile to render it.

All printers are CMYK (or CMYK + additional). It is indeed a smaller gamut than any RGB space so there will be some clipping/compression depending on the image colours used.

Hmm, there's no such thing as a HSL working colour space. If your document is sRGB then that is your colour space, the HSL values in the colour picker are just calculated from there as representations of said sRGB. You are already setting the colours in RGB, regardless of whether those sliders show HSL or RGB. When you say the colours are off in printing, what are you comparing them to?

Either take a copy of the curves you want to offset and combine them into a single curve, and then use the expand stroke on those, or download the beta version which has an offset function (I haven't used it so no idea how good it is).

As someone without an "artist's eye", whenever I need to draw something that exists in the real world I first take a photo of it, positioned how I want it in the image. Then drop that photo in as a locked layer, select the pen tool with a stroke only and no fill (so it doesn't cover the underlying image), then set about copying the photo in the "style" I want.

You need to use the same profile for the export to pdf that you have the document set in. Another option is to set the black as a spot colour.

Good to know, thought I'd mention it in case the OP was still on <= 1.8.3

Not sure if the latest release has fixed it, but there was also a bug where you could select lock elements by clicking and dragging a selection over them.

Yup, proprietary and closed file format sadly.

All I know is what I read from that other thread. I don't know whether they simply strip the profile and take what's there as device cmyk, or whether there is a conversion involved. sRGB seemed to be the "least worst" option in terms of being able to see what you will get.

This thread might be useful to you: The general consensus was that KDP is not colour managed at all, so the easiest and most consistent approach would be to use an sRGB document and have the images in that same colour space, then export to the pdf version that KDP asks for.

In your new document, which gives you the correct white, what is shown for the colour profile? I don't mean the defaults that you posted, I mean the document property > colour tab. When you open the png/jpeg, what does the document colour tab show for those?

Yes they do There are two images, both plain white squares. You cannot see them as the forum background is white.

I think some do and some don't, some only have them available in the driver without installing to the OS, so the application will not see it. If anyone ever writes a decent printer driver I suspect the world might end, which is why they all try so hard to make them terrible.

@Chris26 I see, I had read your first reply in the context of the original question, where the OP said they have no printer profile to use, as such test images won't help. I then got a bit carried away with my extreme negligence example

Surely the only thing you can learn from that is whether your printer matches your screen, nothing about whether either is colour accurate. If they don't match then you still know nothing, as it could be either one or indeed both that are inaccurate. Here's an extreme example, I have a printer that has run out of colour ink and so is printing only in black, and an old black and white screen. Now when I view the print out against the screen I see that it's all perfect You need at least one known good quantity (ie profiled against a defined and consistent data), and proper viewing conditions, to make any kind of qualitative comparison. It is possible to simply make your screen and printer match each other, but then what happens when your printer eventually needs replacing? Your whole library of carefully adjusted images now needs completely redoing.

If the document is rgb, then it can contain colours that a printer cannot physically produce, but the monitor can. Using a cmyk soft proof will at least show roughly how these colours will render to the printed page. If the OP's document is already in a cmyk colour space then there's not much point, as the profile won't be specific to their printer & paper so it won't be any more accurate than what will already be displayed on screen.

@walt.farrell a printer specific profile for that Epson would probably be rgb, but as the OP doesn't have a specific profile then the next best thing is a "generic" coated cmyk one for soft proofing against an RGB document.

You could use any of the "coated cmyk" type profiles, but to be honest you aren't going to gain much from it in terms of colour accuracy, the best you'll get is a very rough idea versus rgb, if that is what your document is.

I think it's the alt key that forces it to ignore snapping, I forget the exact keys but if you read the tooltip at the bottom of the screen it tells you which keys do it. You can click & drag duplicate with snapping, it's just a different key modifier.