loukash

Of course, that's a must. Also, avoid any transparencies, those convert to CMYK. Overprint works, aside from some bugs with gradient fills. Nah: Always check the Affinity forums for any possible known bugs before sending file to print…

In an Adobe/Quark workflow, you'd go with duo/tri/quadtone EPS images created in PS. That was a no-brainer since the 1990s. But Affinity cannot understand duotone EPS. A while ago I made another APu exercise from scratch with tritone: You can use Multiply blend modes on the overprint layers for preview, then set to Passthrough on PDF export. PDF/X-3 exports works alright: It needs quite some tweaking compared to the relatively seamless InDesign/Photoshop EPS duotone workflow, but for small jobs it's manageable if the result is worth it.

Good ole oldschool duotone workflow! More on that here: … where I have rebuilt one of my "antique" QXP duotone layouts in Affinity as an "exercise". Nice. Looks familiar to me for sure. I should finally scan my covers for an underground magazine I did in the early 1990s.

Their size will vary from a few MB to many GB per Affinity app, depending on how many assets, custom brushes or what else you've loaded via the respective panels. Globally, you can save quite a few GB by deleting all language localization bundles (*.lproj) that you wouldn't use anyway. ingmarstein.github.io/Monolingual Make sure to read the instructions first. It's no rocket science but it's important to understand what will happen before you take action. Also make sure to have a full Time Machine backup or an external bootable drive clone before you proceed. In my case, keeping only English, German (and Czech) localizations, Monolingual always strips over 100 MB of redundant localization bundles from each Affinity app alone. Starting with Catalina, the system and many default Apple apps are locked from editing, so there will be less saved space than on earlier MacOS versions. It's still somewhat possible messing with files in the "forbidden zone" for the intrepid tinkerers (like yours truly ) when logging in as root from a separate bootable partition, but don't try this at home!

I don't remember, I haven't used the early Affinity versions very often, particularly as long as they only allowed embedded images which is something I don't like. And I, for one, am happy that it doesn't open a different app on double click. That's a behavior that I definitely don't appreciate either.

… the relevant bit likely being this though:

Sure, but there should be one place with all available commands collected, and that's the main menubar. And even the menubar should be "contextual" in that any unavailable or non-applicable commands are grayed out. (Serif, are you reading this?!) Of course, with more functionality the menubar gets too busy. That's obviously why Schmadobe eventually added user configurable menu sets. And I was very happy about that!

Double-click a picture frame to select the child object. There's your Edit Image button.

JPEG compression disabled on export? I think you'd have to adjust the image size/resolution to 100%, matching the document's "DPI" value. Just posted something similar earlier today:

Frankly, I'm not much of a "context menu" and "right-click" guy. I'm with Apple's original Human Interface Guidelines on this one: Functions shouldn't be accessible from context menus only. Those were originally meant – as the word "context" suggests! – as an alternative way to access the regular menu commands. Not that Apple themselves cares much about Human Interface Guidelines these days though…

That I know…

Thinking of some more: With this possibility, Affinity's Master Pages are in fact something like "master layers on stereoids"! For me, this now solves all issues I was still having while thinking about a bunch of upcoming layout jobs to transfer from my InDesign templates.

That's news even to me, being "well hidden" as an obscure context menu entry when right-clicking on a page thumbnail in the Pages panel…

Wenn es MB Air M1 sein soll, dann mit 512 GB. Keine Frage. Da du nachträglich keine Möglichkeit zum "Upgrade" hast, würdest du später höchtens bereuen, dass du nicht die paar hundert Euro mehr investiert hast. Ein Freund von mir – auch Grafiker – ärgert sich bereits seit ein paar Jahren, dass er "sparen" wollte und in ein MacBook mit nur 128 GB SSD investierte. Immerhin, für sein altes Modell gibt es offenbar grössere SSD zum Nachrüsten, aber er kann es nicht selber machen. (Und ich kann ihm aktuell nicht mal helfen, weil ich in CH, er in CZ, und die Grenzen aus "aktuellem Anlass" immer noch teilweise "dicht"…) Also muss er womöglich noch mehr für den Einbau ausgeben, als er damals "gespart" hat.

If you have Designer, you can convert any object, incl. pixel/image/adjustment/etc. layers to a symbol. Switch back to Photo, duplicate the Symbol container as many times you need and adjust its linking options as you see fit. The symbol's child layers are automatically linked to "transform", so you can edit one with the Move tool or the Transform panel and the other ones will follow. Move any other layer/object into the Symbol container and it will be automatically duplicated in all other linked symbols. Example from an earlier thread: ade_aph_apu_linked_symbols.mp4

The largest you can afford! Depending on what you're working on, it will fill up quickly. And you won't be able to upgrade it. I'm using a MacBook Pro mid-2012 that originally came with a 750 GB spinning drive. That was still a model with user replaceable components, so meanwhile it has a high quality 2 TB SSD drive inside. And I also have a vast collection of external drives for backups and "outsourced" file archives that don't require immediate access. One archive USB disc being attached to my Time Capsule, so it's always accessible in my LAN. Beside design work, I also occasionally do audio editing and mastering for a living, so free drive space vanishes very fast… The "guys from <insert your local Mac dealer>" usually don't have a clue.

That would require scripting support in Affinity. There's none. On Mac, all you can do is scripting via AppleScript's System Events a.k.a. MacOS accessibility features. Or an external macro utility like Keyboard Maestro. That works to a certain degree, as long you're only executing menu commands and UI mouse clicks. Example: Automator and AppleScript workflows can be saved as "droplets", i.e. as small apps. So whichever Affinity function can be accessed via System Events, it can also be in a droplet. In theory and on a quick check with the Accessibility Inspector utility, it seems to be possible to launch an APh macro by scripting a click into the floating Library panel. So it could even work via a droplet.

We're all eagerly waiting for this feature to be added! The hopes are on the "mythical" but eventually-to-happen Affinity v2.0, but you better don't hold your breath. Meanwhile, I'm still using Illustrator CS5 for such tasks, then copying the vector paths to Designer/Publisher for further editing. As long as AI runs on my Mac, no problem with that workflow.

Of course. Usually you would want to go with 1200 ppi. Hence the downsampling problem on PDF export: you may need to downsample all regular composite images to ±300 ppi in advance before placing them in your layout, or rasterize them in place to match the document's 300 ppi setting as the last step before exporting. Also, we can't work around the default "JPEG compression" on PDF export. It must be disabled, else trouble. These are all workarounds. If you have many 1-bit images in many documents to handle, it will be a p.i.t.a. (pain in the arm). But if you just need to use the 1-bit workflow occasionally, it's manageable. Also, sometimes it's worth to convert a 1-bit image to vector straight away; all problems solved. You can't automate that in Affinity yet – only by redrawing it manually – but there's a plenty of affordable 3rd party solutions to vectorize bitmap.

No veď čeština je len volaké západoslovenské nárečie…

A quick example for illustration: Also keep an eye on the resolution and on the XY positions of both the picture frame and the placed image. Make sure they are integer pixel values to avoid antialiasing on PDF export. But that's another (sad) story…

Export as palettized b/w PNG instead. It will be a true 1-bit image. You can then place and colorize it as if it were a 1-bit TIFF. On Mac, you can also use the built-in Preview app to convert the PNG to 1-bit TIFF if you wish, but it will often only increase the file size without much benefit. For Affinity apps, it doesn't make a difference anyway, they are fine with placed PNG. More on that in the following thread, starting here and continuing on the next pages: In fact, you can colorize any placed image by using the "K Only" option button in the context toolbar. Works nicely with CMYK images if you use just the K channel. Works even with RGB images: the K channel will be converted on the fly, albeit just as a "rich black" approximation, so you'll end up with a paler tint of the applied color. So, to create a "pseudo-1-bit" TIFF in Photo: convert RGB image to CMYK add an adjustment to make it grayscale, e.g. Levels in "Gray" mode add Threshold adjustment, adjust the "1-bit" look flatten all layers; you will now have a C100 M100 Y100 K100 pixel layer in Channels panel, clear the CMY channels content, they are now just duplicates of K export as CMYK TIFF, optionally check "resample: nearest neighbor" to be on the safe side, avoiding any antialiasing glitches You have now a "de facto 1-bit" TIFF, with the CMY channels being blank. Place in APu/ADe/APh, colorize with K Only active, behaves exactly the same as "de iure" 1-bit TIFF. ^ Edit: Forgot to mention that PDF export still remains a problem, however. Unfortunately Affinity lacks the export options how to handle 1-bit images separately, so you must disable downsampling and JPEG compression on PDF export to keep the 1-bit appearance intact. There's no way to work around that, as far as I can tell, without resorting e.g. to Acrobat to downsample any placed regular images in an extra step.

+1! +2! Unless it's a workflow you'd be using unchanged like 20 times a day, every day, more often than not it's not really worth the hassle to even record a macro because too many variables can change from task to task. To me this whole "macro" feature still feels more like a marketing gimmick, just to have "✓ Macros" in the Full Feature List.

Po pravdě řečeno jsem Čech. Slovenčinu znam skôr pasívne… To jsem tak nějak tušil, že v tomto asi bude ten rozdíl.

@lightlin, recommended reading from forum.affinity.serif.com/index.php?/forum/52-feature-requests-suggestions: Emphasis in red mine.