JET_Affinity

I have a total disdain for third-party plug-ins. For my money, it's a development model that failed decades ago. I refuse to become work-dependent upon them.
I'd much rather see the development time dedicated to an Affinity-specific Javascript object model.
JET

Again, a topic conjures up fond memories of FreeHand.
FreeHand had just one kind of text object. It could be set to auto-expand horizontally (i.e., becoming functionally equivalent to a so-called "art text" object in other programs) by simply doubleClicking the right middle handle. It could be set to auto-fit its contained text vertically by doubleClicking its bottom middle handle. The text objects could be bound to and released from paths (instead of being treated as a separate "path text" object). They could be threaded, whether bound to a path or not. They could be set to auto-expand when bound to a path, thereby preventing the problem of accidentally truncated text in complex maps, as is so chronically common in maps built in Illustrator.
This is conceptually parallel to the fact that FreeHand also never had any need for two separate selection tools. Its single selection tool enabled you to edit paths at the whole object level and at the node editing level. That elegant interface design made path drawing far less tedious, more fluidly efficient, and more powerful than any drawing program that insists on following Adobe's hideous model of two primary selection tools.
Macromedia finally gave in to ill-advised "demand" from Illustrator users to add a second pointer tool. When added, it provided absolutely no additional functionality. It was literally nothing but an accommodation to Illustrator-habituated users who just refused to learn that it was absolutely unnecessary. FreeHand users simply ignored it. It was not until FreeHand's very last version that its white pointer did anything that the black pointer didn't, and even that was a minor detail that could have been implemented without adding another tool.
Despite Illustrator's two selection tools (three, really, when you include the ill-conceived "Convert AnchorPoint Tool")--actually because of it--Illustrator to this day does not "know the difference" between a path being selected at the object level versus merely having all its AnchorPoints selected. This causes all kinds of silly inconsistencies such as being unable to use the Break Anchor Point command when all of a path's Anchor Points are selected. (You have to unintuitively de-select at least one Anchor Point for it to work.)
Because object selection is so bedrock foundational to an object-based program, its tedious effects "cascade upward" throughout the program's interface. In a nutshell, it's what makes working in Illustrator feel as frustrating to beginners as trying to eat spaghetti with a single chopstick.
It's because Illustrator's white pointer behavior is conceptually "upside down" from intuition. It's the selection tool you have to use to edit a path.  But its first click always selects the most "internal" sub-part element of whatever construct you are trying to manipulate. Rather than intuitively selecting an object of interest and then "digging down" to its subparts with subsequent clicks, Illustrator's scheme first selects some "molecule" of the object of interest and requires use of a modifier key and subsequent clicks to "back out" of it to each next higher level.
It's metaphorically like getting up in the morning and needing a pair of socks. So you intuitively try to open your sock drawer. But your hand passed right through the closed drawer, and the only thing you can grab is a single thread of a single sock. So you have to then use both your hands to select a single sock, and grab again with both hands to grasp the folded up pair. All this "Bizzarro World" behavior instead of simply opening the drawer and grabbing the pair of socks.
The beginning of the end of FreeHand was not the Adobe acquisition. It was when it started to emulate Illustrator's hideous interface.
Unfortunately, because things like selection tools and text objects are foundational to the program built upon them, I'm sure it's too late to back-track the existing conventional-wisdom (i.e. "like Illustrator") in either case. But I say again: If you want to build a better drawing program, Adobe Illustrator is not the program to emulate.
JET

Not to butt-in on Lagarto's generous attempts to help, but it seems that a very common general misconception about the basics of working with Spot inks may be at play in this thread. So please forgive my attempt to re-phrase part of what has already been explained:
I emphasize inks instead of saying Spot colors because software users confuse 'swatches', 'colors', and such with inks, and thereby think working with Spot inks is more complicated than it is.
Even when talking about CMYK process, color-separations for prepress production are not imaged in colors; they are imaged to film or directly onto the press plates as grayscale or bitmap images. The 'color' is all about what inks are loaded into the press.
When you define a 'Spot color' in software, all you're really doing is telling the software to specify that an additional grayscale separation be generated and labeled by that name. Any objects in the file to which that same label is applied (by selecting the defined Spot color swatch named by that label), get sent to that extra grayscale separation.
It really has nothing whatsoever to do with selecting a Spot ink from a 'library'. The Spot 'libraries' are nothing but a convenience for selecting the ink manufacturer's recommendations for how to approximate their inks' colors on an RGB monitor.
Functionally, it's literally "all in the name." What color gets printed is entirely just a matter of what physical ink the pressman loads into the inkwell of the press.
As Largato explained in other terms, you can specify how a 'Spot color' or a 'Spot swatch' appears on-screen any way you want: by selecting it from a pre-defined 'Spot color library' or by just coloring it with literally any mix of RGB or CMYK values you want. Either way, so long as it's defined as a Spot swatch, it's not going to affect its printed color. Objects assigned that color are simply going to be associated with the additional grayscale color-separation by that name.
Consider the context of a Spot metallic ink: No combination of RGB values are going to enable your monitor to look anything even close to a translucent physical ink that has reflective metallic powder in it. That, in fact, is one of the main reasons Spot Inks even exist. But that doesn't matter one whit.
You can select 'Pantone Metallic 8007' from a 'library' list in the software, or you can just set a new swatch that you've set as Spot and then 'mix' your own on-screen display of it. No matter how you try, you're not going to make it look like the actual copper-ish metallic ink that the pressman loads. All that matters is that the 'swatch' is defined as Spot, and is named 'Pantone Metallic 8007', so that's how the associated grayscale film or plate will be labeled when printed as color-separations.
This is why I (and no doubt countless others) routinely simply define a commonly-used Pantone spot ink (e.g.; PMS 185) using my own display values (100y 100m), instead of Pantone's library recommendations. It doesn't make one bit of difference in the printed results. The pressman is simply going to load Pantone 185 ink into the inkwell because that's the name of the color-separation plate.
When working for print--and especially when working with Spot colors--much confusion is avoided by always thinking in terms of inks, instead of 'colors.'
JET

??
Begging your pardon, Mark, but quite often my purposes for resetting a bounding box is to permanently reorient the selection to its current state. I dare say you'll have the same argument  with decades of Illustrator users, because that program's Reset Bounding Box command is used all the time and it is only permanent; it can't be "restored" to the orientation in which the object was originally created (unless, of course, you reverse the transformation(s) performed and then Reset Bounding Box again).
The "extra space" bounds which Wickster illustrates is also a stumbling block, (and I don't mean in the context of live text).
Yes, I appreciate that Affinity is able to "remember" its untransformed orientation. But it's just as common to need the object to forget its original orientation, and thereafter treat its new orientation as normal.
JET

Not to butt-in on Lagarto's generous attempts to help, but it seems that a very common general misconception about the basics of working with Spot inks may be at play in this thread. So please forgive my attempt to re-phrase part of what has already been explained:
I emphasize inks instead of saying Spot colors because software users confuse 'swatches', 'colors', and such with inks, and thereby think working with Spot inks is more complicated than it is.
Even when talking about CMYK process, color-separations for prepress production are not imaged in colors; they are imaged to film or directly onto the press plates as grayscale or bitmap images. The 'color' is all about what inks are loaded into the press.
When you define a 'Spot color' in software, all you're really doing is telling the software to specify that an additional grayscale separation be generated and labeled by that name. Any objects in the file to which that same label is applied (by selecting the defined Spot color swatch named by that label), get sent to that extra grayscale separation.
It really has nothing whatsoever to do with selecting a Spot ink from a 'library'. The Spot 'libraries' are nothing but a convenience for selecting the ink manufacturer's recommendations for how to approximate their inks' colors on an RGB monitor.
Functionally, it's literally "all in the name." What color gets printed is entirely just a matter of what physical ink the pressman loads into the inkwell of the press.
As Largato explained in other terms, you can specify how a 'Spot color' or a 'Spot swatch' appears on-screen any way you want: by selecting it from a pre-defined 'Spot color library' or by just coloring it with literally any mix of RGB or CMYK values you want. Either way, so long as it's defined as a Spot swatch, it's not going to affect its printed color. Objects assigned that color are simply going to be associated with the additional grayscale color-separation by that name.
Consider the context of a Spot metallic ink: No combination of RGB values are going to enable your monitor to look anything even close to a translucent physical ink that has reflective metallic powder in it. That, in fact, is one of the main reasons Spot Inks even exist. But that doesn't matter one whit.
You can select 'Pantone Metallic 8007' from a 'library' list in the software, or you can just set a new swatch that you've set as Spot and then 'mix' your own on-screen display of it. No matter how you try, you're not going to make it look like the actual copper-ish metallic ink that the pressman loads. All that matters is that the 'swatch' is defined as Spot, and is named 'Pantone Metallic 8007', so that's how the associated grayscale film or plate will be labeled when printed as color-separations.
This is why I (and no doubt countless others) routinely simply define a commonly-used Pantone spot ink (e.g.; PMS 185) using my own display values (100y 100m), instead of Pantone's library recommendations. It doesn't make one bit of difference in the printed results. The pressman is simply going to load Pantone 185 ink into the inkwell because that's the name of the color-separation plate.
When working for print--and especially when working with Spot colors--much confusion is avoided by always thinking in terms of inks, instead of 'colors.'
JET

Not to butt-in on Lagarto's generous attempts to help, but it seems that a very common general misconception about the basics of working with Spot inks may be at play in this thread. So please forgive my attempt to re-phrase part of what has already been explained:
I emphasize inks instead of saying Spot colors because software users confuse 'swatches', 'colors', and such with inks, and thereby think working with Spot inks is more complicated than it is.
Even when talking about CMYK process, color-separations for prepress production are not imaged in colors; they are imaged to film or directly onto the press plates as grayscale or bitmap images. The 'color' is all about what inks are loaded into the press.
When you define a 'Spot color' in software, all you're really doing is telling the software to specify that an additional grayscale separation be generated and labeled by that name. Any objects in the file to which that same label is applied (by selecting the defined Spot color swatch named by that label), get sent to that extra grayscale separation.
It really has nothing whatsoever to do with selecting a Spot ink from a 'library'. The Spot 'libraries' are nothing but a convenience for selecting the ink manufacturer's recommendations for how to approximate their inks' colors on an RGB monitor.
Functionally, it's literally "all in the name." What color gets printed is entirely just a matter of what physical ink the pressman loads into the inkwell of the press.
As Largato explained in other terms, you can specify how a 'Spot color' or a 'Spot swatch' appears on-screen any way you want: by selecting it from a pre-defined 'Spot color library' or by just coloring it with literally any mix of RGB or CMYK values you want. Either way, so long as it's defined as a Spot swatch, it's not going to affect its printed color. Objects assigned that color are simply going to be associated with the additional grayscale color-separation by that name.
Consider the context of a Spot metallic ink: No combination of RGB values are going to enable your monitor to look anything even close to a translucent physical ink that has reflective metallic powder in it. That, in fact, is one of the main reasons Spot Inks even exist. But that doesn't matter one whit.
You can select 'Pantone Metallic 8007' from a 'library' list in the software, or you can just set a new swatch that you've set as Spot and then 'mix' your own on-screen display of it. No matter how you try, you're not going to make it look like the actual copper-ish metallic ink that the pressman loads. All that matters is that the 'swatch' is defined as Spot, and is named 'Pantone Metallic 8007', so that's how the associated grayscale film or plate will be labeled when printed as color-separations.
This is why I (and no doubt countless others) routinely simply define a commonly-used Pantone spot ink (e.g.; PMS 185) using my own display values (100y 100m), instead of Pantone's library recommendations. It doesn't make one bit of difference in the printed results. The pressman is simply going to load Pantone 185 ink into the inkwell because that's the name of the color-separation plate.
When working for print--and especially when working with Spot colors--much confusion is avoided by always thinking in terms of inks, instead of 'colors.'
JET

This is competitive low-hanging fruit if there ever was such.
Obviously, transformations (scale, rotate, skew, translate) should of course be relative to the artwork in-progress.
But we've been so conditioned to the tyrannical vertical-horizontal fixation of nearly every feature of this genre of drawing programs that the obvious is overlooked, even by the users. Think about it: It's almost as if drawing software UI developers think 2D doesn't stand for "two dimensions", but merely 'two directions.'
A precious few 'escapes' --features such as snap-to angled guides and rotated grids--have appeared over the decades. Some attempts are better  than others. But they all fall short.
I've been at this vector-based illustration thing since FreeHand 1. Believe me, I know what the cumbersome workarounds are. Thus the feature request.
Exactly. That's the problem. And the low-hanging fruit. As I pointed out, Affinity does at least provide what Canvas has for decades: it can 'remember' the rotation of a selection.
But unlike FreeHand and Illustrator, Affinity does not provide transform tools. It only provides its tactile (i.e., dragged-on-the-drawing) transform features as bounding-box handles.
Well, any illustrator who doesn't just draw boxes needs to be able to perform translations in any direction relative to the artwork, not just to a rectangular bounding box.
Illustrator provides both transform tools and bounding box transform handles. And it, too, rotates an object's bounding box when the object is rotated. Inkscape doesn't even do that. Inkscape's bounding box stays parallel to the page edges even when an object is rotated.
FreeHand avoided continually cluttering the interface with bounding boxes. What most Illustrator users don't know is that FreeHand's transform tools were better than Illustrators in that they worked better (more powerfully and more controllable) when dragging at arbitrary angles.
Again: Affinity provides a ridiculous five rotation handles on its bounding boxes, all of which do exactly the same thing. Honestly, who needs that?
Meanwhile, try this: Select something. Show the Transform Anchor. Drag it to somewhere other than the selection's center. Now drag one of the scale handles. The Transform Anchor is ignored when scaling. To make drag-scaling act at least similar to what Illustrator's Scale Tool can do, you need to temporarily draw something else to serve as the 'transform anchor' and add it to the selection. Don't try to tell me Affinity's selection/transform interface doesn't still need work.
But as always, Illustrator is hardly anything to which to aspire. like Affinity, its rotated bounding boxes also cannot be rotated about its selection in order to orient the transform handles to the direction in which the selection needs to be scaled. In fact, I don't know of any program in this competitive genre that empowers the user to re-orient the bounding box relative to the selection. It's time one did! It would 'transform' Affinity's scale handles from sub-par to superior in one elegant, unobtrusive functional enhancement.
I don't want Affinity to be a cheap 'me, too' clone of Illustrator. I want it to become something better.
Low hanging fruit.
JET

This is competitive low-hanging fruit if there ever was such.
Obviously, transformations (scale, rotate, skew, translate) should of course be relative to the artwork in-progress.
But we've been so conditioned to the tyrannical vertical-horizontal fixation of nearly every feature of this genre of drawing programs that the obvious is overlooked, even by the users. Think about it: It's almost as if drawing software UI developers think 2D doesn't stand for "two dimensions", but merely 'two directions.'
A precious few 'escapes' --features such as snap-to angled guides and rotated grids--have appeared over the decades. Some attempts are better  than others. But they all fall short.
I've been at this vector-based illustration thing since FreeHand 1. Believe me, I know what the cumbersome workarounds are. Thus the feature request.
Exactly. That's the problem. And the low-hanging fruit. As I pointed out, Affinity does at least provide what Canvas has for decades: it can 'remember' the rotation of a selection.
But unlike FreeHand and Illustrator, Affinity does not provide transform tools. It only provides its tactile (i.e., dragged-on-the-drawing) transform features as bounding-box handles.
Well, any illustrator who doesn't just draw boxes needs to be able to perform translations in any direction relative to the artwork, not just to a rectangular bounding box.
Illustrator provides both transform tools and bounding box transform handles. And it, too, rotates an object's bounding box when the object is rotated. Inkscape doesn't even do that. Inkscape's bounding box stays parallel to the page edges even when an object is rotated.
FreeHand avoided continually cluttering the interface with bounding boxes. What most Illustrator users don't know is that FreeHand's transform tools were better than Illustrators in that they worked better (more powerfully and more controllable) when dragging at arbitrary angles.
Again: Affinity provides a ridiculous five rotation handles on its bounding boxes, all of which do exactly the same thing. Honestly, who needs that?
Meanwhile, try this: Select something. Show the Transform Anchor. Drag it to somewhere other than the selection's center. Now drag one of the scale handles. The Transform Anchor is ignored when scaling. To make drag-scaling act at least similar to what Illustrator's Scale Tool can do, you need to temporarily draw something else to serve as the 'transform anchor' and add it to the selection. Don't try to tell me Affinity's selection/transform interface doesn't still need work.
But as always, Illustrator is hardly anything to which to aspire. like Affinity, its rotated bounding boxes also cannot be rotated about its selection in order to orient the transform handles to the direction in which the selection needs to be scaled. In fact, I don't know of any program in this competitive genre that empowers the user to re-orient the bounding box relative to the selection. It's time one did! It would 'transform' Affinity's scale handles from sub-par to superior in one elegant, unobtrusive functional enhancement.
I don't want Affinity to be a cheap 'me, too' clone of Illustrator. I want it to become something better.
Low hanging fruit.
JET

Unlike some mainstream drawing programs (FreeHand, Illustrator), Affinity doesn't provide Tools (i.e., icons in the Toolbox) for tactile (dragging) common transformations (scale, rotate, skew). Instead, it only provides bounding box handles.
Here's a triangular path:

It's been arbitrarily rotated from its original orientation. Unlike Inkscape, Affinity's bounding box 'remembers' a selection's rotation:

Like Canvas, it does let you switch a rotated bounding box back to its as-created pagewise (vertical / horizontal) orientation:

The bounding box provides no less than five rotation handles:
 

 
We can change the object's 'remembered' rotation by rotating it again and invoking the Reset Rotation command. Thereafter, clicking the Cycle Selection Box button switches between horizontal-vertical and the new 'remembered' rotation:

But what if I want to scale the object in some direction other than the sides of the often entirely irrelevant bounding box? For example, in the direction perpendicular to the rightmost side of this triangle?:

Why can't at least ONE of those ridiculously redundant five rotation handles (the 'lollypop' one) be used (even if by means of pressing a keyboard modifier) to rotate the bounding box itself, relative to the selection, and thereby have that become the 'remembered' bounding box orientation?
To illustrate, I've just used a simple triangle. But this ability would be a boon to all kinds of selections with any number of objects in any number of orientations. In technical drawings, for example, 'tilting' objects drawn on a plane, is a matter of scaling them in the direction of their 'thrust line' (a line perpendicular to their plane). But this is just as applicable to countless situations even in freeform 'eyeballed' drawing.
JET
(I intended to post this as a Feature Request. Moderator, please feel free to move it there.)

Unlike some mainstream drawing programs (FreeHand, Illustrator), Affinity doesn't provide Tools (i.e., icons in the Toolbox) for tactile (dragging) common transformations (scale, rotate, skew). Instead, it only provides bounding box handles.
Here's a triangular path:

It's been arbitrarily rotated from its original orientation. Unlike Inkscape, Affinity's bounding box 'remembers' a selection's rotation:

Like Canvas, it does let you switch a rotated bounding box back to its as-created pagewise (vertical / horizontal) orientation:

The bounding box provides no less than five rotation handles:
 

 
We can change the object's 'remembered' rotation by rotating it again and invoking the Reset Rotation command. Thereafter, clicking the Cycle Selection Box button switches between horizontal-vertical and the new 'remembered' rotation:

But what if I want to scale the object in some direction other than the sides of the often entirely irrelevant bounding box? For example, in the direction perpendicular to the rightmost side of this triangle?:

Why can't at least ONE of those ridiculously redundant five rotation handles (the 'lollypop' one) be used (even if by means of pressing a keyboard modifier) to rotate the bounding box itself, relative to the selection, and thereby have that become the 'remembered' bounding box orientation?
To illustrate, I've just used a simple triangle. But this ability would be a boon to all kinds of selections with any number of objects in any number of orientations. In technical drawings, for example, 'tilting' objects drawn on a plane, is a matter of scaling them in the direction of their 'thrust line' (a line perpendicular to their plane). But this is just as applicable to countless situations even in freeform 'eyeballed' drawing.
JET
(I intended to post this as a Feature Request. Moderator, please feel free to move it there.)

Unlike some mainstream drawing programs (FreeHand, Illustrator), Affinity doesn't provide Tools (i.e., icons in the Toolbox) for tactile (dragging) common transformations (scale, rotate, skew). Instead, it only provides bounding box handles.
Here's a triangular path:

It's been arbitrarily rotated from its original orientation. Unlike Inkscape, Affinity's bounding box 'remembers' a selection's rotation:

Like Canvas, it does let you switch a rotated bounding box back to its as-created pagewise (vertical / horizontal) orientation:

The bounding box provides no less than five rotation handles:
 

 
We can change the object's 'remembered' rotation by rotating it again and invoking the Reset Rotation command. Thereafter, clicking the Cycle Selection Box button switches between horizontal-vertical and the new 'remembered' rotation:

But what if I want to scale the object in some direction other than the sides of the often entirely irrelevant bounding box? For example, in the direction perpendicular to the rightmost side of this triangle?:

Why can't at least ONE of those ridiculously redundant five rotation handles (the 'lollypop' one) be used (even if by means of pressing a keyboard modifier) to rotate the bounding box itself, relative to the selection, and thereby have that become the 'remembered' bounding box orientation?
To illustrate, I've just used a simple triangle. But this ability would be a boon to all kinds of selections with any number of objects in any number of orientations. In technical drawings, for example, 'tilting' objects drawn on a plane, is a matter of scaling them in the direction of their 'thrust line' (a line perpendicular to their plane). But this is just as applicable to countless situations even in freeform 'eyeballed' drawing.
JET
(I intended to post this as a Feature Request. Moderator, please feel free to move it there.)

Hear hear! It's been demonstrated that a lot of nice things can be done with the brushes in Designer, but calling them "vector" brushes just because the raster images they contain follow a spline path, is entirely misleading.
Actual vector brushes (in which the brush's base artwork is vector paths) enable you to do an entire world of more powerful things:

 
For example, A single "Pattern Brush" in AI can be built to enable creation of a mechanically correct hex bolt of any length and diameter. As always, Illustrator's implementation could be easily exceeded in power and versatility, and that's what I want to see in Affinity Designer. Hopefully, that's what the eventual goal is (perhaps after sorting out the problems associated with the present sub-par expanded stroke results).
But it is disconcerting that the current brushes are called "vector" brushes. That doesn't suggest that what you (and I) would call "real" vector brushes are on the unpublished road map.
This is also why I am so very disappointed in the merely "me, too" treatment of arrowheads. I am convinced that a truly innovative implementation of what I call path stokes and path ends that could be combined into user-defined path styles could yield both a much more powerful "arrowheads" feature and a vector-brush feature more powerful, versatile, intuitive, and elegant than Adobe's treatment.
It would be a true game-changer even for long-time AI users who have never really discovered the kind of brush-based applications I'm talking about, just because Adobe's treatment is too "standalone" as opposed to being truly integrated with its own preexisting features of the program.
That is what I see as the core of potential advantages over Illustrator: The fact that it is a decades-old stack of newer features merely "bundled with" a bunch of outdated basic features. I see that opportunity diminish whenever I see a feature implemented in a mere "me, too" fashion, as is arrowheads.
JET
 

The "old model" is clinging to absurd prices for mediocre 2D graphics software as if the "desktop publishing revolution" of the mid-80s is still in bloom. It isn't rocket science anymore. That's another example of Serif's innovation with the Affinity line.
JET

But Mac only. So—to appropriate the claim cited by every forum visitor angrily demanding a specific timeline for any given specific pet feature—"it is of no use to me."
Just as one could do with most any other vector-based program to which one is habituated. For example, those who are really convinced Adobe Illustrator's is the envelope distortion to beat all envelope distortions, can export their paths to Illustrator, warp them, copy them back to Affinity. One could do the same with Canvas, Draw, Inkscape…anything with a reasonable exchange format path for Bezier curves. All as a workaround, of course, until Affinity has its own (hopefully better, more elegant, more innovative) warp feature.
Why bother? Because enduring occasional workarounds gives you the advantage of developing proficiency in other and newer programs, thereby reducing your mission-critical dependency upon a specific software brand and the trauma of making a cold turkey "switch" when the time comes. That's how one avoids—or at least minimizes—falling victim to every machination of a single vendor.
No, that is not practical for every feature and function. One cannot, for example, work around Affinity's infernal overdone bounding-box fixation, because that is something you must deal with the whole time you are working in the program. But more "standalone" functions like distortion effects or (gag me) auto-tracing are quite amenable to a little back-and-forth between separate programs.
Example: Remember the days when a separate utility program called Type Styler was the de facto "standard" for any kind of text warping, before the Big Four had such features?
JET

Fixx,
Read the initial post in this thread. As I understand it, It's about pressuring Serif, not users, to license Astute Graphics's code in order to add it to Affinity's standard feature set, not necessarily as a plug-in. That is very specific. None of us on the user side knows how that kind of back-end deal between Serif and Astute Graphics would actually translate to us or our wallets or to the future development direction of Affinity.
This is not the same thing as a general request for Serif to add a plug-in architecture to Affinity like those in other drawing programs, so as to turn it into a platform that encourages any third-party commercial developers who want to, to create add-on plug-ins bought separately by users who want them.
As mentioned earlier, I consider it folly to develop habituated dependency upon third-party plug-ins, especially for freelancers. That's why my 'user vote' for that would be no. I'd rather Serif focus on truly elegant innovation in 2D vector-based drawing.
On the other hand, I would very much favor Serif's developing a scripting object model to empower users to create (and share, if we wish) our own functionality using a non-proprietary scripting language like JavaScript—when the time is right for that. That's something I would definitely use. But that is an entirely other subject from the matter of Serif making a specific back-end agreement with a specific plug-in developer to license incorporating that developer's code into the standard feature set of the program, which we would all then be paying for, whether we want it or not.
And I agree with those who have opined that it is rather inappropriate for that developer to be using this Affinity user-feedback forum as a platform to foster demand for whatever that private business agreement between Serif and Astute Graphics might actually entail.
JET

I've made my living in graphics since 1972. In using graphics software ever since its advent in the mid-80s. Two things I've learned to avoid like the plague, and will not tolerate:
Mission-critical dependency upon rented software. It's all for the vendor. What business wouldn't want to have its customers' work effectively held hostage by a continual rental payments scheme? Mission-critical dependency upon third-party plug-ins. To my mind, this pie-in-the-sky software model failed long ago. Users should counter the preached 'merits' of rented software licenses by pushing its claims to their logical conclusion: Why shouldn't we demand to only pay rent based upon the actual time the software is used instead of by the calendar?
JET

My interest in true vector-based brushes is not to emulate 'painterly' strokes, but to more powerfully leverage the base purpose and advantage of vector-based drawing in the first place.
As always, this is definitely not exactly what I have in mind, because I want something better.
Shown are just two of my own Pattern Brushes collections; hex head bolts and springs. Each Brush can turn a single-segment straight path into a bolt or spring of any diameter and any length with a single click.
However, building such constructs is much more tedious than it should be for several simple reasons:
Note that I have a separate Brush for each orientation (5° increments of rotation about an isometric axis). What makes all that setup work necessary boils down to a couple of simple geometric transforms that could and should be built into the Brush feature's options. (Think of the parameter adjustment handles in Affinity's various live Shapes for a general idea of what I'm talking about.) A better implementation would make this whole array possible with just 2 brushes instead of with 36. Note that the size of Illustrator's vector brushes (therefore, the diameter of the bolts) is controlled by adjusting the stroke weight setting of the spine path. But there is no option for leaving the stroke weight of its Brushes' base artwork alone. So in order to have consistent stroke weight in an overall drawing that has multiple differently-sized bolts or springs, one has to 'Expand' the 'Appearance' and then apply previously-defined Styles. This is a typical example of Illustrator's failure to integrate separate features with each other. Illustrator's Symbols do provide the much needed option to toggle off "Scale Stroke Weight When Scaling". So why isn't that option provided in its vector brushes? And why can't Symbols be uses as the base artwork in Brushes? Again, these are just two such collections. I have similar vector-based Pattern Brushes for "lasso arrows",  insulated wires with color banding, wire rope, wire loom, square tubing, piping, and more. To someone who does a good bit of technical drawing, the tedious bother is 'worth it' in the long run. But it could be done so much easier for users with a better thought-out implementation. Just more 'low hanging fruit' opportunity to beat Illustrator, rather than just mimic it.
 

 
JET

Nonsense. Since when is merely specifying a line by length and angle or drawing to user-defined scale only for 'CAD tools'? Egads, man, by that kind of logic, no 'CAD tool' should be able to colorize a vector object, either. Do you know why it's called a Bezier curve, and what industry Mr. Bezier was working in?
Mainstream vector drawing programs are very general-purpose. They are not just used for loosey-goosey freehand scribbling in an ill-conceived attempt to emulate 'natural media' on a tiny cell phone screen with a pudgy finger. These programs are routinely used for:
Cleaning up and augmenting CAD exports to make them suitable for commercial-quality reproduction Drawing die cuts for commercial collateral and package design Drawing garden plats Maps of all kinds Typeface design Bird's-eye views of theme parks for visitor's brochures Conceptuals and working drawings for commercial signage, storefronts, interior designs, point-of-sale displays, billboards Cutting paths for sign vinyl plotters and routers Architectural concepts Trade show displays and booth sites, both as conceptual renderings and as final working drawings All manner of info graphics And, yes, axonometric drawing (assembly diagrams for everything from colorful pre-school toys to mundane light fixtures) …I could go on indefinitely. Since the mid-80s I've been using FreeHand, Canvas, Draw, Illustrator, Flash, and most others that have come along in this software category since then to do these kinds of things, all of which are squarely within the real world domain of profitable commercial illustration.
JET
 

Regardless, the request for a hairline stroke weight setting is valid. (It's been brought up before in other threads.)
For those not familiar, a hairline stroke weight always renders at the smallest width possible on the output device, be it your monitor or an imagesetter. This is advantageous when drawing paths in detailed illustrations, during which we are constantly zooming in and out. Having stroke weight set to hairline feels more precise and is less distracting because the stroke weight is always drawn the same, regardless of zoom. The extreme zooming capabilities of Affinity as compared to other programs buttresses the point.
It's a great feature, a standard setting in PostScript, and it should be provided in every vector drawing software.
JET

Something I hope all would consider: The intents (and therefore requirements) of distorting type, as opposed to general artwork.
I grew up working in sign shops, long before the advent of digital type. (I'm proud to say I can still twirl a lettering quill.)
The trouble with automated pre-set envelope distortions as usually implemented is that they treat type the same way they treat any other vector paths, when usually it shouldn't be.
I'm not talking about deliberate effects like the water-drop examples. I'm talking about the ubiquitous things like curving what is supposed to read like normal text around circular emblems, the ess-curved "flag" baselines, the 'hero' headlines, and especially the whole plethora of attempts to emulate retro signage styles. The result, more often than not, is really amateurish adulterations of good type.
All those classic treatments of type are why software since the earliest days, long before vector envelope effects in every drawing program, have been separate features implemented as options for live type-on-path objects, especially the one called various names like "Vertical" or "Skew."
The good thing about that very important treatment is that these things are maintained, as they should be:
The proper "uprightness" of the glyphs The straightness of their vertical strokes The proportion of horizontal strokes to verticals The only bad thing is that the straight horizontals of the glyphs skew, but remain straight.
Typical general-purpose envelope distortion features know nothing of this.
That's why I'd like to see an envelope distortion that knows when it's dealing with type, not just random vector paths. Implementing it as a separate type-specific envelope feature wouldn't hurt my feelings a bit.
JET

As in many features, the devil is in the details. And again: just because Illustrator dominates the market segment does not necessarily mean it is the program to emulate. Typically, Illustrator new features seem to be designed more for an initial "wow factor" when introduced, than thoroughly thought-out. Its first introduction of a warp tool was a case-in-point, which then cascaded down to other subsequently introduced distortion features. Those devilish details can make all the difference between just another "me, too" copycat feature and an elegantly more powerful implementation.
When Illustrator finally got around to having an enveloping tool, its primary historic rival, FreeHand already had one. There was a subtle difference: In FreeHand, the user had control over whether or not the envelope, when initially applied, already had its node curve handles extended.
This "tiny" interface detail made all the difference.
I dare say the simplest, most basic, and therefore most common use for a warp effect is to simply distort the rectangular envelope of a selection by independently moving its corners so as to make the content artwork fit a surface in the illustration that is viewed at an angle; like simply putting a graphic onto the side of a drawn box or monitor screen that isn't viewed "straight on."
That was a simple, straightforward, few clicks in FreeHand. It was a tedious nightmare in Illustrator. Why? For one simple reason: Illustrator's envelope insisted upon being created with its nodes' curve handles already pre-extended by the rule-of-thumb 1/3 length of the segments. In FreeHand, the user was provided control over that.
That was commensurate with a preceding interface superiority in FreeHand: Its provision of auto-retract and auto-extend options which did not appear in Illustrator until much later and which, as usual, still fall short of FreeHand's implementation due to other pre-established "underlying foundations" of the interface. Specifically, it was related to the fact that FreeHand "knew the difference" between paths' being selected at the object level as opposed to merely having all of its individual nodes selected. That engrained foundational inferiority plagues Illustrator to this day, being directly related to Illustrator's now almost universally mimicked interface convention of having two separate primary selection tools.
So thanks, Mithferion, for starting a forward-looking feature discussion thread, as opposed to the pandemic "I want this feature [ just like the only program I've ever used has] and I want it now!" demands. We need more of this. It's what could lead to more powerful innovation instead of just more same-old, same-old mediocrity (like—I hate to say—the frankly disappointing arrowheads feature).
JET

Amazing that an ex-user still have so much time to whine about the software you don't want to use. Of course there are things Affinity does not do as well as some would like. But no one is forcing you to use it and no app is for everyone. I miss some things in Affinity too, but for me as a whole it has giving me a lot and I like to use the apps, despite some shortcomings. If you want more advanced vector support but not illustrator, just try Vectorstyler. This is an app with great potential, and many of the features Affinity users request. Despite that the UX is still better with Affinity so its only a side gig.

Regardless, the request for a hairline stroke weight setting is valid. (It's been brought up before in other threads.)
For those not familiar, a hairline stroke weight always renders at the smallest width possible on the output device, be it your monitor or an imagesetter. This is advantageous when drawing paths in detailed illustrations, during which we are constantly zooming in and out. Having stroke weight set to hairline feels more precise and is less distracting because the stroke weight is always drawn the same, regardless of zoom. The extreme zooming capabilities of Affinity as compared to other programs buttresses the point.
It's a great feature, a standard setting in PostScript, and it should be provided in every vector drawing software.
JET

Again, a topic conjures up fond memories of FreeHand.
FreeHand had just one kind of text object. It could be set to auto-expand horizontally (i.e., becoming functionally equivalent to a so-called "art text" object in other programs) by simply doubleClicking the right middle handle. It could be set to auto-fit its contained text vertically by doubleClicking its bottom middle handle. The text objects could be bound to and released from paths (instead of being treated as a separate "path text" object). They could be threaded, whether bound to a path or not. They could be set to auto-expand when bound to a path, thereby preventing the problem of accidentally truncated text in complex maps, as is so chronically common in maps built in Illustrator.
This is conceptually parallel to the fact that FreeHand also never had any need for two separate selection tools. Its single selection tool enabled you to edit paths at the whole object level and at the node editing level. That elegant interface design made path drawing far less tedious, more fluidly efficient, and more powerful than any drawing program that insists on following Adobe's hideous model of two primary selection tools.
Macromedia finally gave in to ill-advised "demand" from Illustrator users to add a second pointer tool. When added, it provided absolutely no additional functionality. It was literally nothing but an accommodation to Illustrator-habituated users who just refused to learn that it was absolutely unnecessary. FreeHand users simply ignored it. It was not until FreeHand's very last version that its white pointer did anything that the black pointer didn't, and even that was a minor detail that could have been implemented without adding another tool.
Despite Illustrator's two selection tools (three, really, when you include the ill-conceived "Convert AnchorPoint Tool")--actually because of it--Illustrator to this day does not "know the difference" between a path being selected at the object level versus merely having all its AnchorPoints selected. This causes all kinds of silly inconsistencies such as being unable to use the Break Anchor Point command when all of a path's Anchor Points are selected. (You have to unintuitively de-select at least one Anchor Point for it to work.)
Because object selection is so bedrock foundational to an object-based program, its tedious effects "cascade upward" throughout the program's interface. In a nutshell, it's what makes working in Illustrator feel as frustrating to beginners as trying to eat spaghetti with a single chopstick.
It's because Illustrator's white pointer behavior is conceptually "upside down" from intuition. It's the selection tool you have to use to edit a path.  But its first click always selects the most "internal" sub-part element of whatever construct you are trying to manipulate. Rather than intuitively selecting an object of interest and then "digging down" to its subparts with subsequent clicks, Illustrator's scheme first selects some "molecule" of the object of interest and requires use of a modifier key and subsequent clicks to "back out" of it to each next higher level.
It's metaphorically like getting up in the morning and needing a pair of socks. So you intuitively try to open your sock drawer. But your hand passed right through the closed drawer, and the only thing you can grab is a single thread of a single sock. So you have to then use both your hands to select a single sock, and grab again with both hands to grasp the folded up pair. All this "Bizzarro World" behavior instead of simply opening the drawer and grabbing the pair of socks.
The beginning of the end of FreeHand was not the Adobe acquisition. It was when it started to emulate Illustrator's hideous interface.
Unfortunately, because things like selection tools and text objects are foundational to the program built upon them, I'm sure it's too late to back-track the existing conventional-wisdom (i.e. "like Illustrator") in either case. But I say again: If you want to build a better drawing program, Adobe Illustrator is not the program to emulate.
JET

But why only the midpoint of a segment? What if I want to snap to thirds of a segment? Or divide a segment into fifths.
An Add Nodes Per Segment command would enable one to create snap candidates at any fractional increment along a segment.
JET