Corgi

I've been dismayed by the number of reports that the production release of 2.5 fails immediately in various ways. Obviously there's no way for me to tell what percentage of users are experiencing problems, but it's prompted me to wonder whether the decision to release more frequent 2.x versions, each with fewer changes from the prior release, has changed the character of the Beta program. It's easy to imagine that this change in production strategy has reduced the effectiveness of the Beta programs: The Beta for each new 2.x release appeals to fewer potential Beta testers, since it has fewer new features and bug fixes. Thus, there are fewer users who might get really excited by the new Beta. Beta weariness -- with more frequent product releases, there are more frequent Betas. I'm sure some Beta testers must tire of putting each new Beta release through its paces. Schedule pressure -- With a compressed schedule for version releases, there's less time for the 2.x Beta to mature. I haven't studied the numbers, so these are speculations.

Now that Serif is owned by an Australian company, what will this mean for us users? Will all the UI icons be upside down? Will all the video tutorials use Australian accents? Please say 'no.'

I completely believe you and your sincerity. At the risk of speaking for others, the concern isn't that there are immediate plans to move to a subscription model. It's that the transition to a subscription-only model is now inevitable. What we would love to hear is, "The Affinity suite will continue to be developed with enthusiasm, and Canva and Serif commit that you will absolutely never be forced to subscribe to receive updates or new versions of our products." But, even then, we'd be skeptical, given what other companies have done after similar promises.

I'm happy for the Serif staff, but far less happy for us users. There's always the potential for some beneficial synergy, but history and common sense suggest that this is the beginning of the end of the Affinity suite as we know it. Of course I agree with others that moving to a subscription model will shed me as a customer forever. But, even more problematic would be to turn the Affinity suite into web apps, or even applications that require frequent network access -- that would be simply awful. It's already problem enough that I need to connect to the Internet to register v2, even once at initial install.

Thanks for trying @fde101 but neither one of those solutions works for me. Using the "force cusps" modifier key seemed to produce the same problem, namely, dragging the path changes the control point on the node whose control points I want to remain stable. Changing the node to Smooth does produce a control handle which I can adjust, but if the node is in the middle (rather than at the end in my simplified example), I would still need to turn it back to Sharp, which then removes the control point and also changes the implicit control point angle.

Unless I'm missing something, there is no way to create control points on Sharp nodes without click-dragging one of the paths the node is connected to. But doing so will modify the control points on the other end of the path you drag. For example: Now suppose I want to gain access to a control point on the leftmost node. Dragging down on the path immediately to the right of that node yields: Why did the Smooth node on the right need to change? How can I restore the control points to their original positions? There should be a way to create the control point on the Sharp node without affecting anything else. This doesn't seem to be a problem on Coreldraw for example.

I'm using Designer 2.2.1 Normally when changing a node from Sharp to Smooth (or Smart) you'd expect the curve to change. But if the curve at the Sharp node is actually "smooth" to begin with, there's no reason for the shape of the curve to change. It may not be possible to create this scenario from scratch within Designer, since when you have a Sharp node and move a control point such that it becomes parallel to the other control point, the node automatically becomes Smooth. However, this is not the case when opening an SVG file or editing an embedded SVG file. Consider this portion of a Designer file that was used to open an SVG file: The node in the center is Sharp, yet the control points are aligned (perhaps give or take a rounding error). But if I change the node type to Smooth, this is what I get: This behavior makes touching up imported graphics imprecise and much more tedious. Designer should recognize this situation and leave the curve as-is when converting the node to Smooth. Of course, this situation would arise much less frequently if Designer had its own bitmap trace support. 😉 The attached afdesign file was derived from opening an SVG file with Designer (I created the SVG file by tracing it with CorelDraw and exporting). You can play around with it if you want. sharp-to-smooth.afdesign

To elaborate more on Node improvements (with some overlap of OP's suggestions), there are some missing features I routinely encounter -- perhaps there are already solutions to these which I don't know about: Ability (or at least the option) to change a node from Smooth to Sharp without affecting the curve's shape. Ability (or option) to change a node from Sharp to Smooth without affecting the curve's shape, in situations where the node is Sharp but the handles are already in perfect 180-degree alignment. When editing a Sharp node in Affinity, the node automatically turns into a Smooth mode if the handles become perfectly aligned like that, so it might seem like you can't have a Sharp node that mimics a Smooth node. But this isn't the case (for example) when opening an SVG file. In my case, today I had an SVG that I was editing, and many Sharp nodes were effectively Smooth (control points/handles formed a straight line), but when I converted them to Smooth nodes Affinity unnecessarily changed the handles and shape of the curve. Ability to show or produce handles on Sharp nodes without "pulling" the curve. The problem with dragging the curve is that it modifies the control point for the other end of the segment. Often I wish to leave the control point on one end alone while changing the behavior only of the Sharp node in question.

Thank you for the simple workaround.

@NotMyFault: I created a file (that performs identically as the one I posted) on v2. Then I copied the layers and pasted them into v1 and saved it. That's the file I uploaded. I've now posted the v2 version here, for completeness. The blend modes are normal. The gradient layer has a linear blend range applied. All I did was create a new file and: Create a gradient, with varying alpha Apply a non-default blend range (I used 0% to 100%) Add a live Gaussian blur Tried to change the blur to something other than 0px I presume the reason you see the alpha only change in 85% is because the white parts of the pixel layer have no transparency to begin with. It appears that this is the same bug as afp-3062, and was reported back in 2020, and then logged with the developers. Too bad it's still there. blur-confusion-v2.afphoto

I'm seeing a problem when applying a live gaussian blur on a pixel layer that has non-default blend ranges. See attached file (edit the Gaussian Blur settings to see the problem). It also happens on v1. As soon as a non-zero live gaussian blur is attempted, the blend range is ignored. It looks like something similar or identical was reported in 2021 as afp-3062. Windows 10, seen on 2.1.0 (and also 1.10.5.1342). Seems to occur whether OpenCL is enabled or not. No problem if I do a destructive gaussian blur, however. blur-confusion.afphoto

When comparing small, agile businesses to large, established businesses, it's seems logical to expect that the smaller company will: Create products which generally have fewer features than the larger company, but will gradually close the gap over time. Be the first to incorporate some disruptive technologies. Be more likely to tip their hand about future product evolution, to draw interest and create buzz. Although the Affinity suite is very good and boasts certain capabilities that Adobe can't match, it feels as if the feature gap is growing rather than shrinking. And this is most evident in the case of AI - both generative, and the LIghtroom productivity features. The gap is unnerving, as is the lack of a good sense of Affinity's future direction. At least we now know that there are no immediate plans for generative AI, and can plan (and provide feedback) accordingly. Even so, I plan to continue to use the Affinity suite, and can always supplement with third-party tools when necessary, for AI, vector trace, image organization, et al. Yet I will miss the ease-of-use that comes with integration.

It's also a bug (2.1.0, Windows 10) in that upon starting Designer and going into the Export window for the first time, the Matte thumbnail is pure white (no red slash through it) even though there is no matte actually selected. Following the suggestion from @debraspicher of selecting the "no matte" option in the Swatch panel fixes this. Closing Designer and re-opening it can restore the default of "no matte" as well, even though the color thumbnail is incorrect.

I tend to doubt there are many people who are happier to have their content scaled down smaller than the thumbnail square in order to fit blank areas due to a rotated bounding box. Can anyone think of a situation in which the current implementation is really helpful? But in any case, I suggested it as an option, which would give users their preference (though perhaps not making developers themselves happy 😑) Thanks for the link -- that thread seemed to reference a different situation, in which the aspect ratio of the content doesn't match the aspect ratio of the thumbnail. I don't have any issue with the way that's treated currently.

Minor suggestion (for all apps, presumably). Right now, it appears that the size of the contents displayed in the Layer panel thumbnail depends on the size/orientation of the bounding box, rather than the size of the contents themselves. This can make objects appear to be different sizes when they're not, and doesn't make full use of the space available in the thumbnail display. For example, create a perfect circle and the thumbnail will be filled with the circle edge-to-edge. Now rotate the circle 45 degrees and the thumbnail display shows a smaller circle, presumably about 70% of its full size. So it might be nice, at least optionally, to scale the thumbnail to fit-to-contents rather than fit-to-bounding-box. When you're dealing with thumbnails this small, every little bit of detail helps.