BofG

I'm confused now Is the problem that some files are coming out the wrong colour and others are not? Or that one half of your sheet results in a different pressed colour to the other half?

Can you share the one you actually printed from? The one you have attached is only one copy of the images and isn't set up the same as in your above screenshots.

Hmm, that is odd. If you create a new document, then paste in the "good" side from your existing one and duplicate it and try that it would rule out any odd file setup issue. If the sheet prior to pressing looks fine though I've no idea how it can produce different outcomes. The soft proofing etc isn't going to help in this instance, your print setup looks fine.

If the printed sheet looked uniform, then it's unlikely to be print settings or file setup. I would imagine that the second mug was pressed at a different temperature to the first - either hotter because the press continued to warm up, or cooler because the first mug took the heat out. The temp can, I believe, affect the colours. I'd try another run, give some time between pressing.

In that case, two questions spring to mind: 1: When the sheet came out of the printer, was it noticeably different on one half? 2: Did you press the second mug immediately after the first one?

Are you saying you printed a single sheet, and one pressed mug came out fine and one came out dark? Or do you mean they were both printed on the same type of sheet?

Check for paragraph spacing. If you have a hard return the lines are treated as paragraphs. You can get a soft return using shift+return.

Get the free trial, I think it was recently extended to 90 days.

I think that you just have an image that hits the limitations of the jpeg format. With only 8 bits to represent the colours with, there's just not enough data there to produce that smooth transition, which is worsened by the compression technique of the format. I know there is the lossy/non lossy compression difference, but even at 100% quality the jpeg is only around 1/10th the file size of a full quality png - usually you can "throw away" a lot of pixel information and not notice it, but with this image that's not the case. If you want to see the details, you need the details to be in the file :)

Random thought, when you process the raw image initially, can you choose a non-linear profile? 8bit images benefit from a curved tone reproduction curve as it packs more steps into the data at the dark end of the image. Just wondering if starting out with a "gamma" type profile might help when it's later packed into 8bit. I don't have Photo myself to experiment with.

Part of the problem is the jpeg format is limited to 8bit, so you get less "steps" between colours, hence some banding. Technically sRGB should have less banding than the Adobe RGB, as it has less range to fit into that 8bit space. I'm not too sure what you can do if anything, presumably you are exporting to 100% quality in jpeg? Hopefully someone with more knowledge on these things will help.

What colour profile are you using on export to jpeg? Your English is better than most native speakers

Those options only apply to raster (pixel based) elements or effects. Vector elements can be scaled without affecting their appearance, so they don't need any special processing. Whether those options have an effect will depend on the contents of your document.

There's no resampling of vector based content (like actual text).

A sensible first step would be to turn off all of those "adjustment" and "correction" settings (along with the descreen and unsharp) and see what the raw output is like.

Up/Down arrow keys on the keyboard also work if you don't have a scroll wheel (trackball user here :) )

From what I've tested it does seem to work. Given that it avoids inserting (completely unnecessary) "text span" elements, the name is somewhat confusing! 🤣

Okay, yeah that's just messed up!! If the text starts with a capital letter, it gets split into a <tspan> yet if the capital is anywhere else it's fine. There's no odd kerning or tracking. @Dan C any ideas? p.s. If you place a leading space on artistic text, the space is taken up, but the bounding box doesn't encompass it - on export to SVG the leading space is lost, yet it prevents the first capital being placed into a <tspan>.

The only way I can see to get that to happen is to format parts of the text differently (e.g. make part of it bold, or a different font size). Do you have an example affinity file?

Most of the time a "near enough" screen will do the job, but when using such a large gamut (which would be clipping as no monitor will get close to that range) it will show any issues like this. I'm not a mac user, but I found this for calibration which might help a bit: https://support.apple.com/en-gb/guide/mac-help/mchlp1109/mac If you want to do it properly you need a colorimeter/spectrophotometer that hangs on the screen to measure it. X-Rite do decent versions. Whether you need that kind of colour accuracy is another question. Unless you know for sure you need to produce a wide-gamut output I'd stick with sRGB.

It depends on your intended final output - what will it be for? That setup is a sensible default for digital work. To explain, it wasn't broken before - it's just that the colour space you had was beyond the capabilities of your monitor (or your monitor is just not well calibrated). sRGB contains less extreme colours which fall within what your monitor can display.

Create a new document in sRGB, and use those same colour values - do you see a difference in them in that?

Can you post the details of your document colour settings?

@loukash excellent detective work, I knew those ellipses were suspicious from the start @Pšenda I've tried different matte options, cannot reproduce the issue. What specific version of Designer are you both using? It looks to me like an issue with the rasterisation process not handling those layer blends properly. @GT70 it might be worth you trying the latest beta version:

Designer makes terrible SVG files. Take for example the most simple file possible: Default SVG "for export" gives: As you can see highlighted the width and height of the square are different!! It's using a matrix transform to alter the relative scale of the width/height so that those different values result in the same height and width. Positioning is done through this transform also rather than the rect having an x/y. Thankfully, there is an option to 'flatten transforms' which gives much more sensible code. Combine this with not including the viewbox, and exporting to 96dpi* should give the correct results: The document: SVG export settings: The SVG in InkScape: If you are getting the wrong size out, all you need to change is the dpi in the export box - as per the SVG spec it's up to the reading program to determine the scale (when the units are not specified, which is the case with the exports from Affinity), some make different assumptions about this.