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...)

@MEB Hi, any updates on whether this is already logged?

yeah me too... I'm on Sonoma 14.7, btw)

@MEB Thanks for logging checking! Wouldn't you also agree that it is odd that the position of the tool panel is obviously not saved/restored with the studio preset?

I noticed this in 2.5.3 but now with 2.5.5 it's still the same: I have most of my panels neatly arranged on my second monitor. Some of them are "combined", or docked together, and some of them are floating freely. the Bug: On each restart of the program, they subsequently keep getting taller. NOTE: This is at first barely noticeable as it seems to be only 1 pixel per restart. But with several restarts some of them are overlapping each other. The ones which extend to the bottom of the screen are getting their icon rows cut off. Additionally, the Tools panel also slips downward as a whole, on each restart, but much faster (ca. 10 px per restart). Saving and reloading a Studio preset only partly resolves this, as the tools position is not remembered and the rest of the panels still overlap by 1 pixel see comparison video: Bildschirmaufnahme 2024-09-04.mp4 and separate screenshots:

"regression"? – I'm not even sure this was ever fixed. For me, having all my panels undocked, it's always X, W, Y, H, R, S. Without switching personas. Tested in Publisher and Designer's own original personas. using macOS Sonoma

Thank You for pointing to the correct help page, @Hangman I know how to work with text styles, but often times it is the exact opposite way how they are created: You (creatively) play around with some headline/bodytext/graphical elements regarding weight, size, color, etc. and maybe scale the whole combo up or down so it uses the same relational appearance. After you (or your client) like the result of this prototype, you "cast" these different text parts into styles and begin the duller part of the work - adhering to these styles. As it is now, you would first have to "reset" (but the other way around) the text so that it sticks to its current sizes. My personal use-case is not about books. It's more like I have a brochure/folder and need to make a poster and a half page ad with the same typo+graphical elements - obviously in different sizes and aspect ratios but with the same look-and-feel. Bildschirmaufnahme 2024-07-30 um 15.46.15_1000.mp4

Oh Wow. I had this too when importing IDML files in the past. Now, with V2 2.5, we finally "see" what was happening all the time. Why did nobody ever mention this? I searched the help file but there is no explanation of "content scaling" or how you would get rid of it. So how do I "repair" all my somewhat finished documents, which many have slightly modified text styles or no styles at all, mixed inside a single text box? There better be a "override scaling BUT convert text sizes to match current appearance"-button. How would be the proper way to scale a bunch of text boxes and graphical elements to a new permanent scale?

walt is right. the difference (if you're used to InDesign) is that the warning is only briefly displayed to indicate that it has already been automatically converted. When instead the same setting in InDesign lets you choose (e.g. ID: "and ask" instead of AfDes: "and warn")

Seriously, I reordered the panels in each app and additionally saved them as studio setups just to be sure. But they still keep overlapping after reopening the app. And when I reload the (corrected) studio setup nothing changes. There must be something off.

Today I saw a newer post by @srg regarding this issue but decided to instead reply to this original one as it already has two Bug tags on it: APL-1434 and AF-1159 (which was already reported in April of 2023) Affinity, please get to it. I just realized I _mentally_ put on my heat gloves when handling affinity apps in these scenarios.