Brad Brighton

While I can understand and appreciate this, Greg, I doubt there's anything Serif could have done except explain it better. I cannot speak on the MS side but as an Apple developer, had this situation been on the Mac side, there's no one for the developer to talk to. Apple specifically tells developers they CANNOT initiate refund requests. The user/customer MUST do so. I suspect it's similar on the Microsoft side.

To get this out of the way, I do NOT work for Serif nor am I an apologist. I'm going to dive in on this part only because it may be useful for any non-developers reading, either for this specific topic or generally. App Store versions (both Microsoft and Apple) of any app are NOT identical to self-distributed versions of those same apps in two critical ways: There is extra code involved to support the delivery of the app (security & receipt checking, etc) through the respective app store as well as potentially dealing with the environmental differences because of delivery method (see the next point). The "rules" of what an App Store version of an app can do by default are increasingly different than what a self-distributed app may do, predominantly centered around asset and resource access security. "What can you open?", "Where can you save?", "How do you talk to other apps?", "What hoops do you have to jump through to achieve a particular action?", etc. Neither of these is meant to be a "get out of jail free" card for Serif should there be bugs or uncaught misbehaviors due to restriction cases that weren't clear. However, the nature of software development is that the results are imperfect and the more variations there are of an environment, the more likely there will be errors that are only discovered "in the field". Serif, I'm certain, tests for as many of these as reasonable and when something breaks or is missed, works diligently to identify, isolate, and correct those issues. Add in the nature of App Store business agreements (which effectively are determined by MS and Apple, NOT Serif) and it's understandable that some audiences may feel slighted when there are issues. It's unfortunate, both that those feelings are incurred and that the remedies are fewer for Serif when working with the App Stores but that's the state of the situation in cases like these.

Yeah, I'd have to agree, there are several suspicious elements here. I would recommend running First Aid on the disk but if you're going to have it looked at anyway, leave it alone and let that person see it as it is (to avoid hiding any symptoms or messages that inform the situation).

:-) I wasn't focusing on the 'me' part, I was focusing on the leading slash. Are you trying to work on the file(s) simultaneously in the two apps? Your comment about only getting errors when Designer was running makes me go "huh?"

It could easily be a typo in bringing the error message over so forgive the detail question -- is it "Users/me..." or "/Users/me..."? The former is highly unlikely to exist and FileNotFound errors can sometimes be lumped together with access permission errors (in that you don't have permission to access something that doesn't exist). And I do see the slash in the Desktop example, so I suspect it's "/Users/me...". Also, do I miss in the thread whether you're dealing with the MAS version or direct-from-Affinity version of AP? There could be sandboxing issues going on if you're using the MAS version. Apropos of advice you didn't ask for and FWIW, when you eventually move to a Mac that runs a newer version of the OS, you're going to have additional hoops to jump through to keep that non-Home-tree workflow unless you move it to external drives. More and more, full disk access is being restricted by default (though you CAN make exceptions, hence the hoops).

Only if any development the OP may do is specifically for fonts. FTXcode and FTXViewer catch me periodically when I'm trying to install, not debug, and I *do* know what to do with fonts. These are tools that are installed but I never have a need for them. FTXcode specifically can capture that double-click; the only harm is to my vocabulary for me. For someone otherwise unfamiliar with those tools, specifically calling out the app needed may help them realize that the default open app may not be Font Book.

For completeness, if you happen to be a developer you may have other tools installed as well that would interrupt that double-click as described so if double-clicking the font doesn't open Font Book, Font Book is the app that will let you install them.

@Castle Al You have to read the and decipher info on the main page you linked to get that the txz file is what you want. To the package maintainers, it's apparently more important to save a few MB at distribution time than to stick with standard delivery methods.

Yuck, that sucks. Silverfast is the only other major player in the game of older scanner support AFAIK (https://www.silverfast.com) but its price point is a non-starter for most people. One option that might help is to run a virtual machine (VMware Fusion or Parallels) with Mojave (either from a previous backup or a clean install), connect the USB scanner to it rather than the host OS, and see if that will restore your access through "Acquire Image..." within the VM. Then scan to a shared folder destination to make the results available in both environments.

VueScan lists that scanner and despite the download button saying Mojave (which may be based on auto-detection), the supported versions text beneath the button notes 10.15 (Catalina) support. https://www.hamrick.com FWIW, I have no personal experience with that scanner nor have I upgraded to Catalina yet.

Forgive me, @LionelD, but I'm still unclear. It now sounds like you're looking for an alternative to the native afphoto storage format, but one that preserves all your edits in a granular way. Is that actually the case? And if so, what is it that makes the Affinity native files unsuitable for your needs?

Are you referring to pixel image output formats? If so, you're probably going to hit pixel count issues in PNG (I did) so you're probably looking at TIFF instead. If you're talking about something else, please elaborate further. :-)

Serif will have to speak to whether the existing license can be converted or a refund issued... To the original goal, Serif sales can walk you though a process to get a redemption code that can be used with the Affinity Store account. A quick check suggests that 13 is the minimum age for that, though it's not explicitly stated. (13 is a "magic age" on the internet below which reputable sites do not collect information or (in many cases) even allow usage).

from https://www.businessofapps.com/data/app-revenues/#4

I'm not the poster you refer to but unless you're being picky about one word, "tablet", it's long been known that iOS is more profitable (here's one of many sources): iOS App Store 2018 revenue came to $46.6 billon, while Google Play revenue stood at $24.8 billion by this measure (https://www.businessofapps.com/data/app-revenues/) as far as piracy on Android, it gets a little trickier to document in a more general way because many of the reports I found in my quick search talked about the numbers in terms of a specific app which makes the argument more anecdotal. Also surprisingly, most of the noise about android piracy specifically is from the 2015/1026 era; these days the message is more about embedded malware and bad actors swamping Google Play despite the attempts to curb it. (piracy: https://www.makeuseof.com/tag/piracy-android-how-bad-is-it-really/, -- malware: https://arstechnica.com/information-technology/2019/09/malicious-pop-up-ad-apps-slipped-past-google-play-security-to-reach-millions/) Bottom line is that the Android market as a whole leaks like a sieve and while there may be pockets of parity, iOS users are less likely to pirate (since it usually takes jailbreaking to accomplish this) and measurably more likely to spend money (weirdly, also from 2016: https://www.androidauthority.com/new-report-reveals-that-ios-users-spend-2-5-more-on-in-app-purchases-than-android-users-700983/), making the business case for Android Affinity Suite is difficult at best.

For your own testing then, what I did is turn on Force Pixel Alignment under the Snapping dropdown (see attached). EDIT: But now that I'm thinking about it, that checkbox by itself probably didn't actually do anything, as you're noting. I wonder if you have some things aligned on boundaries that don't export well and may take a little tweaking.

@Tevya Before I say what I did (which may be nothing useful), does this look better to you? It does to me zoomed in with Preview.

Once again, this is an Apple change for Safari on iPadOS. While the previous link was a user responding to a different post in a different forum, here it is "from the horse's mouth" as it were, from Apple's WWDC19 session on "Desktop-class Browsing on iPad" (from the transcript of session 203 - https://developer.apple.com/videos/play/wwdc2019/203/?time=1377) "The user can tap a second time if they wanted to click." While anything is possible about future changes, this is a definitive statement from Apple: if you're using the "desktop class browsing" on iPadOS 13+ and the website implements hover and link on the same element, you're going to have to tap twice.

"It just works" as long as the new computer is of the same OS family as the previous one. No need to "remove" the old one. If you bought through Serif's Affinity Store, go back there and get your license key. If you bought through one of the vendors' App Stores, reinstall from there as needed.

What most novice users may not realize is the dramatic cascading loss of quality for doing that (saving at anything less than the least-lossy option) multiple times. Default behavior cannot be assumed from a single action; if the user knows/thinks they know how the end product is going to be used, ok (I'm all for giving people the option to do things that may seem silly in the general case because not all cases are general) but "silliness" should be the exception.

Another FWIW since this topic of UI consistency, however inappropriate for this part of the forum, is getting interesting: Hover over the thread link in "Browse" gets the thread summary. Hovering over the thread link in "Activity" does not, in macOS Safari 13.0 (on Mojave). EDIT: And that makes a curious (if geeky) sort of sense because in "Activity" it's not a thread link, per-se, it's a post link. Hover over user links and avatars gets the summary in either location.

@mac_heibu Our posts probably crossed but see my link above yours... it appears really to be an Apple change to Safari behavior and while its impact may be more prevalent on the forums here, I suspect you will run into it elsewhere at some point.

Since I don't have an iPad running this yet, I couldn't confirm but I did find an explicit reference to this behavior footprint: From https://www.macrumors.com/2019/06/06/safari-on-ipados-optimized-for-desktop-websites/

FWIW, Safari on iPadOS did change to specifically become more "desktop browser"ish so some behaviors I'm sure changed. https://www.macworld.com/article/3403436/safari-on-ipados-13-the-best-new-features.html#toc-1

<eyeroll> If we're going to down the silly analogy road, Serif's position is more like "You bought this to read on Kindle, if you want to read it on Apple Books you need to buy it again," than it is about the different Kindle devices. I can appreciate that some people may get surprised by the "license per platform model" and may even hate (intentionally strong word chosen) such a model but even in a perfect development world, it takes different resources to create and maintain a substantial part of the application on each platform. All the math in the world that may be in common code everywhere the Affinity apps reside doesn't make it appear magically through a user interface. It doesn't make it magically compatible (and accurate) with different versions of Windows, macOS, and iPadOS (nee iOS). A for-profit entity has a choice of spreading those development costs across all platforms (making each one more expensive to subsidize the others) or to allow (for some part) each platform to earn its own keep. Both approaches have pros and cons and when there's an uproar over having to deal with separate licenses at a cumulative cost that still is less than that of the competition, that uproar can arguably be likened to whining more than constructive market and user feedback. If you don't want to support Serif's business model, make your voice heard to them then go spend a greater amount money on the competition, if that's what you need to do. Serif's value proposition is not misleading nor is it out of place in the market.