Stokestack

Oh boy, this again. And, again, the answer: There is no "versionless" repository for outstanding issues, is there? If there is, please share it with us all so we can avoid this "mistake" and the follow-up snark.

As I mentioned, most people's E-mail addresses are already collected on spammers' lists for easy bulk attacks, whereas this is not true for proper user IDs. Those IDs could be scraped, but not collected as easily or widely as E-mail addresses. Apple IDs were not originally required to be E-mail addresses. And even when Apple disappointingly adopted that requirement, they didn't have to be functioning addresses. Now Apple has just thrown in the towel on sensibility and created a mess, because (as you point out) E-mail addresses change, and people think they have to create a new Apple ID as a result. And after creating the problem, Apple has publicly and huffily refused to allow account consolidation. Apple has also had to tack on additional measures to mitigate the resulting "hacks" of accounts, which were undoubtedly compromises based on weak E-mail-address/password combos. I'm also not talking about hacking the back end, where of course the whole user record is compromised. I'm talking about logging in with stolen, sold, or guessed credentials... with spammers' E-mail-address lists providing an excellent starting point for sites that use E-mail addresses as IDs. The fact that usernames aren't bulletproof doesn't change the fact that forcing them to be E-mail addresses is dumb, or that the stated reasons for doing so on this site are backward and wrong. You brought up additional valuable examples of why.

That's pathetic.

Of course, but they wouldn't be the log-in mechanism. Banks and other high-security institutions have your E-mail address too. But they don't have you logging in with it.

Since there's no place for feedback on the forum itself, this'll go here. This post from Affinity is so opposite to the truth and good security practices that it demands a rebuttal: Forcing people to use E-mail addresses as user IDs is an amateur-hour practice that should be avoided. You'll note that high-security institutions like banks and brokerages do not use this scheme. It is E-mail addresses, not usernames, that populate thousands if not millions of spammers' and hackers' lists. Hackers can iterate through those lists and attempt log-ins with a dictionary of common passwords and pretty much be guaranteed plentiful log-ins. But that's not all. The people in this particular forum may be a bit more computer-savvy than the general public, but you need to consider that when many people are confronted by a site that demands their E-mail address and a password... they're going to think they need to use their E-mail password (or they will use it out of convenience). This makes relatively insecure Web sites and forums gatekeepers to thousands of people's E-mail accounts, ripe with opportunity for identity theft and other scams. This is an ignorant, retrograde policy that should be abandoned. I am mystified that someone thinks an Affinity-forums user ID is more important to protect than someone's E-mail account.

That is an absurd comment. You should be directing this question to Affinity, not a user. Do you expect users to log in, year after year, and re-post their feature requests under new version numbers to herd them along in perpetuity?

@stokerg @lepr Thanks for the quick replies, guys. I never enabled "Lock Children," and in fact would never have noticed that control. Looking at that toolbar, there's nothing anywhere near that button that I would have used and accidentally clicked it, either. When activated it does indeed produce the behavior I reported. My temporary workaround was to select the layer and "group" it; this did force the mask to rotate with the layer. I found the problem though! I noticed that after creating the mask and then dragging shapes onto it, the shapes seemed to be masks on their own. They are not shown as children of the mask layer, and activating or deactivating the mask layer has no effect on the masking behavior. So I deleted the mask layer, and sure enough the shapes continued to work as a mask. But this activates Lock Children without the user being aware of it. That is the problem! Update: After seeing this behavior, I started over and tried to record it. It didn't happen this time. It's baffling.

Hi all. I masked off some areas of an image, and now I want to rotate the result. But nope: Despite the masks being shown as selected along with their parent, they don't rotate. But if you select a mask by itself, it rotates. Look at this. And I might as well head this off: No, flattening is not a solution. I created these masks as vectors on purpose. Thanks for any insight!

These applications have some serious UI-validation problems. There are numerous situations where controls that should be disabled aren't, and then this one where one is disabled but shouldn't be.

This is why I didn't update my Affinity applications. I would have done so for bug fixes alone, but they show little interest in fixing easily-identifiable bugs both large and small. I can't imagine that this one is hard to fix; it's defective UI validation. If this is more than a quick fix, the codebase must be a deplorable mess and there's no hope for the app anyway. Cap that off with a "we aren't going to fix that" attitude, and you have a very disappointing missed opportunity in these applications.

I was referring to Serif's refusal to add the ability to flag a layer as non-printing in their applications; this is a standard feature in similar software.

Which is not a feature Serif understands, considering one of the most complained-about functionality gaps in their applications.

Thanks for taking the time to provide that info. Since Preview on the Mac makes Acrobat Reader unnecessary, I would guess that almost nobody sees PDF "layers" or content-group visibility toggles on the Mac.

Thanks. I opened the "Layers.pdf" file from that thread, and there's no indication of layers in Preview on the Mac. I don't even understand where that capital-L bug comes into play, but it sounds ridiculous!

Thanks for the responses and helpful tips, everyone! How? How are the layers manifested in the resulting PDF? I don't see any structure analogous to the layers in the document. Thanks!

Thanks! Any idea what "include layers" is supposed to do, then?

Hi all. I have a multi-layer Photo file. I tried including layers when exporting to PDF with both "persona" and "non-persona" methods, but this didn't appear to do anything. The resulting PDF was only one page. Any idea what gives here? File attached. Thanks! vaporizerManual.afphoto

I really like Corel Draw, which I agree is far superior to Illustrator. What's your beef with it? Did Corel go to a software-rental scam too? I don't use Draw anymore because I don't use Windows anymore. There have been a couple of disastrous attempts at Mac versions of Draw, which were quickly abandoned.

I declined to buy v.2 of all of these applications because of defects and omissions like this. The blurring of layers in Photo is so unforgivable that I can't see ever updating that one unless it's fixed. But if even a couple of other defects in Designer had been fixed, I would have coughed up the dough. But as far as I can tell, Serif hasn't fixed any of the glaring problems that cripple this (and their other) applications.

Nope. That doesn't make sense. The OP wants to transform them together, not separately:

Yet another independent confirmation of this defect. How many people experience it but never know their work was degraded? Odds are: many. And then whittle those down to the ones who bother to come here and post about it, and the logical conclusion is that many of the people who actually exercise this software encounter it. But hey, enjoy the pile of grasping excuses you'll find among the dozens of posts about it.

I really wanted to support Serif for developing new art software (especially Designer, because Illustrator is dead), and I hate the software-rental rip-off trend. But their designers' detachment from reality, not to mention ignorance of good UI standards and design that already existed, has led to bizarre functional gaps and gaffes. I mean... this whole thread started with a simple request that should never have been necessary: Let us transform a selection. I mean... WTF? How does a NEW photo-editing/compositing application make it out the door without that in the last 20 years? The FREE software I got with my Epson scanner in the '90s had that (and still does). You can point out defects and make sure you suggest solutions that don't impede anyone else's workflow, and serve the most-common use cases and reflect industry standards. You can mock up a complete UI revision and grant free use of it, which again impedes no one's workflow. Yet the same apologists will endlessly attack it and defend dysfunction, like that which gradually degrades users' work through innocuous operations that are harmless in every similar piece of software (and should be in this one). I sincerely appreciate the fact that an employee or representative engaged with us in the thread. But I don't appreciate the insulting excuses and technically incorrect statements (peppered with citations of speculation from other customers as some kind of "proof"), and the condescending "You simply [undertake a number of steps that there was no reason to guess were necessary and are not indicated as necessary in the UI and aren't in competing software], so it's not a bug." Several people have independently demonstrated the blurring defect reported here, and nobody has been able to show why they should have guessed that their work was being ruined. Dan claimed he's sorry that I don't feel this software can be trusted, but that didn't hold up in further conversation. If Serif cared about users' work, it would either prevent it from being degraded, with the simple step we've suggested here; or at the very least WARN THAT IT'S GOING TO HAPPEN. There is no excuse for not doing at least one of those things. And that's that. It's sad to see that these applications are already moribund, hobbled by the same design defects, functional defects, and missing functionality that have dragged them down since their inception. Over and out.

Amen. Your request is succinct and nails it.

Hahah, they're just supposed to wait, for no apparent reason, for "understanding" to magically descend upon them? And that's assuming they realize that their work was degraded in the first place (which, as already pointed out, may depend on the type of imagery it is). Knowing what DPI and resampling are doesn't make any difference, except in being able to point out how defective Photo's logic is here. Nobody is complaining about that. Of course that's desirable. I never said anything to the contrary. I'm complaining that Photo doesn't do that when you are satisfied with the imported imagery's placement and integrate it into what's underneath it. It decimates the underlying image data; and nobody is denying that. Looks like we agree here. For pixel-precision work, I really don't want the software to do any resampling for me. Me neither, and the only way to avoid resampling both layers, according to the almighty authorities in this thread, is to rasterize the overlaying layer before the merge down. So you too must wonder why Photo shouldn't do this as part of the merge-down operation.

Again, the regurgitation of the DPI excuse without explaining why BOTH layers would be resampled. Which there's no way for the user to know. So why doesn't the software do that as a part of the "merge down?"