woefi

When you examine these two images (for example with preview.app's info panel, press the (i) icon) you will notice that: "affinity.jpg" has a color profile (P3 D65 (Linear)) whereas the "preview.jpeg" says "generic RGB". I suspect when copying, the system wraps the image-content in the color profile of your display (p3?) and affinity tries to re-interpret this now profiled image to whatever color profile is set in affinity's app preferences. Try to change the color profile preference in affinity photo and see if this changes the pasting behaviour. scratch that. I just tried with your Pages source file. Pasting it into Pixelmator gives a png with sRGB and correct interpretation. No matter what I set my profiles in Photo to, It always creates a P3 (D65) copying from Apple apps (Pages, Numbers, Preview) always come in as P3 d65 and washed out. Inspecting the pasted graphic in preview.app says they are already p3 in the clipboard, when I then choose Tools > Assign Profile > sRGB. Copy it, then the pasted content in Affinity is correctly set to sRGB and not washed out. when copying a still from Quicktime Player it is correctly imported into Affinity with color profile "HDTV" of the video. So I would say: Affinity works correctly. It's the Apple Apps that are incorrectly assigning P3 to the pasteboard. Pixelmator always imports as sRGB no matter what the source (my video frame was HDTV and came in as sRGB...) The workaround with Apples iWork Apps would be: Paste it into Preview, assign sRGB color profile, copy it again, paste it into affinity.

Nope. absolutely not: EDIT Just to make my point clear: screenshots of indesign in the same situation (but behaving better...).

Hint to the devs - The solution to this should be (conceptually) straight forward: The purpose of _the color panel_ is for mixing together fresh colors (choose freely which color space suits best). The popup _edit existing swatch_ must be independent of the former and it has to honor the colour space the swatch was created in. ...to clarify: the problem is that Affinity's color mixer remembers and switches its colour space globally _per App_

Yes, please! I have been waiting for this since the first Publisher beta.

Oh, I apologize if I made the impression that I ridicule your choice of keyboards. 🙇‍♂️ I'm absolutely aware that there are so many different 'tastes', professionally speaking of course. If it gets the work done, it's one's weapon of choice. My point was: I was not that aware, that nowadays not everyone knows of the olden times in macintosh desktop publishing (aka the nineties) with the "Apple Extended Keyboard II" and on this topic in particular: "the key layout" which I would call the gold standard*. (Believe me, I would never start an argument about keyboard switches...) *The left and right _Shift/Ctrl/option/cmd_ corners enable the most variety of keyboard shortcuts without breaking your fingers, the numpad lets you assign various text style commands on top of that and I never successfully managed to type in numbers using this ominous upper row but do so blindly and fast on the numpad. Yes, and of course the separate Backspace and Delete keys... p.s. I would have no idea what to do with a "globe-" or "copilot"-key, or this fourth win key in the right hand corner of a pc keyboard...

Happy it now works! but now that all is golden, I absolutely HAVE TO post a picture of an "actual" mac keyboard, not a neutered laptop/mini sized one, but a real, "grown-up" keyboard for serious work: just, you know, for @walt.farrell and @NathanC to look at. (working on a laptop keyboard feels like my hands with winter gloves on...)

@NathanC Yes, but please: also relay to the devs to NOT simply "match" colours on screen, which would be dependant on colour profiles, but read the "actual" color value from memory/colour palette. This is especially important for those of us who work with CMYK colours, where the AffinityApp obviously takes the (internal) LAB value of an existing CMYK colour and converts it back to CMYK. This "roundtrip-conversion" completely alters the colours and makes it unusable in print production workflows. Example: take a "clean" yellow colour of 0/0/100/0 and _create_dokument_palette_ makes LAB L90 A-3 B86 out of it, which gives a "dirty" CMYK: 4/5/90/1.

you are correct, technically this _could_ be handled better. (at least on a Mac...) But consider this old-timer workflow (since 1994): sometimes the user (as in "me") wants to quickly swap resources by renaming the established version to, say "filename_old.xyz" and copy another version of the resource into the original folder. If you have a document with hundreds of images, this will be very fast by using a bulk-renaming tool. Compared to the technically correct way of clicking in the resource-manager for each image and selecting the new version, which could take hours. So, what I'm saying is: it depends on the user's workflow. Not sure if a setting could help some or confuse others...

I had the same issue yesterday... I'm on an intel-iMac running Sequoia. The obvious workaround is to force-quit publisher, rename the file back (or just make a copy of it with the old name) and then restart publisher so you can relink to the new file. I hope this gets addressed soon as a hot-fix.

please try my attached test-file: AfPub_Mastertest.afpub

so... any change on that? It's still not fixed as far as I see... Hey, @stokerg you commented in 2022 on this bug AF-3283...

And possibly also related to: (aka: AF-5418)?

This seems to be connected to AF-3611 (undocked Tools mysteriously moving) This is known since 2022?

ausserdem gibt es (seit v2.3 oder so) den Shortcut, dass man die Leertaste gedrückt hält, während des Ziehens. Als wenn man temporär das "lock children"-Häkchen angehakt gehabt hätte.

agree with that one! the edit colours dialog is missing many functions the create swatch dialog has (overprint for example...)