Matthias

Well, Mark, then we do have a different approach here. We both want to put the designer in charge — but from opposite directions. I concede your points. What would help though is if the app would somehow memorize the originally dialed in colour values. So when the colour space would change back from a different one to the original one the colour values would jump back to what exactly one intended them to be.

… note also that there was recently another thread where people were basically requesting the opposite. They wanted the CMYK values of swatches to remain unchanged when pasting something into a document with a different color space - they were more concerned about the numbers than the actual color for some reason related to corporate standards of clients or some such. Hi fde101, I am one of those people you mention in this quote. The way I read Mark Oehlschlagers request me and him are sort of on the same page: I too would want it “easier for the designer to accurately specify and manage color with confidence” — which is why I think that CMYK values I myself have dialed in should stay true to my decision — for several reasons I have outlined. I am not sure what Mark’s wish is but I’d suppose it’s not the opposite of mine.

Thanks, Matt!

My guess: Either Publisher beta ignores image linking and embedds them anyway (the size of your publisher document would be a tell) or the pictures are somehow twice on your hard drive.

True. But I think as long as it is a colour that I have defined as a global colour it should always stay the same, regardless of the document’s colour profile. I’d also expect the according swatch to show up in the new document (which it doesn't). I’d prefer my global colour looking weird in a different colour space. Numerically (but kind of secretly) changing the actual colour values is a recipe for disaster when you have to work with people that are not so much into colour management (I’d guess it is the majority). Because once the app has benevolently changed ”my“ colour’s numerical values in order to keep it’s appearance a third party cannot ever trace it back to it’s original values (which might have been there for a reason). Whereas it’s easy to change the document’s colour profile anytime to match the intended output (or the global colour itself, provided the swatch is being copied over, too). Since numerical colour definitions (not colour appearances) are a customary thing in corporate design I am actually baffled that this is a topic that’s being discussed at all.

I think the discussion about how we don’t need user-defined compositions of colour since the printing process itself is flawed (and paper variations making it even worse) is beside the point. Yes, there are many variables that can render a colour different than intended. But that doesn't mean relying on one’s own colour definitions is superfluous. It is a necessity for reasons like rastering or tinting or overprinting or for simply passing them on.

Once an element is attributed with a defined global colour this colour swatch (including it’s colour space and according values) should be tagged to the element, regardless where you copy it. In corporate design work this is a must. Consider how this is handled in InDesign: When I need a certain defined colour in a new document I just copy an element containing this colour from a previously made document into my new document — and then maybe even erase this element. But the attached colour swatch is being copied along with the element and — Bingo! — there it is in my colour palette, ready and willing to be utilized. This makes sense even if you copy a cmyk swatch over to an rgb document for, say, web design. As it is a global colour you can simply change the swatch (and thus any element using it) to match your predefined corporate design colour in rgb colour space should you want to have control over the conversion (otherwise the app does it on the fly). A designer ultimately has to be in charge of numerically defined colour values — regardless whether the app ”thinks“ it knows better. The very idea of a global colour swatch is an expression of this paradigm. Otherwise she can always use the colour picker or mix something in the colour wheel. Defined values often have to be communicated to third parties to ensure everyone in the design process is on the same page. With the Affinity Suite — as much as I truely love it — the handling of colour swatches is confusing and should be overhauled. To reiterate: Once I, the designer, have defined a global colour “with my own hands” it’s colour values should be an attachable and thus copyable asset and must be sancrosanct in any document.

Great — may the next round begin! Thanks, Affinity. Edit: Unified toolbar looks good. Every pixel counts.

Now that Designer and Photo can open multipage Publisher documents it would be nice if page navigation were accessible via menu (probably in the ”View“ section) — thus steerable via shortcut.

That’s what I was missing! Yes, I have. Just didn’t see it (but didn’t see a description of it neither). My bad, thank you Matt.

Maybe I am missing something but when I open a multi-page Publisher document (1.7.1.399) in Designer 1.7.1 I just get to see the one page that was the last on display in Publisher.

As long as Affinity implements the functionality somewhere else this is fine with me. I think the user should be able to choose between linking and embedding images. As it can be achieved with a few clicks to Publisher and back there is already a way to keep Designer files with images small. For the time being I am happy with Affinity app hopping, too.

Of course. When they do it in Publisher you can be sure they’ll keep Designer and Photo in sync.

Not when placing a picture but only when replacing it you’ll find an option button where you can choose whether to embed the placed resource or link it (keeping Designer file size small). The UI seems to be a bit messed up and it would be great if the option also existed within the ”Place“ command in the first place. But still it is great to have the option right within Designer, thanks for that!

Why not give the vaguely named "Miscellaneous“ (in German: "Verschiedenes“ ) tab in Preferences a more descriptive name? I’d suggest "Resets" or "Defaults“ (in German “Zurücksetzen“ or “Standardeinstellungen“). Because "Miscellaneous" tells you exactly: nothing when in fact the subsumed functions are quite specific. Cheers, Matthias