A_B_C

Again, a fantastic improvement. The team is definitely on fire at the moment. 😀

Never mind, I know it’s super difficult to do this correctly, or rather, in a visually pleasing way. You don’t even have to consider different cell border styles, it’s sufficient to consider the same border style everywhere and different row heights or column widths. So I understand that balanced strokes in tables won’t make it into version 2.1. Basically, I was just curious to see whether you already have a solution for tables. 🙂

Interestingly, I was able to create a guide just by clicking a ruler some moments ago. Now it does not happen anymore. I hope that was temperamental. It wouldn’t make sense if we could create a guide by a single click on a ruler. 😲 Here’s a video with sound, such that you hear the clicking noise. Internal trackpad of MacBook Pro 16'' 2019 Intel. Just-Click.mov

Though for tables, it doesn’t seem to work yet, or does it? 🙂

This is fantastic. 😀

I like the formatting-related part of your post, but I must confess I’m not entirely sure about the deletion-based part. I fear the option to manually delete parts of a cross-reference in the text would provide another error source. Imagine you could individually delete some digits of a page number that is part of a cross-reference. What should happen in such a case when you click Update cross-references? Should the truncated page number be completed then? Or should it be left alone? To be honest, when I click Update cross-references, I expect that all of my cross-references should become complete and correct references to whatever they refer to. The reference (target) may be incorrectly chosen, but the referring expression should be correct, no?

Ah, I see. It was just a reference problem. I wasn’t sure what you were talking about. 😀 Oh, and yes, what I forgot to mention in my suggestion above: of course, we would need to have a way to create pattern presets for cross-references. Once the user is done with creating a cross-reference pattern (expression involving variables), they would need to have the option Save Preset, just as in other parts of the application. Basically, that goes without saying. Building the pattern over and over again is not much better than building the actual cross-reference itself. That would defy the idea of a pattern. 😉 In particular, it would be helpful if we could (a) store such pattern presets with a specific document only, (b) sync these patterns across parts of a book, and also (c) store the patterns also as application presets, just as we can do with color palettes.

Unfortunately, I’m not exactly sure what you mean by that. My idea was not about slices or reading meta-data from files, but about utilizing a UI logic that is already available elsewhere in the application and works great, as far as it goes. If “Page Number”, “Section Name” etc. were available as variables that could be used for building expressions just as it is possible with the path name variables in path name expressions for slices, it would be possible to recreate many of the features that are available in the cross-references systems of applications like Indesign. Think of it from a practical perspective. As Paolo said, when you have hundreds of cross-references all of which are supposed to follow a complex pattern like See chapter <chapter number>, “<chapter title>”, on page <page number> of volume <volume number>, you will currently have to assign four (!) cross-references to create a single (!) instance of this pattern. That means, you will not end up with hundreds of cross-references, but with 4 times as much cross-references in your document. And from a practical point of view, it should be obvious that this is a pain: First off, your Cross-References Panel will become overcrowded, making navigation increasingly difficult. You will easily lose track of which entries belong to the same quadruple and represent a single instance of the cross-reference pattern above. And secondly, the current non-complex approach creates a potential error source of first rank. The reason being, that for each instance of the example pattern above you will have to check four pointers to locations in your document instead of a single one, where each of the pointers can be set independently from the others. By logic and economy alone, it should be obvious that the correctness of a complex cross-reference following the pattern above should not be a function of four independent data points. So, please, give us a variable-based system from the outset. I have the impression that the target of a cross-reference is already handled internally as a complex set of data, for otherwise the user could not switch between the “Display as …” options. But if that is the case, it should be not too difficult to expose the elements of that data set to the user in the form of variables that can be used to build complex expressions. Please consider these arguments. 😀 As a side note, it would be fantastic if each of the variables could be associated with an individual character style. This way, we could, for instance, automatically format expressions that represent chapter headings (titles) in italic style, or similar. 😀

I hope this illustration is clear enough to express my idea. 😀

“Super-fields” would come in super-handy. I wouldn’t consider those any more overwhelming to the user than the way in which custom path names are defined in the Export Persona. So I would suggest that you simply do the following: Turn the options of the “Display (cross-reference) as …” menu that is available from the Edit Cross-Reference dialog into variables and borrow the user interface from the Path Name Definition flyout in the Export Persona to let us build super-fields in the sense suggested by Paolo T. The user interface and its mechanics are already there. Why not use these things for something else that would be very useful? 😀

This is fantastic news! Thank you so much! 😀 Tiny issue, added to observations above: when panel with gets small, some button icons get distorted.

Ash, I am so very delighted to see these improvements added! Thank you so much everyone in the team, and sorry for the late reply to this announcement. 😀

Scenario: Rulers visible, Guides hidden (View > Show Guides unticked) When you simply click a ruler in this scenario (mouse-down), without dragging out a guide to the canvas, guides become visible and stay visible on mouse-up. So simply clicking a ruler has the same effect as ticking View > Show Guides. This is too much, in my opinion. For it can happen that you click a ruler by accident, and you certainly don’t want to change guide visibility in such an instance. So I would suggest that, in the scenario described above, you should make guides visible if-and-only-if a new guide is actually created. Just clicking a ruler shouldn’t change guide visibility. Alternatively, you could implement a mouse-down and mouse-up behavior in the scenario above. On mouse-down, you could show the guides, on mouse-up (without a new guide having been dragged out of the ruler) the guides would be hidden again. Guides could be displayed temporarily. Could be nice to have. Please consider. 😀

A plus icon next to the cursor when cloning a layer by drag-and-drop would be very useful to have, as @Frozen Death Knight had already mentioned. But other than that, a great and long awaited addition! Thank you! 😃

Hmm … I see. Thank you so much for taking the time and for sharing that link to the developer site, Mike. So unless Apple is doing something, nobody can, it seems. Unfortunately, the “killall dock” method doesn’t work on my system either. I had tested it before, but it just has no effect. Tonight I discovered another command that seems to work for some people. I will have to try it tomorrow. pmset displaysleepnow; sleep 2; caffeinate -u -t 1 So weird that such a painful bug that affects so many laptop users isn’t addressed by Apple. But anyway, thanks for your help. 🙂

No offense, but have you read the threads you’re pointing at? Essentially, the only suggestions they have are (a) or (b) above – or filing a bug report with Apple. It’s not that kind of suggestions I have been asking for here. My intention in starting this thread was the following: since all of the other relevant discussions on the internet are by application users only, not by application developers, I wanted to know whether a developer whose apps are affected by the very same bug could give me a hint how their app communicates with trackpad inputs. I am interested in some technical information, since all other ways to deal with this bug are extremely painful and time-consuming. Imagine you are working on your laptop, and every twenty minutes or so, you cannot zoom into your document anymore without toggling a system setting or logging out of your user account. You will understand that, at some point, there arises an interest in hard, technical facts. 😉

Hi there, it’s been a while since I reported that after upgrading my system to macOS Ventura I have repeatedly experienced the problem that the Pinch-to-Zoom gesture gets randomly disabled on the internal trackpad of my MacBook Pro. All you can do is (a) either manually toggle the respective switch in System Settings off and then on again or (b) logging out of your user account and logging back in. It’s painful. It seems that this is a widespread issue that does not only occur with Affinity Photo, but also with apps like Photoshop, Figma, Sketch or FontLab, even with the Preview app that ships with macOS. But it also happens in the Affinity Suite, and I would really like to know what causes that or what we could do to stop this really terrible bug. To be sure, I already sent a bug report to Apple, but such seems to fall on deaf ears. So I wonder whether you have, as developers, a guess what could go wrong here? How do the Affinity apps intercept trackpad inputs? Where would I have to look, what would I have to monitor to see whether I could find a solution to this bug that doesn’t require (a) or (b) above? I would be most grateful for any hint. 🙂 Alex

Well, of course, you can zoom in on the export preview to inspect your fine details. So that’s not an argument in favor of the request that there should be a button to turn export preview off. I think the main argument remains that (a) export preview is not necessary for all jobs, and in such cases (b) creates needless UI friction by imposing a psychological hurdle to the user against quickly pressing the Export button. It is a simply a psychological fact that we are all trained to wait and expect something when we see a spinning wheel icon on a screen, even if we know that, in a particular instance, this spinning wheel icon does not tell us anything and does not want to make us wait with respect to our next action. Good UI/UX design should understand the importance of such psychological facts. A toggle switch, two lines of code to hide the left panel of the export dialog – this should be done in a moment. Would it be so difficult to add this?

Well, that November 21 detail could be a mere coincidence. I know for sure that this document was created in Publisher 1, not in a Beta of Publisher 2. The additional message reads: “Affinity Publisher created this file on November 21, 2022.” — I can only say, version 2.0.0 is installed nowhere on my system. “Find any file” doesn’t find any application file. Hmm.

Wow, thank you so much for sharing your thoughts. This is very appreciated, and I feel truly honoured that you spent so much time on trying to find out what’s going wrong, Mike. 😊 Unfortunately, and I hate to say this, none of your ideas applies to my situation. Sure, I had the Beta versions installed, but when the release versions became available, I removed all Beta-related stuff from my hard drive. Including preferences, application support files, et cetera. I can’t find a trace of an earlier version besides version 1 on my computer. So I take it that my issue is very special and probably limited to a few particular files. I’ll keep an eye on the problem, and if it happens again with other files, I’ll report back. It’s very mysterious. With new files, it doesn’t happen, so there’s a chance that it will simply be a transition problem. 🙂

Yes, everything works fine, save for this message. I can even open the document from within Affinity Publisher, but not by double-clicking in Finder. Hmm.

The first text reads: “*.afpub cannot be opened because the developer cannot be verified. macOS cannot verify that this app does not contain malware.” The second text reads: “The Application ‘Affinity Publisher 2.app’ cannot be opened.” MBP 16'' 2019; 2,6 GHz 6-Core Intel Core i7; Intel UHD Graphics 630 1536 MB; 16 GB 2667 MHz DDR4; macOS 13.1 (22C65); Affinity Publisher 2.0.3.

Publisher 1 document, opened in version 2. Or rather, not opened in version 2. Instead, I get the following error message, when I double-click the document in Finder: What? — I’m trying to open an .afpub document here, not an application. How comes macOS Ventura to think that this document is an application that must be scanned for malware? After clicking OK on this dialog, I get the following notice: When I open the document from within Publisher 2 (File > Open), it just opens correctly. Very strange. 😳

The Portrait / Landscape icons are indeed hard to find, if you don’t know where to look. They should be in the document setup section, bottom right of the new dialog. I get the idea that you can now switch *all* templates from Portrait to Landscape orientation at once, but still, when I’m setting up a specific document, I usually don’t care about the other templates, and it feels slightly unintuitive that I cannot switch the orientation alongside page dimensions settings etc. 😐

Ah, thanks for that! My goodness, we could really have looked there. 🤦‍♂️😁