Matthias

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

There has to be some unseen feature unveiled at the live event in three days, right?

Thank you so much! Command-drag is a feasible solution for deciding-to-clone-while-dragging — though somewhat redundant: Command-drag does what Alt-drag does –only more of it. If Publisher instead would take into account the state of the Alt key after the dragging process started — just like it does now with the Command key – the Alt key alone would suffice for what now takes two different keys. As it is now Command-drag works exactly like Alt-drag in macOS Finder does. So for the sake of system wide consistency: Why not just use Alt-drag with the Cmd-drag functionality and leave the Cmd key alone (or use it for other/future purposes like e.g. initiating a symbol instance)?

Yeah, seems to be an unusual term. For me as a native German speaker so much so that I surmised you just misspelled “Tönung“ because I never saw the word "Tonung“ before (and my Mac’s autocorrection neither). So let’s get some Popcorn and see what the Affinity term for "tint" in German will turn out to be – hopefully neither “Tonung“ nor “Tönung“.