JET_Affinity

Application-specific formats are proprietary and subject to change at any time. (Ask anyone dealing with AutoCAD formats.) It's unrealistic to expect software vendors to match, object-for-object, construct-for-construct, the proprietary formats of their competitors. That's why open exchange formats exist, and robust compliance with those is what should be the responsibility of the competing vendors.
Do you also pressure Adobe to make Photoshop seamlessly export live text objects to Affinity Photo and Affinity Designer? No. Why? Just because Photoshop currently dominates the market. And yet you say you "hate Photoshop." Well, the object of your hatred will never stop dominating the market if everyone keeps insisting that everything else has to perfectly conform to it.
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

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

One can make a list of "deal-breaking missing features" which make it "impossible to switch to" any given drawing program. Guess which program is missing these essential features:
Live shape primitives Dimension tools. Connector lines. User-defined drawing scales. User-defined diagonal grids. Ability to key multi-operator math expressions into value fields. Find/Replace a simple carriage return. Text frames that can be set to auto-fit their content. Proper paragraph rules. ...and much more. Yep. Adobe Illustrator (at least as of CS6, the last version available as a traditional perpetual license).
Whether they realize it or not, just as users of other programs do, Illustrator users have continually limited their needs to the capabilities of Adobe Illustrator every day by working around its limitations. But they do so all the while proclaiming it the "professional industry standard" which serves "99% of users needs" by which anything else has to be measured and found lacking if it doesn't mirror every feature in every detail.
Features versus user's needs; which is the chicken and which is the egg?
But wait! There's a third party plug-in, say CAD Tools,  that saves the day by providing the functional sophistication that should be standard in the overpriced program in the first place, and that costs as much as or more than the host program.
I'm not knocking CAD Tools. But instead, one can pay half as much for a competitive side-grade to, say CorelDRAW Suite, and gain:
The needed functionality in a cleanly-integrated standard feature set instead of tagged-on runaway tool glut. A plethora of additional software and assets. Hand's-on knowledge rather than mere hearsay when presuming to "compare" competing programs. "Most popular" does not necessarily equate to "best." It often just means most ordinary.
JET
 
 

Not when, say, 50% of a given user's needs happens to be illustration destined for screen imprinting on garments by means of multi-channel spot color separations, for just one example.
It's silly to make these blunderbuss "program A is better than program B" pronouncements. Affinity Designer is already "better than" Adobe Illustrator if you have an essential need, for example, to specify dimensions by trig functions. Illustrator can't do that. Adobe Illustrator is still "better than" Affinity Designer just because of its Pattern Brushes.
All these programs have their own strengths and weaknesses. There is no law prohibiting anyone from using more than one vector drawing program.
A watercolorist doesn't choose his medium because it is "better than" oil paint. Nor vice-versa. Both painters simply exploit the characteristics and abilities of their preferred medium. No one really has to "wait" until Affinity Designer has each and every tit-for-tat feature that so-called "industry leader" (gag me) Illustrator has, before buying it and getting profitable and enjoyable use from it (especially at its price).
What ultimately wins in the marketplace is value and user experience (including customer relations). No one likes having their own creative files effectively held hostage by software rental schemes. Even if hades froze over and Adobe reversed that, the fact remains that the pricing model of all the old stalwarts dates back to the days of the game-changing desktop publishing "revolution." That old world pricing is now long outdated. When industries undergo radical changes people pay "whatever it costs." But then things stabilize, price efficiency is achieved, business models become more realistic, and the big players either adapt or fail to. In that struggle, they grasp at the customer base's tolerance in desperation to maintain their inflated status.  But 2D graphics software is not rocket science anymore.
I learned early on to avoid third-party plug-ins like the plague. To my mind, the whole plug-in thing is long ago failed. Maintaining version-parity is a pain. The vendors of them come and go. All the while they're too "vertical market" priced (the plug-ins often costing as much as or more than the host program itself). But moreover, I quickly found I didn't like developing business-critical dependency upon their volatility. I'm not sure I'd be crazy about how Serif's mission-critical dependency upon more third-party tech licensing might trickle down to me in the form of its products' pricing, capabilities, or interface elegance.
So yeah, I want to see multi-spot-channel accommodation in Affinity Photo. That doesn't mean I can't use it until I can "switch" to it because I'm somehow "required by law" to only know how to exploit the strengths of one program.
djjss,
I'm not the forum sheriff, but please post individual suggestions in their own threads, (and look for pre-existing threads on those topics) so that topics are organized and navigable. Specific-user "wish list" posts just become grab-bags of open discussions, as this one already has.
JET

I agree with a good bunch of those POVs. I handle a bunch of apps now.... (and plan to purchase even more, specially of painting nature). You make a very key point... Each project almost shouts for a particular tool, sometimes. Even if you manage to regularly do the global activity with, say, the same 3 or 2 apps for vectors and another 2 or 3 with raster, there are projects that seem to be ideal for an specific project. I'm doing a (happily) very long project that requires tons of line art illustration (hence am using CSP a lot) ... and in 3D, I could model almost equally with Blender or Wings 3D, but when it involves a lot of rendering, I end up doing most of it with Blender for less I/O, versus when is mostly heavy work in character modeling, I end up predominantly using Wings.... For me AD and AP are two "new" tools (in comparison with some more arcane apps), just way important for how complete they are, and the wide area they cover ( let's face it, the wider (if they work solid) it is, the safer for a full project) but doesn't collide with your fact: You can use different tools for different projects. Working at companies is very much like that, all the time).

While I agree in concept, it's worthy of some further discussion because this can be taken as another example of assuming that Adobe Illustrator is the end-all "leading' functionality worthy of being mimicked when, here at nearly one fifth of the way into the 21st century, we really should be aiming rather higher.
Not trying to be a know-it-all, but the following may be instructive to those...well, younger.
Like most vector drawing programs, Illustrator also started out with just the four basic Boolean path combination operations (add, subtract, intersect, exclude), and as I recall, it didn't move beyond that until around version 9 or 10, when its so-called "Live Effects" became all the focus. That's when Illustrator's so-called "Pathfinder" functions became (by default) its so-called "Compound Shapes" (which, in typical Adobe fashion, creates untold confusion with the term "compound paths"; an entirely different thing).
Affinity Designer also provides the four base Boolean path operations, and they are also already "live" constructs.
In Illustrator's case, it was actually user reaction against "Compound Shapes" (the "Live Effect" behavior) being the default that finally reversed the default so that the "Live" behavior requires the modifier key.
Regarding the Merge Pathfinder in particular:
Illustrator's Merge Pathfinder cycles through the selection in its stacking order and performs Boolean subtract on paths with differently-colored fills (which Mintcar's screenshot depicts). But its differentiating aspect is that it then cycles through the results and performs Boolean add on any adjacent same-color fills (which the screenshot does not depict).
This is indeed a very useful time-saving feature, especially when designing for rather involved instances of purposes like cutting sign vinyl and stencils, or screen printing. So yes, when priorities get around to elaborating the Boolean operations already in Affinity Designer, something similar to Illustrator's Merge would be valued. But for decades prior to its appearance, we did what Merge does by simply performing Boolean subtract, followed by Boolean add.
As in almost all such comparative requests, there remains much to be desired, and we should aim higher than "like Illustrator."
For purposes to which Illustrator's Merge is most beneficial (and thereby worth of a separate command), a degree of overlap is commonly, if not usually, needed (similar to separation traps in offset printing terms; but more like offset path commands in vinyl and screen printing). To make Illustrator's Merge feature something rather more special than just doing color-specific Boolean subtract followed by Boolean add, it should have also been provided a simple field for an offset value.
Illustrator's Merge also suffers from the same problem which has always plagued its Pathfinders (and other things like its Knife Tool): It doesn't know what to do with strokes. Whenever Pathfinders have this problem, strokes are just removed. Even before the advent of so-called "Live Effects," competing programs did not have this problem. FreeHand, for example, simply kept strokes as strokes (which, if one thinks about it, is also a "live effect") in the results of its Boolean path combinations (and its Knife Tool correctly cut all paths, open, closed, filled or unfilled).
Illustrator provides multiple features which essentially do the same thing, and add to its overall clutter. While sometimes useful, this is not elegant interface design. It's a better user experience when more "power" is provided "just under the hood" of more fully thought-out and better-integrated functionality of relatively fewer tools.
In this context, I'm not sure that greater path combination functionality couldn't be accomplished as part of a user-friendly scripting or macro implementation.
Given that, as explained, Illustrator's Merge button is, in effect, a "macro" that performs two base Boolean operations (subtract, add) in one move, with the caveat that the operations are color-specific, consider:
Wouldn't the "missing" overlap value field also be valuable for the normal subtract function? Wouldn't all the Boolean operations benefit from an option to set a conditional constraint, such as same or different color?
So Boolean path operations represent yet another opportunity for Affinity to break beyond and rise above the conventional-wisdom treatment, providing greater power with less "feature glut."
JET
 

While I agree in concept, it's worthy of some further discussion because this can be taken as another example of assuming that Adobe Illustrator is the end-all "leading' functionality worthy of being mimicked when, here at nearly one fifth of the way into the 21st century, we really should be aiming rather higher.
Not trying to be a know-it-all, but the following may be instructive to those...well, younger.
Like most vector drawing programs, Illustrator also started out with just the four basic Boolean path combination operations (add, subtract, intersect, exclude), and as I recall, it didn't move beyond that until around version 9 or 10, when its so-called "Live Effects" became all the focus. That's when Illustrator's so-called "Pathfinder" functions became (by default) its so-called "Compound Shapes" (which, in typical Adobe fashion, creates untold confusion with the term "compound paths"; an entirely different thing).
Affinity Designer also provides the four base Boolean path operations, and they are also already "live" constructs.
In Illustrator's case, it was actually user reaction against "Compound Shapes" (the "Live Effect" behavior) being the default that finally reversed the default so that the "Live" behavior requires the modifier key.
Regarding the Merge Pathfinder in particular:
Illustrator's Merge Pathfinder cycles through the selection in its stacking order and performs Boolean subtract on paths with differently-colored fills (which Mintcar's screenshot depicts). But its differentiating aspect is that it then cycles through the results and performs Boolean add on any adjacent same-color fills (which the screenshot does not depict).
This is indeed a very useful time-saving feature, especially when designing for rather involved instances of purposes like cutting sign vinyl and stencils, or screen printing. So yes, when priorities get around to elaborating the Boolean operations already in Affinity Designer, something similar to Illustrator's Merge would be valued. But for decades prior to its appearance, we did what Merge does by simply performing Boolean subtract, followed by Boolean add.
As in almost all such comparative requests, there remains much to be desired, and we should aim higher than "like Illustrator."
For purposes to which Illustrator's Merge is most beneficial (and thereby worth of a separate command), a degree of overlap is commonly, if not usually, needed (similar to separation traps in offset printing terms; but more like offset path commands in vinyl and screen printing). To make Illustrator's Merge feature something rather more special than just doing color-specific Boolean subtract followed by Boolean add, it should have also been provided a simple field for an offset value.
Illustrator's Merge also suffers from the same problem which has always plagued its Pathfinders (and other things like its Knife Tool): It doesn't know what to do with strokes. Whenever Pathfinders have this problem, strokes are just removed. Even before the advent of so-called "Live Effects," competing programs did not have this problem. FreeHand, for example, simply kept strokes as strokes (which, if one thinks about it, is also a "live effect") in the results of its Boolean path combinations (and its Knife Tool correctly cut all paths, open, closed, filled or unfilled).
Illustrator provides multiple features which essentially do the same thing, and add to its overall clutter. While sometimes useful, this is not elegant interface design. It's a better user experience when more "power" is provided "just under the hood" of more fully thought-out and better-integrated functionality of relatively fewer tools.
In this context, I'm not sure that greater path combination functionality couldn't be accomplished as part of a user-friendly scripting or macro implementation.
Given that, as explained, Illustrator's Merge button is, in effect, a "macro" that performs two base Boolean operations (subtract, add) in one move, with the caveat that the operations are color-specific, consider:
Wouldn't the "missing" overlap value field also be valuable for the normal subtract function? Wouldn't all the Boolean operations benefit from an option to set a conditional constraint, such as same or different color?
So Boolean path operations represent yet another opportunity for Affinity to break beyond and rise above the conventional-wisdom treatment, providing greater power with less "feature glut."
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

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

Securing PDF files is a feature that belongs in a PDF editor, I think; although it would be handy if we could export secured PDF files directly from the Affinity apps themselves.
I use the free version of PDF-XChange Editor to read, comment on and secure PDF files. The free version is quite capable, and placing security on PDF files is simple. https://www.tracker-software.com/product/pdf-xchange-editor
Open your Affinity generated PDF file in the XChange Editor, open the document properties (under FILE or use CTRL-D), and select the Security tab. Click the "Apply Security Policy" button, and add a new policy "Add New-->Password Security". In the dialog select a PDF compatibility (version 9 or later is best), and tick the "Restrict editing and printing..." checkbox. You must set a password. Then adjust the document's permissions as you require at the bottom of the dialog.
Finally, name your new security policy setting, and click OK. Select the new policy in the list, and hit "Apply to Document". You must then save the document.
The next time you just have to open the document settings, and click the "Apply Security Policy" dropdown button to select the security setting, and save your pdf.
Simple, and completely free! No Adobe rubbish! 
PS I LOATHE the Adobe Reader: it's one piece of garbage software. The free version of XChange Editor is far faster, leaner, and even the free version allows the user to add annotations/custom stamps, save these and change the security which we have to pay for to be able to do with Adobe Acrobat. Don't get me started how atrociously bad the Adobe Reader is.
 

...continued
"Reset" what? does it reset the shortcuts in focus or all? the manual says all customized, but a first time user, trying to find its way around the app will have to dig, and all it takes is that button to say "Reset all shortcuts to factory defaults" (or something on that line)
"Clear all shortcuts" ok this one is self explanatory.
7. the shortcut list itself...
a) c'mon, it's a list and it is restricted to show only 8 lines at a time it is wider than it is tall, and the window cannot be resized to see all items on the list :-D that's silly. I need to constantly scroll up and down this miniature list although I could dedicate a whole monitor for it, as I am unable to search for an item on it because the frickin' search bar is bonkers.
b) If I pick a new key that overlaps with existing combo, I get great little yellow icon telling me so, mouseover will give me the info, great. And now I need to go back to those two fiddly drop-downs fo find my way to the duplicate if I want to change it, why not give me an opportunity to solve this conflict here and now, by doublee clicking on the yellow icon or something.
Here is my suggestion for solving the Keyboard Shortcut preferences mess. Why not making a table with horizontally foldable categories of shortcuts (foldable like "Assets" sub categories) these categories would be "File", "Edit", "Text" etc.. First column would stay the same, that is, the description, Second column would show Draw persona shortcuts, third Pixel persona, fourth Export persona. It would make the features that are parallel across personas obvious, those that are non-existent in a certain persona would be "grayed out"  And make the preferences window resizable, please. That way we could edit our shortcuts many times more quickly, and enjoy the switch to Affinity apps much more.
Please, pardon my ignorance, as I am not a professional UI designer but a frustrated user. I have written this overly long post to try and make Affinity better. I have lost precious time and artistic inspiration because of the design of this window and decided to spend some more time, trying my best to alleviate the problem somehow.
Please try and read it with an open heart, as it was written in the best of intention.
 

I don't know if everyone is catching your meaning by the photo, since if one looks "straight at" the side of the bottle label, the text baseline would be horizontal.
But yes, being able to skew pathtype so that the vertical axis of the characters remains vertical as the path bends is every bit as important as simply rotating the characters with the path (the ubiquitous text bent around a circle).
I distinctly remember when FreeHand provided this and other drawing programs didn't, and the difficulty in explaining its importance to users of other programs.
Nowadays, many would no doubt argue that the vertical skewing option for pathtype is inferior to and rendered obsolete by envelope-based distortion features with the customary "arch" option (and the corresponding complaint that the vertical skew option for pathtype still keeps horizontal edges of the glyphs straight). But the typical "arch" envelope (as commonly implemented) is not the same thing, and the vertically skewed pathtype is a better starting point for things like the type treatments commonly seen in "retro" sign-painting.
JET

There is no need to couch this request in apologetic terms. The provision of proper transform tools is arguably even more important in Affinity Designer.
In fact, I found this post while searching for the subject (I thought) in the Designer forum, so as to not start a repetitive thread.
Transform tools should not be characterized as "dedicated  tools which can do only one thing" because they do too many crucially important things that merely bounding-box based transforms (whether in a transform palette or as bounding box handles) fail to do.
Just one example:
When an ellipse is used to represent a "tilted" (foreshortened) circle, its minor diameter should be aligned to its "thrust line" (the centerline about which the circle "orbits").
A common method for doing that is:
Mousedown on one of the ellipse's nodes. Drag the whole ellipse by that node to snap it to somewhere along an existing line of the drawing in progress (the thrust line). Set the center of rotation at that point of snapping intersection. Rotate the whole ellipse about the center of rotation by dragging another of its nodes and snapping it also to the thrust line. Those kinds of transforms are typically done with a single Rotate Tool that can:
Set the center of transformation with a single, snap-sensitive click. Snap to any detail of the selection. Rotate the selection by snapping that dragged detail to any unselected snap candidate. You can't do that with just bounding boxes when the detail that you need to drag and snap to other positions is not one of the bounding box's handles, which is by far more often the case in serious illustration. And the same principle is valid for page layout design, wherein the assumption also should not be made that everything that needs to be accurately transformed is not necessarily just corners of bounding boxes.
Affinity does let you set the center of transformation to anywhere. That is not the missing functionality. The problem is that, first, the transformation anchor is only available when the black pointer is active (in other words, when the current selection bounding box is displayed), and second, because the needed transformation can even then only be performed by manipulating bounding box handles, not by dragging snap-able elements of the selection.
In the Affinity Designer "1.7 sneak peek" thread, Ben posts a video clip of upcoming functionality for performing transformations on sub-selections of Nodes. But so far as I can tell, that video clip still exemplifies the same problem, because it still just draws a bounding box around those sub-selected Nodes, and all the transformations still seem to require manipulation of the infernal bounding box handles, not of the specific node(s) of interest.
If I'm right, and not just overlooking some esoteric keyboard shortcut or something, it's simply substandard in comparison to other drawing programs. It is seriously debilitating of the work toward drawing with accuracy in the Affinity apps.
I'd love to be wrong about this.
JET
 

There is no need to couch this request in apologetic terms. The provision of proper transform tools is arguably even more important in Affinity Designer.
In fact, I found this post while searching for the subject (I thought) in the Designer forum, so as to not start a repetitive thread.
Transform tools should not be characterized as "dedicated  tools which can do only one thing" because they do too many crucially important things that merely bounding-box based transforms (whether in a transform palette or as bounding box handles) fail to do.
Just one example:
When an ellipse is used to represent a "tilted" (foreshortened) circle, its minor diameter should be aligned to its "thrust line" (the centerline about which the circle "orbits").
A common method for doing that is:
Mousedown on one of the ellipse's nodes. Drag the whole ellipse by that node to snap it to somewhere along an existing line of the drawing in progress (the thrust line). Set the center of rotation at that point of snapping intersection. Rotate the whole ellipse about the center of rotation by dragging another of its nodes and snapping it also to the thrust line. Those kinds of transforms are typically done with a single Rotate Tool that can:
Set the center of transformation with a single, snap-sensitive click. Snap to any detail of the selection. Rotate the selection by snapping that dragged detail to any unselected snap candidate. You can't do that with just bounding boxes when the detail that you need to drag and snap to other positions is not one of the bounding box's handles, which is by far more often the case in serious illustration. And the same principle is valid for page layout design, wherein the assumption also should not be made that everything that needs to be accurately transformed is not necessarily just corners of bounding boxes.
Affinity does let you set the center of transformation to anywhere. That is not the missing functionality. The problem is that, first, the transformation anchor is only available when the black pointer is active (in other words, when the current selection bounding box is displayed), and second, because the needed transformation can even then only be performed by manipulating bounding box handles, not by dragging snap-able elements of the selection.
In the Affinity Designer "1.7 sneak peek" thread, Ben posts a video clip of upcoming functionality for performing transformations on sub-selections of Nodes. But so far as I can tell, that video clip still exemplifies the same problem, because it still just draws a bounding box around those sub-selected Nodes, and all the transformations still seem to require manipulation of the infernal bounding box handles, not of the specific node(s) of interest.
If I'm right, and not just overlooking some esoteric keyboard shortcut or something, it's simply substandard in comparison to other drawing programs. It is seriously debilitating of the work toward drawing with accuracy in the Affinity apps.
I'd love to be wrong about this.
JET
 

Regarding the axonometric grids and ruler origin reset:
Hopefully before these two related sneak peek features reach a customer beta stage (in which feature schema and behavior is mostly already committed and focus is mostly just on bug testing), I want to throw this out, so I can sleep at night:
Having been doing isometric drawing since the days of drawing "on the board" before desktop computers, I dare say you won't find anyone more enthusiastic about adding some geometric intelligence (other than just snapping) to the plane grids (more akin to DrawPlus). Such grids are a great way to introduce commercial illustrators without prior experience to axonometric drawing.
So don't think it contradictory when I say this: In all those decades, frankly, I have never met a fellow serious axonometric illustrator who is highly dependent upon grids; neither before the advent of graphics software nor since. Here's why:
There is a fundamental concept which the trivial "isometric grid" features in mainstream drawing software typically gets completely "backward":
As usually implemented, grids make your drawing conform to the grids, when the grids should be adapting to the drawing.
Grids tend to force your drawing to conform to the increments of the fixed grid. That's fine for "fantasy" drawing like, for example, bird's eye view game artwork wherein the actual dimensions and spacing of whatever "boxy" shaped things you are drawing are entirely up to you. But in real-world technical drawing, it's not about just drawing conveniently "boxy" things, and it's not about making your drawing measures conform to a fixed grid; it's about having a set of freely moveable and correctly proportioned angled rulers which enable you to make correctly-scaled measures from any point in your drawing.
In pre-computer days, the only time you saw a tech illustrator using a grid was when he was away from his drawing board (or when his drawing board was not equipped with a track drafter). Newbie illustrators would sometimes use a printed axonometric grid under a sheet of tracing paper. And guess what: He would be constantly moving the grid around under his drawing sheet.
A technical illustrator is not the least bit concerned with measures incremented from any page origin. He's constantly gliding his properly-angled rulers to make measures from pre-existing points in his drawing.
If grids are to serve as the rulers for axonometric drawing, they need to be able to act like rulers and freely follow the cursor, not be stuck to any page origin. The origin of the grids (the intersection point of the three planes) needs to be able to snap to any snapping candidates in the artwork, completely free from interference from a page layout grid.
This is essentially why no grid-based approach has ever really matched the quick, easy, intuitive fluidity of a physical drawing table equipped with a mechanical track drafter. The closest software emulations of the fluidity of the physical tools metaphor are not grids, but three proportional rulers (axes) which follow the cursor, as in some 3D modelers.
But axonometric drawing is, by definition, a 2D construction method historically performed on a 2D sheet of paper. So there's no reason a similar interface could not be provided in a general-purpose 2D illustration software, based on 2D geometry.
JET

I have been playing with APBeta for an hour or so and it already feels comfortably familar in use.
I have worked out that I can open old PDFs of InDesign docs and convert them to native format with a little work setting up the text styles etc. and I am using one of these files as my tester for the program. As it has a fairly complex text layout and many images it should be fun.
I have been (Commercially and Privately) an InDesign user since before it was born (when it was Pagemaker) and I am feeling I will soon be able to say 'ex-user'.
Of course, I am having one or two small problems with some of the things I am used to doing a certain way, but I will learn!
My overall impression so far is that, even in Beta, this is the program I had hoped it would be. At long last a valid and, more importantly, affordable alternative to Adobe's money-pit software.
Congratulations all involved - I've not been so excited about a new program since... well ever really.

But that is an unrealistic expectation. For example, you can't even provide an "end user editable" Adobe Illustrator file and "know that [the recipient] can make any necessary changes in Photoshop." Illustrator can't "seamlessly" open an Adobe Fireworks or an Adobe Flash file and "make any necessary changes" nor vice-versa.
Are you aware that Adobe InDesign can neither open nor even import native Adobe Illustrator content? It can only import the PDF content that is stored within the Illustrator file. You can try this yourself. Simply save an Illustrator file without turning on the "Create PDF Compatible File" option, and then try to import it into an InDesign file. Turning that option on merely tells Illustrator to create a PDF of the entire file's content and then include it within the supposed "Adobe Illustrator" file.
File exchange between raster imaging programs has always been more "seamless" because, when it comes down to it, a raster image is a simpler construct; basically just a rectangular array of pixel color values. And since the beginning, their cross-application exchange has been accomplished by means of cross-application raster formats (.TIFF, .GIF, .JPEG, PNG, etc.)
Vector-based graphics program (drawing and page-layout) files are collections of individual, independent objects. (vector based paths, raster images, live text, and various proprietary constructs which combine and elaborate upon those objects). So unlike raster formats, there was no plethora of cross-application open exchange formats. (This is a large part of why vector-based graphics has been so long and slow in coming to the web.) There was only PostScript (EPS); basically an uneditable "locked box" which the importing program could just pass along to the printer. And not all drawing programs created PostScript output, and not all of those that did were actually full-blown PostScript interpreters.
So vendors of vector programs had to sort of "reverse engineer" their own import filters so as to claim to "open" (dissect and try to convert) competing files. And that has never been perfect, and still isn't; not even between different programs from the same vendor, because all such programs create native constructs which the other programs don't understand. For just one of many examples, both Adobe Illustrator and CorelDraw provide path Blends. But that doesn't mean they are identical constructs. Both programs claim to "open" the other's files. But in either direction, the Blends are often dumbed-down to just stacks of individual paths with no "blend" functionality. Similar issues occur with other proprietary constructs.
It's the same way with CAD/CAE programs. You don't directly "open" a native Solidworks file with, say, AutoCAD; you export the Solidworks file to an exchange format, and then open that exchange format file with AutoCAD. And much is lost in the "translation."
But today there are at least a few standardized open exchange object-based formats which the various vendors can choose to implement (primarily PDF and SVG), and Affinity supports both. But even of these, PDF is not actually intended to be an editing format. And with either format, full editability at both ends of the exchange is far from "seamless" in terms of native round-trip editing, because the exchange formats do not fully support all of the native editing constructs of all the programs that use them.
That doesn't mean one can't use multiple drawing programs in the same workflow. But you have to be aware of the limitations and devise your workflow accordingly. It's always been that way anytime you try to share files between competing products, and Affinity is not to blame for that.
JET

So who says you have to "switch"?
If there were things I absolutely had to be able to do that I simply could not do without Illustrator, then  obviously, I would have to use Illustrator for those things. There aren't, and I don't. But even if there were, how does that preclude my using Affinity, Canvas, Draw, DrawPlus, Gravit, Inkscape, Xara Designer for many (or even most) other things? (It doesn't, and I do.)
The way so many people in the vector drawing segment talk, one would think there is some law that you can only use one drawing program. If there is, I've been breaking that law since the beginning of the "desktop graphics revolution."
It's not so much that way in other graphics software genres. Drafters, game developers, video producers, photographers--you name it--commonly use multiple programs and routinely switch between them, even sometimes within a given project.
Illustrator has a few features unique to it. But that's just as  true of all the others. I quit paying for Adobe apps as soon as the rental-only license scheme was announced. The money I was  paying for Adobe software until version CS6 pays for most of the other graphics software I use.
Illustrator has been around since the mid 80s, and it still fails to provide dimension tools, user-defined drawing scale, support for full multi operator expressions in value fields, proper shape primitives (what is more basic than that?), connector objects, a full-featured find and replace, axonometric grids, hairline stroke weight, and much more. Evidently, that didn't keep many of its users from "switching" to it in search of the mythical "do it all" program.
I'm sorry, but those with this oft-repeated "I still can't switch" complaint are simply habituated to Illustrator's convoluted, confused, scattered, cluttered interface; and not just to its abilities, but also to its limitations. Logically, it makes about as much sense as would my complaining that I can't "switch" from my table saw to my jig saw.
I can't "switch" from my dualsport motorcycle to my trials bike. Heck, I can't even bring myself to "switch" between my two trials bikes (one a 2-stroke; the other a 4-stroke).
In the drawer next to me, I have these ostensibly "do it all" multi-tools:
The original Leatherman (the one with the full-size pliers) A Leatherman Juice (a more compact one with pliers) A Leatherman Micra (more compact still, but has a really good scissor) A Victorinox Sailor (even has a splicing fid!) An early Craftsman (has a hex bit socket) … and others.
I sometimes prefer one over the others, depending on whether I'm on the dualsport, the trials bike, the sailboat, or just fiddling around the house. But the one by far most often in my pocket is hardly the one most "fully equipped": A pretty standard medium size Victorinox, because it has the all-important (to me) T-handle Philips, pliers (albeit tiny), and tweezers; and because it doesn't have a stupid, useless corkscrew.
But be it shop tools, motorcycles, pocket knives, or drawing software, if I suddenly had to rent any one of them to keep using it, it would be gone in short order. And I'd do just fine without it.

JET

Ygoe, no one is suggesting that. Deeds said:
Again, as I explained at length, even Adobe Illustrator's Arrowheads are stored as ordinary symbols; they just reside in a separate file that has to be awkwardly accessed in order to customize them or add to them. That separate, ordinary .ai file (rather crudely, as implemented) serves as an app-level "library" to populate the arrowheads popup menus in the Attributes palette. (Illustrator does the very same cumbersome hack with bevel profiles for its 3D Effect plug-in.)
No one is suggesting that every Affinity user should have to draw their own arrowheads from scratch. The program would be assumed to ship with practical collections of pre-built Symbols libraries, just as other features (brushes, swatches, patterns, etc.) are typically pre-populated.
For technical illustration, I would even favor having such pre-built arrowhead symbol libraries that conform to the several mechanical drafting standards. But even if those were not provided with the program, there would be nothing stopping an enterprising Affinity user from creating and distributing them.
There would be nothing lost in the functionality of ordinary traditional arrowheads as a result of cleanly integrating path strokes, ends, brushes, symbols, and graphic styles for far greater and more versatile functionality instead of effectively implementing them as yet another lame collection of seemingly isolated, standalone, single-purpose features. As Illustrator demonstrates, that "isolated" aspect has nothing to do with actual functionality; it's just due to the program's outdated, scattered, cluttered, and confused piecemeal interface design.
This is yet another area of huge opportunity for Affinity to surpass the archaic mediocrity of most other Bezier-based drawing programs.
JET
 

Ygoe, no one is suggesting that. Deeds said:
Again, as I explained at length, even Adobe Illustrator's Arrowheads are stored as ordinary symbols; they just reside in a separate file that has to be awkwardly accessed in order to customize them or add to them. That separate, ordinary .ai file (rather crudely, as implemented) serves as an app-level "library" to populate the arrowheads popup menus in the Attributes palette. (Illustrator does the very same cumbersome hack with bevel profiles for its 3D Effect plug-in.)
No one is suggesting that every Affinity user should have to draw their own arrowheads from scratch. The program would be assumed to ship with practical collections of pre-built Symbols libraries, just as other features (brushes, swatches, patterns, etc.) are typically pre-populated.
For technical illustration, I would even favor having such pre-built arrowhead symbol libraries that conform to the several mechanical drafting standards. But even if those were not provided with the program, there would be nothing stopping an enterprising Affinity user from creating and distributing them.
There would be nothing lost in the functionality of ordinary traditional arrowheads as a result of cleanly integrating path strokes, ends, brushes, symbols, and graphic styles for far greater and more versatile functionality instead of effectively implementing them as yet another lame collection of seemingly isolated, standalone, single-purpose features. As Illustrator demonstrates, that "isolated" aspect has nothing to do with actual functionality; it's just due to the program's outdated, scattered, cluttered, and confused piecemeal interface design.
This is yet another area of huge opportunity for Affinity to surpass the archaic mediocrity of most other Bezier-based drawing programs.
JET
 

Ygoe, no one is suggesting that. Deeds said:
Again, as I explained at length, even Adobe Illustrator's Arrowheads are stored as ordinary symbols; they just reside in a separate file that has to be awkwardly accessed in order to customize them or add to them. That separate, ordinary .ai file (rather crudely, as implemented) serves as an app-level "library" to populate the arrowheads popup menus in the Attributes palette. (Illustrator does the very same cumbersome hack with bevel profiles for its 3D Effect plug-in.)
No one is suggesting that every Affinity user should have to draw their own arrowheads from scratch. The program would be assumed to ship with practical collections of pre-built Symbols libraries, just as other features (brushes, swatches, patterns, etc.) are typically pre-populated.
For technical illustration, I would even favor having such pre-built arrowhead symbol libraries that conform to the several mechanical drafting standards. But even if those were not provided with the program, there would be nothing stopping an enterprising Affinity user from creating and distributing them.
There would be nothing lost in the functionality of ordinary traditional arrowheads as a result of cleanly integrating path strokes, ends, brushes, symbols, and graphic styles for far greater and more versatile functionality instead of effectively implementing them as yet another lame collection of seemingly isolated, standalone, single-purpose features. As Illustrator demonstrates, that "isolated" aspect has nothing to do with actual functionality; it's just due to the program's outdated, scattered, cluttered, and confused piecemeal interface design.
This is yet another area of huge opportunity for Affinity to surpass the archaic mediocrity of most other Bezier-based drawing programs.
JET
 

I applaud your use of  "line end effects" rather than "arrowheads."
It is so 1980s to think in terms of just arrowheads. As with other still-missing features, I very much hope that the reason for the delay is that the Affinity team has something far better in mind than the prevalent conventional wisdom.
Those who also follow Gravit Designer's (rapid, but sometimes too rapid) development know that it has been under a similar "must have" outcry for "arrowheads," and that it was just recently added. I have high regard for Gravit's  nobel effort to restore what has been for too long abandoned in vector drawing programs: interface elegance. But its obviously rushed-out-the-door arrowheads treatment is possibly the poorest I've ever seen. I sure don't want to see Affinity go that way due to unrelenting user pressure.
Paths have strokes and paths have ends. Nowadays, everyone expects (and rightly so) vector-based path stroke features to be far more elaborate than just the archaic basic color, weight, and end caps settings. Sadly, Illustrator's Pattern, Art, and Scatter Brushes (despite their needlessly overblown interface and lack of integration with other features) leads that functionality and is one of the really very few true advantages of that program.
All the while expecting more sophistication for path strokes, there seems to be a prevalent fixation on the archaic single-purpose use of "arrowheads" as path ends. Yes, arrowheads are a common need. But they are just a pointy-shaped vector graphic positioned at the end of a path and rotated to maintain tangency with the path's stroke. Thinking of "arrowheads" as a distinct feature needing its own interface is as archaic as thinking of dashes as something worthy of a standalone interface entirely distinct from other path strokes.
Even the conventional treatment of "brushes" misses the elegance mark. It's an example of how the typically-strained "natural media" metaphor breaks down. Like Illustrator, most programs have come to treat "Brushes" as an attribute. But in the physical media metaphor, a brush is not an attribute; it's a tool. A brush applies strokes, just as a pen or a pencil applies strokes.
Paths have strokes and paths have ends. Path ends should be every bit as versatile as path strokes (including so-called brushes). Both represent opportunity to exceed the functionality and disconnected non-integration with the rest of Illustrator's cumbersome, scattered, and grab-bag-like interface. Powerful as they can be when used with a little ingenuity, Illustrator's brushes are hamstrung by their stand-alone nature:
You can't simply use a Symbol as the "end tile" of a Pattern Brush. Why? You can set an option on or off to "Scale Strokes and Effects" for any ordinary object(s) in the document, but you can't set that for Symbols, strokes contained in Art Brushes, or strokes contained in Tiles of Pattern Brushes. Why? You can't simply assign a Symbol as a path end. Illustrator has its archaic separate Arrowheads setting. You can create custom Arrowheads, but to do so, you have to open a separate Arrowheads file, draw your custom "Arrowhead", and store it in that separate document as--wait for it--yes, a Symbol! You then quit the program, re-launch the program, re-open your document and now your "Custom Arrowhead" is available in the stupid separate Arrowheads popups of the Attributes panel. Arguably (albeit a stretch), Adobe may have somewhat of an excuse for this convoluted nonsense in that it is a very, very old program, so certain archaic aspects have to be perpetuated for the users' old files. But Affinity is new; it should be free of such backward constraints. I'll say it again: Market share be hanged. Adobe Illustrator IS NOT the program for anyone to emulate in creating a far better drawing program.
Nowadays, most programs provide a symbols feature. Path ends should be integrated with symbols. Any symbol should be able to be applied as a path ending. The interface for applying a symbol as a path end should include these options:
Setting the rotation angle of the symbol, and whether that angle is relative to the page or to the path. Setting the scale of the symbol (relative to how it is stored) and whether changing the path's stroke weight correspondingly affects the scale of its ends. Setting for whether or not strokes contained within the symbol's artwork are scaled. Most programs treat paths as having two primary attributes: stroke and fill. But they really have three: stroke, fill, and ends. It's way past time for someone to provide a modern, powerful, and elegantly integrated treatment of path ends.
JET

Integration. Another myth. Merely having the same brand on the boxes and selling them as a bundle does not make disparate softwares "integrated." Corel's suite is more functionally "integrated" than Adobe's. And clearly, functional integration between apps is part of the driving agenda with the Affinity line.
I think you need to differentiate what kind of "seamless integration" you're talking about if you insist on continuing this line of argument. When you're talking about "seamless integration" between different workers under different roofs actually editing the same files, workflow is of course more "seamless" if everyone is using the same software. But that would be true of any software. But not everyone works that way. No one modifies my illustrations but me. And I can "integrate" them into any "industry standard" publishing workflow with any of the drawing programs I use, via commonly-compatible exchange formats.
Look, I've been making my living doing this stuff since before Macs and graphics software. Throughout their competitive history, Aldus/Altsys FreeHand led Illustrator in functionality, often to the point of embarrassment. Even in those pre-PDF years, I was doing national level advertising and product collateral with FreeHand in the days when the claim of Illustrator devotees was that one "can't get files output at the service bureaus without using Illustrator." Those same single-program devotees rent their garments and proclaimed the coming of the apocalypse whenever anyone merely suggested that an Illustrator file should be able to have a "page 2."
Adobe is what it is (big) primarily because of one reason: PostScript. That was the baby that put Adobe on the map because it was the software half of the industry-changing "desktop publishing" equation in the 80s. That's how Adobe first acquired its mindshare. Many of its software products were acquired from other companies (and some of them wrecked).
It takes a while for users to get over their fear of learning new and different software, but times do change. And Adobe's applications (especially Illustrator) are increasingly dated. In terms of "professional" quality and functionality; Illustrator is as mediocre as "competing" programs which mimic it, and the widespread addiction to that mediocrity has stifled the advancement of the 2D vector drawing segment. I mean, honestly; an ostensibly "professional" 2D drawing program in the 21st century that can't handle user-defined drawing scales?
It's way past time for something beyond that, and the Affinity line is one of the promising specs of light shining at the end of that long tunnel. But it, too, will fall into mediocrity if the goal is to simply focus on playing "me, too" to Adobe.
JET

From your original post:

I assume you understand how Adobe Illustrator's arrowheads work?
As of CS6, they exist in an ordinary .ai file inconveniently buried in a directory of the default installation:
C:\Program Files\Adobe\Adobe Illustrator CS6 (64 Bit)\Support Files\Required\Resources\en_US
In that ordinary .ai file, they are just simple path artwork stored as Symbols.
To "customize" an arrowhead, you have to dig for that file, open it, draw your custom arrowhead, store it as a Symbol in that document, save that document, switch back to the document you're actually working on, in order for it to finally be usable.
That is extraordinarily cumbersome for anything claiming to be a "professional quality" drawing program. That's not an interface; it's a worst-of-class hack.
What, exactly, do you find in anything that I've written as cause for fear that what I suggest would be in any way more limiting than Adobe Illustrator's hacked-together treatment? How do you see my suggestion that arrowheads should be elegantly integrated with the Symbols functionality as less functional than Illustrator's awkward and cumbersome storage of arrowheads as Symbols? And why should such straightforward, clean, intuitive interface efficiency of closely-related features not be extended to the other attributes you also must apply to any path (e.g., strokes)?
Again: Illustrator's arrowheads are just simple drawings stored as Symbols in a particular file that is anything but convenient. In typical Adobe fashion, that sloppy hack was thrown together because it was very late to the game (to the point of embarrassment) in providing for user-defined (and user positioned) arrowheads. FreeHand, Draw, and Canvas (its three historic competitors) already provided for custom arrowheads years before.
And how do you think anything you currently do with Adobe Illustrator's arrowheads would be broken if, for example, selection of path ends were logically integrated with the interface for setting the same path's strokes (including brushes)? Illustrator's Pattern Brushes have...wait for it...End Tiles. But guess what? That feature is totally ignorant of the existence of Symbols and Arrowheads. That is anything but the kind of integration of functionality that can make each separate feature more powerful and more versatile. It's just the archaic hodge-podge, grab-bag, "me, too" approach to software design.
JET