Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.


  • Posts

  • Joined

Profile Information

  • Gender
  • Location

Recent Profile Visitors

5,189 profile views
  1. 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. 🙂
  2. 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. 😉
  3. 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
  4. 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?
  5. 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.
  6. 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. 🙂
  7. 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.
  8. 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.
  9. 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. 😳
  10. 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. 😐
  11. Ah, thanks for that! My goodness, we could really have looked there. 🤦‍♂️😁
  12. Here’s a hint at the underlying technology: I guess that is to say that the (supremely fast!) screen renderer that is used by the Affinity apps requires a custom text engine that does not rely on the operating system or on third-party libraries for the core business of text layout and rasterisation, but reads font data directly from the binaries.
  13. But I wonder what’s your point, @fde101. All three operating systems (macOS, Windows, iOS) already support variable font rendering and offer the respective APIs, and the Freetype project provides a freely available cross-platform software library to render variable fonts. Personally, I’ve never heard what @DamienG said, namely that the Affinity apps would already use Freetype. I doubt they do, for they would probably have been able to add variable font and color font support already, if they did. It would be interesting to hear from a developer about the text layout engine currently used in the Affinity apps or receive any comment on this thread. Everything is just speculative to this point.
  14. Indeed, that’s probably one of the problems that has prevented adding variable font support so far.
  15. I’m not so sure. Take the Mac versions as an example. I could be mistaken, but far as I understand, the Affinity apps do not use Core Text on macOS, but are based on a custom text layout and rendering engine that reads the raw font data directly. So handling variable fonts would have to be done by that custom engine. If the Affinity apps were to use Core Text, they could also provide variable font support. As far as I remember, the Mac operating system started to include variable font support in version 10.5. Though “support” certainly meant something different then, compared to what is possible today. In general, I would also support the request made in this thread. While I used to be sceptical about variable fonts in the past, my mind has changed since. These fonts are highly useful design tools.
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.