Andreas Scherer

Page 303: “EINFÜHRUNG” has a double-G.

On page 362, two entries in the table have excess text: BegrenzungenFarben & Verläufe HilfslinienSymbole that should be deleted.

Place a picture frame on the master page and a text frame with the page number on top. Then you can populate the picture frame on each page with individual images.

This seems to be ambiguous. Google claims that SF Pro is the system font for macOS, but my Mini doesn't have this. Then Google claims that Big Sur has Helvetica Neue as system font, but this doesn't have the symbol; the error reappears. I'll stick with Apple Symbols. Edit: Lucida Grande also works fine (even at identical font size).

That would be overkill for the small text at hand. Instead, I simply select the five symbols and change the font.

Thanks, I use Apple Symbol with a slightly larger size (30pt vs 24pt) to match the text font.

Inserting the ⌘ symbol from the Emoji&Symbols menue doesn't play well with the APub checklist. Each occurrence of ⌘ is marked in red. How do I get rid of this error message in preflight?

The APub manual for text on a path should mention this extended functionality more prominently. There is a short sentence in paragraph ”To create path text“ (without a link to the Text Frame panel), but the AD/APh text about the discarded original object (which it is not in APub) comes much earlier in this page.

It appears that AD and APh automatically make the form transparent when you add text on the path. However, APub retains the fill colour of the form. So, in order to achieve the desired effect in APub, you could start with an ellipse (form tool in the left column; click on the little triangle to choose from predefined forms). Create it with the mouse to your liking (you can change its size later). Choose “no filling” for its body colour. Now switch to the art text tool and click on the ellipse (slightly outside or inside; cursor shows ”T with wave”). In the tool bar set your choice of text colour. Then type your text. See also this discussion I do agree that APub's behaviour should match AD and APh in this respect.

Saal Digital seems to request spreads: »Es ist wichtig, dass wir im PDF jede Doppelseite als eine Seite erhalten.« Blurb requires individual pages: »Wählen Sie für Ihre Seiten die Option Bereich: Alle Seiten.«

Um deine allgemeine Frage aus dem Thread-Titel zu beantworten: Jede meiner Kameras bekommt eigene SD-Karten, die ich – auch wenn sie voll sind – nicht wiederverwende, sondern in Kartenboxen archiviere Mit den Sony-Kameras habe ich für jedes »Thema« einen eigenen Ordner auf der Memorycard angelegt; mit den Lumix-Kameras mache ich täglich einen »Number Reset« (erst neuere Lumix-Kameras haben eine etwas komfortablere Speicherverwaltung, wo man zwischen den Ordnern wechseln kann) Mit dem Programm »unison« übertrage ich die (neuen) Daten von der Speicherkarte auf den Linux-Laptop, wo für jede Kamera und jede Speicherkarte eigene Unterordner angelegt sind Als »Einstiegspunkt« pflege ich eine HTML-Seite, wo Kamera, Karte, Datum und Themen der Unterordner beschrieben sind Das Bildarchiv des Laptops wird auf mindestens zwei externen SSD-Platten gesichert JPEG-Bilder von den Sony-Kameras bearbeite ich in Gimp, selten in APh RAW-Bilder von den Lumix-Kameras bearbeite ich in Rawtherapee; die exportierten JPEG-Bilder und die Sidecar-Dateien landen vom Laptop auf den externen SSD-Platten, nicht jedoch auf den SD-Karten in den Kameras Projekte in AD und APub, die Bildmaterial aus dem Gesamtarchiv benötigen, erhalten einen »Material«-Unterordner mit Kopien; »Nachbelichtungen« – also neue/veränderte Sidecar-Dateien und exportierte JPEG-Dateien – werden im Gesamtarchiv einsortiert Soviel zum Thema »umständlich«. 🙄🤔

https://support.omnigroup.com/reinstall-mas-purchase/

Sorry for the delay, I was afk. @GarryP: The AD document does not contain snapshots nor do I save the history with it. Unfortunately, I can neither share the original AD document nor the bitmap file (which is, in fact, a jpeg file, not png). However, I can almost reproduce the effect with the simplified outline file circles.afdesign (518 KB) and the jpeg file wall.jpg (487 KB). When I place wall.jpg on each of the circles as a bitmap filling, the AD file becomes more than 50 MB in size. Undoing the overlays (cmd+z) restores the original file size (half a MB). Deleting the overlayed objects and recreating the non-overlayed circles and saving as a new file results in a file size of 5.1 MB. @Callum: Copy/pasting the 7 artboards into a new file results in an almost restored file size of 988 KB, so it seems to be purged of the overlay information. Thanks for the hint. circles.afdesign

In my case this does not work. File size with Artboard 8: “41 MB”. Delete Artboard 8 and “Save As” gives file size “39.4 MB”.

I am working on a single AD project with currently 7 artboards with sketches of forms and curves (linked as symbols). Its file size is reported in macOS Finder as “939 KB”. Now I am adding an 8th artboard with a similar sketch and use a 1200px x 1200px png image to add as “bitmap” fill of the individual curves (about a dozen objects). This increases the file size to “40.9 MB”. Even after deleting the 8th artboard and saving the file (and closing AD) the file size stays at the humungus value. Is there a way – other than pulling from backup – to purge the AD file of the intermediate stuff completely?

Side note: For the time being, it seems I'm one Affinity user who hasn't encountered file corruption with any of the three apps (versions 1.8.4 to 1.10.5) on any of the Mac Minis in use. Fingers crossed! 🤓 For quite some time I've been using single Affinity Designer project files with multiple artboards, but I've tried the “history” feature just today. Obviously, its interface is far from being comparable to a “version control system” (maybe the “snapshot panel” can be of help). Provided that the internal document structure is in one form or another “text-based” (XML?), it would be a nice (but major) extension to have a genuine “VCS panel“ with tagging and branching etc.

Have you tried to save your work history – with branches – within your document(s)? https://affinity.help/designer/English.lproj/index.html?page=pages/Panels/historyPanel.html?title=History panel This allows to keep a lot of the changes "active" without bloating disk usage. As @walt.farrell points out, placing large binary blobs into a VCS like Git does work, but takes up a lot of disk space. From a "hacker's" point-of-view, I'd try to keep the major work history within the project document and only place significant milestones, e.g., a customer delivery, under external version control (most likely with Git), where you can mark them with tags.

Die Katze aus den Vektorformen ist eine Vektorform. Leider sieht sie bei mir nicht so verspielt wie im Handbuch aus:

See, e.g., my recent post in a parallel thread.

The search item “Open Path” leads to “About lines, curves and shapes” and that to the “Node tool” with ample information. 😉

Have you at any time exceeded the capacities of your 2012 iMac? Are you planning to do so in the foreseeable future? In mid-2020 I started with the full Affinity 1.8.4 suite on a late-2014 Mac Mini with 8GB RAM and 256 GB HDD running macOS Catalina, which I bought used for 301€. After all the hype around the M1 processor, I replaced this machine last year with the smallest (!) M1 Mac Mini — 8 GB RAM, 256 GB SSD, macOS Big Sur —, which cost less than 600€ (and sold the old Mac Mini for 150€). The Mac Mini shares an Asus PB258Q monitor (245€ pre-owned), a Perixx keyboard and a CSL vertical mouse — both USB wired —, and a Wacom Intuos Pro S tablet with an Acer Travelmate X349 laptop running K/Ubuntu Linux 20.04 LTS with 8 GB RAM and a 256 GB SSD (absolutely no issues running Gimp, Inkscape, Rawtherapee, w.h.y.). The M1 Mac Mini is much faster than the 2014 Mac Mini: instead of dozens of seconds, cold start to login takes less than 20 seconds, the Affinity apps start in 3–5 seconds (without loading a project file), everything works absolutely smoothly. Compared to the 2017 Linux laptop I notice about double performance when compiling a non-trivial multipart C/TeX project (and compared to the 2014 Mac Mini the same terminal script runs three times faster on the M1 machine).

At first glance, there's a significant difference between Affinity Designer and Affinity Photo: In Designer, the Pen tool (P) and the Node tool (A) have two different shortcut keys, while in Photo both are mapped to (P) by default. (Affinity Publisher seems to side with Designer in this respect.) Playing with the shortcut keys I find an interesting “feature” when I try to toggle between tools by pressing the same key(s) repeatedly: All three Affinity programs seem to “remember” the origin tool and jump back to it with the shortcut key of the target tool. For example, you can toggle from the Move tool to the Pen tool with (P) and back with a second (P). Likewise, you can toggle from the Pen tool to the Move tool with (V) and also back with (V). In Affinity Designer and Publisher this is also true for the pairs Move—Node and Pen—Node when pressing the (A) shortcut key repeatedly. Of course, if you toggle into a group of related tools, you won't jump back to the origin tool. For example, in Affinity Photo, shortcut key (P) jumps from the Move to either the Pen or the Node tool, but not back to the Move tool. I couldn't find a description of this feature in the online help, so my question is: Is this behaviour of the Affinity programs intended?

You can read how the Publisher Workbook was created and watch the video how Andy merged the multitude of separate parts. IMHO, far too many manual steps, at least some form of “scripting” would be useful.

It seems that only the [ and ] without any keyboard modifiers are affected. For example, the default settings for “one layer up/down” (cmd+] and cmd+[) and “move to top/bottom layer” (shift+cmd+] and shift+cmd+[) work also with the German keyboard layout, i.e. (shift+)cmd+alt+5/6. Only alt+5/6 makes a difference. I've saved three *.affshortcuts files with the replacements for [ and ] and use these between my two Macs at home and at work. IMHO, the inline help should address this mishap (or a non-English installation should take care to replace these collisions).

This could easily be a user error, so bear with me. I'm working on Mac Mini with a keyboard model A1243 (German layout). According to the inline documentation of Affinity Photo (or the Pixel Persona in Affinity Designer), the keyboard shortcut to decrease and increase the brush size is [ and ]. This also seems to be defined in the application settings in tab “Tastenkürzel”. However, on a Mac keyboard with German layout, you have to type “Alt 5” and “Alt 6“ to get [ and ] respectively. Having received a warning beep whenever I tried to follow the help/tutorials, I changed the “Tastenkürzel“ as in the screenshot and now the keyboard shortcut works as advertised. Could this be a misconfiguration from the start? Clicking on “Serif-Standard” puts [ and ] back in.