JET_Affinity

I've said this before in other threads, but it is pertinent to this thread, too. so... Every serious vector-based illustration program should provide for transforming selections disproportionally in any direction needed, not just horizontally and vertically. So first, it is a very good thing that Affinity bounding boxes 'remember' their contents' rotation. Since Affinity does not provide transform tools, but only provides transform handles on bounding boxes, that is the only way to perform on-page scaling in directions other than vertical and horizontal. Yes, I agree that one should be able to permanently re-set an object's to page-normal when desired, but a rotated bounding box is a very useful thing. Inkscape, for one example, insists on all bounding boxes always being page-normal. So when you need to scale a rotated selection in the direction of its rotated orientation, you have to 'un-rotate' it so that the desired direction of scaling is either horizontal or vertical, perform the scaling, and then re-rotate it to its intended orientation. That's needlessly tedious. But Affinity's treatment is still senselessly limited. Consider an object that is rotated 35 degrees. Its rotated bounding box is 'remembered'. So you can disproportionately scale it in either the 35 degree or 125 degree directions. But by what logic is it assumed that the illustrator does not need to scale the rotated object in some other direction that is pertinent and meaningful to the illustration. Affinity bounding boxes provide an absurdly redundant FIVE rotation handles! One of them already has a different visual treatment: the 'lollypop' handle. Give that handle a practical and useful difference: Enable it to rotate the bounding box around the selection when a modifier key is pressed, thereby enabling the illustrator to 'aim' the transform handles in whatever direction needed, relative to the selection. JET

Vector drawing programs have done fine without the silly lollypop since the 80s. 'Difficulty hitting' a handle is usually controlled by a proximity setting in user prefs. But it's a moot point anyway. I didn't say get rid of the silly lollypop; I said "...give it the ability...." That could be accomplished by means of a momentary keyboard modifier when dragging it. I said to give that ability to the lollypop because that 'fifth wheel' rotation handle is the one that looks 'special' in the interface. Giving it the ability I desire would actually make it special. I assume the silly lollypop is for those using their fingers on touch screens. I gave up finger painting when I was 3. JET

Bounding boxes have thie As a FreeHand user for the entire life of the program, I certainly relate. Two things FreeHand users despised about Illustrator's interface was the visual clutter of bounding boxes and its insistence upon two separate selection tools. Unfortunately, almost all drawing programs have mimicked both, just because the market 'majority' is too accustomed to the inferior interface of Illustrator. But bounding boxes do have their uses, and "always' working with them off sacrifices that utility. In that sense, it's parallel to the way many Illustrator users claim to 'never' use the Selection Tool (black pointer) and 'always' use the stupidly named Direct Selection Tool (white pointer). The uses of bounding boxes pertinent to technical drawing are far more than just serving as snap points for guides. Affinity's bounding boxes are better than, for example, Inkscape's in that they rotate with their content. Inkscape's always reset to normalized to the page, no matter how you transform the selection, which is downright debilitating. By what logic does any illustration program assume that a user only ever wants to scale a selection either vertically or horizontally? Affinity's bounding boxes are better than Illustrator's. Like Illustrator's, they rotate with their contents. This is invaluable in technical Illustration because the side scale handles remain oriented to their content; for example, they remain oriented to the major and minor diameters of a rotated ellipse, and the measures in the Transform panel reflect those of the major and minor diameters. Like Illustrator's they can be re-normalized to the page. Unlike Illustrator, rotated objects still 'remember' their rotated orientation, and their bounding boxes comply. If you 'reset' a rotated bounding box in Illustrator, its rotated orientation is lost. Unfortunately, Affinity's bounding boxes cannot be permanently reset to page-normal, despite this having been requested for years. But the main ramification you have to keep in mind about any wish of 'getting rid of' bounding boxes in Affinity is that you loose any tactile on-page transformation tools, because Affinity doesn't provide transform tools in the Toolbox, like both Illustrator and FreeHand always have. You have to transform objects using the ridiculously redundant bounding box handles, which of course most often don't even reside on the objects being transformed. Yes, you can perform transformations numerically in the Transform Panel, but that's not "tactile on-page". So I'm afraid you're stuck with bounding boxes in Affinity. Being stuck with bounding boxes, they should at least deserve far more thoughtful and powerful implementation than they have. What justifies a ridiculous five rotation handles? Almost as frustrated as my comment about Inkscape, by what logic does any Illustration program assume that a user only ever wants to scale or measure a selection in the directions of its bounding box? Do something new and tremendously useful: Take just one of those absurdly redundant five rotation handles (the lollypop one) and give it the ability to rotate the bounding box about the selection so that its scale handles can then be used to scale the selection in whatever direction needed. And provide an option to permanently reset the selection's 'remembered' orientation to the current orientation of that rotated bounding box. This one simple feature would, so far as I know, be unique in this program segment, and immensely useful for technical drawing (and other drawing types, too). JET

Thanks, Garry. I just became aware of V2 yesterday, rushed to order it, and that was the first thing I checked for. Of course, searching the Help files for "Cycle Selection Box" returns no results. (Affinity still sorely needs a far better implementation of its documentation.) Having the keyboard shortcut for it is certainly nice, but keyboard shortcuts are not limited to menu selections. The main toolbox icons have them. No reason the Context Bar icons can't have them. I still insist that one of the best features that could be done for Affinity Designer's interface is to make the 'lollypop' rotation handle able to rotate the bounding box independent of the selected content. This would be a godsend for illustration. Where do developers get the notion that the only direction in which something needs to be scaled is parallel to the bounding box? For the simplest and most common example, consider any ellipse that represents a tilted circle: The minor diameter of such an ellipse must always be aligned parallel to the direction of the 'thrust line' that the circle 'orbits'. But this principle applies to countless other things, too, including shapes and artwork that are not bilaterally symmetrical like an ellipse. One needs to be able to: Rotate any shape drawn 'in the flat' so that it is oriented correctly about its thrust line. Then scale it in the direction of its thrust line to make it appear tilted. This is essential in axonometric drawing, but just as valid in general commercial illustration. JET

Can't help, other than to sympathize and agree. Affinity's very weak documentation is one of the first things I noticed about it. It's not just the search; the writing is far from thorough, too. Have assumed it will eventually be improved. Best-written user documentation of the many programs I've used over the decades is that of FileMaker Pro. Even it, though, was better before it became web-based. JET

Alternatively alternatively: a macro recording feature. Alternatively alternatively alternatively: a Javascript-based scripting implementation. JET

I've hung out on the 'big four' user forums for decades, practically never seeing a response from a developer. When this product and its forums started, it enjoyed the most refreshingly direct customer-to-developer access I have ever seen in this market segment. Affinity developers certainly don't need me to speak for them, but I strongly suspect that the current absence of that interaction is not entirely unrelated to the ceaseless repetitive and unproductive 'threats' of too many whiny users effectively looking a gift horse in the mouth. In an engineering department where I used to work as a technical illustrator there was a sign on the wall that read "In the course of every design project a point is reached at which it becomes necessary to shoot the engineers and begin production." The same principle no doubt also applies to rude users (and yeah, I've been one of those in other user forums, too). I expect version 2 is also not going to be perfect, but is still going to be great. JET

"To speed up with new releses I was thinking that we need to pay more..." Warning: Old guy rant. No, no, no. 2D Bezier-based drawing is not rocket science anymore. The old-guard companies like Adobe and Corel that were established in the mid-80s hey-day of GUI computing are clinging to an outdated pricing model. Far too many users are too willing to succumb to the most customer-abusive scheme ever devised (software 'rental'). Serif and others have already proved that neither outrageous prices nor subscription schemes are necessary for solid profit and growth. That's empowering game-changing competition. That's free enterprise. That's progress. That's the very revolution this software segment has needed for far too long. Support them. Don't invite them to adopt the same pricing and licensing strategies of monoliths that think it's their birthright to forever dominate an industry. And sheesh! I wish everyone would stop whining about every new program not being the tit-for-tat mirror image of the single old-school application to which he or she happens to be most habituated. I've been doing this stuff for a living for well over four decades, and can still make a list of never-addressed complaints about any of the old programs. And guess what: I was making that living long before any of them had mesh grads or cheesy instant-gratification distortion envelopes that make a mess out of a typeface's painstakingly developed design principles. Most of those old programs still can't 'understand' a basic trig function keyed into a value field. Affinity can. I'm not saying just be satisfied with the status quo. By all means, continue to request well-thought-out improvements. That's also progress. But try to be more innovative about it than just forever cursing a $50 program for not being a clone of (gag me) Adobe Illustrator. And meanwhile, learn to use the capabilities of the tools you have to their fullest. Don't try to tell me that professional and profitable work 'can't be done' in Affinity. That's utter nonsense. My Kawasaki W800 can't do everything the (good riddance) KTM 790 it replaced. But I find it far more enjoyable while it gets me wherever I need to go. JET

Neo, Your post is a little difficult to understand because you are not consistently using the terminology of the program (or terms generic to programs of this genre). But after reading it a few times, it sounds to me that what you're desiring is the ability to select a straight path segment, and have just that segment's height and width displayed in the H and W fields so that you can numerically specify the height and width of just that segment. While I agree whole-heartedly with the basic need, I see two problems with it: First, you would still have the same problem you mention with diagonals ("...doesn't work well...at an angle"). Far better is to be able to specify the length of the selected segment, which Affinity does provide for: Pen Tool: Click 3 times to draw a path consisting of two diagonal straight segments. Node Tool: Select the two nodes at the ends of the segment of interest. The L field of Transform Panel shows the length between those two nodes. The R field shows the angle of that segment. You can key in the desired length without changing the R value. Of course, that brings up your second problem: "...adjusting the size or length of line should offset other contents attached to it...". Changing the length of one segment without changing its angle necessarily changes the length and angle of any adjacent segment of the same path. But are you aware that you can, for example: Move Tool: Select the path. Point Transform Tool: Click one end of one of the segment of interest to set the Transform Origin at that node. Point Transform Tool: Mousedown on one of the other nodes, press shift and drag. As you drag, Shift constrains the direction relative to the Transform Origin. The other segment also moves and scales. A cursor tooltip displays the scaling change as a percentage. In other words, if I'm understanding you correctly, what you want is the ability to specify the length of a straight segment without changing its angle (which we can already do), but have a choice as to whether doing so changes angles and lengths of adjacent segments of the same path to accommodate (as it does) or scales the whole path to accommodate (which it doesn't). All that would be needed to provide that is another proportional chain link icon in the Transform panel (next to the L field) or (perhaps more intuitive) a single checkbox labeled "Scale Path". Bottom line is: Affinity already provides more in this regard than most programs of this genre; the ability to numerically specify the length of a diagonal straight segment without changing its angle. A simple, modest addition of another proportional link icon or checkbox associated with the L field could greatly enhance that ability. But meanwhile, at least a workaround is possible using the Point Transform Tool, as described above. In programs of this genre, (Bezier-based drawing programs) the underlying geometry required for many tasks is there, but the interface just doesn't include explicit tools for them. So it's often necessary to employ a little on-page temporary 'construction' to do them. Such a workaround for this would be to: PenTool: Draw a separate temporary path to serve as a 'ruler', snapping to the nodes at the ends of the segment of interest. Node Tool: Select both nodes of the temporary path. Set the desired length in the L field. Point Transform Tool: Click the original path to select it. Click the node that corresponds to one end of the 'ruler'. Mousedown on the other end of the segment of interest. Press Shift and drag to the other end of the 'ruler'. Move Tool: Select and delete the temporary 'ruler' path. JET

Those of us familiar with FreeHand's as-yet still unmatched Graphics Find And Replace palette are writhing in our seats. o This is one of countless similar things that, in my opinion, are better accomplished with a Javascript implementation than with a 'same for everyone' command. You would want to control multiple variables for such a feature. For example, should all instances of the object-replacing Symbol be the same size, or should each be scaled to the size of the corresponding object it's replacing? Should each instance be rotated to the same orientation as the replaced object? Should each instance take on the color of the replaced object? What about nested objects? Would the replace-with-symbol command 'dig into' groups, or replace the whole group? There are use-cases in which I would answer 'yes' or 'no' to each of those--and other--questions. I say this from experience, having written my own 'features' in Illustrator for years, the details of which can be customized (or optioned) to work exactly the way I want it to. For example, with my own Illustrator Replace With Symbol Javascript, I can simply replace selected objects as you describe for things like icons in maps. But I can also: Create entirely vector-based faux halftones in which each halftone dot becomes a Symbol sized according to the greyscale value of the dot. or... Draw lines of random lengths radiating from a single point at random angles. Then position a Symbol at the endpoint of each line, each scaled and rotated according to the direction and length of the individual lines, thereby creating 'explosions' or 'swarms' radiating from a center. One-size-fits-all behaviors tend to leave as many users dissatisfied as satisfied, resulting in the "close, but if only..." frustration. 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

Fde, Please go back and re-read my post carefully. I'm well-aware of the Cycle Selection Box. I even pointed out that feature when I said: "Like Canvas, it does let you switch a rotated bounding box back to its as-created pagewise (vertical / horizontal) orientation" What I'm talking about is the ability to rotate the bounding box relative to the selection so as to thereby orient the bounding box's scale handles in a direction pertinent to the actual artwork. The point is to be able to scale a selection that is already rotated as needed in the direction that it needs to be scaled. 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.)

Macro, unlikely. Too many variables. Although Windows applications tend to refer to Visual Basic scripts as 'macros', generally speaking, a macro is just a recording of a sequence of individual performed operations or commands provided in the standard interface, like so-called Actions in Adobe apps. The sequence would likely be different for every piece of artwork, thereby negating the advantage. Scripting, on the other hand, maybe. But that's far more ambitious. A good scripting implementation provides for variables and conditional logic. But the operative phrase here is "good implementation". I've resorted to writing Javascript to create a substantial collection of 'missing features' in Illustrator, and yes, I am one of those who dearly wants to see Affinity provide a complete and well-documented Javascript object model as soon as its feature set is more fully fleshed-out and stabilized. But even so, it was the continual frustration of scripting AI that I had to resort to it for no-brainer missing functionality like, for just one example, a simple reverse path command. (And no, no one need trot out clicking an endNode with the Pen Tool.) But it comes immediately to mind in this context that Illustrator's Javascript (as of CS6, after which I abandoned it because I will not enslave myself nor have my business-critical files held hostage to a software vendor) provides no method for collision detection between paths (something I asked for throughout the years of writing AI scripting). So one might be able to devise into the script a repetitive loop of 'tests' to determine which paths actually overlap. But I'd be gritting my teeth doing that just because the functionality should be in the standard interface. The use case I described (vinyl cutting) is one in which something akin to Illustrator's Merge command quickly becomes indispensable. But its utility is certainly not limited to that. It's one of the kind of features that a user may not immediately recognize the 'need' for, but will quite likely find many uses for once it is provided. Adding a button and a slider to a Boolean palette would not constitute excessive gratuitous tool-glut. If one thinks it through, it becomes evident that the so-called Merge Pathfinder is doing essentially much the same thing that the much later so-called Live Paint and Shape Builder features are doing. They're just doing it as a 'live effect' with an elaborate tool interface, instead of by a simple command. Much of Illustrator's tool glut boils down to 're-packaging' of existing functionality with more elaborate interfaces. Of course it did. And I dare say, like many other things, it probably appeared before Illustrator's trapping functions. But FreeHand did not have a command akin to the one specified in this thread. The Merge command was one of the precious few positives in having to segue to AI after Adobe bought and killed FreeHand. I'd have to fire up the old bulbous pinstripe Mac G4 relic to verify, but something in my own vague recollection suggests that FreeHand's Boolean path operations could be made to incorporate manually-built traps. All this is why I continually argue that we need to think beyond Illustrator. Illustrator is just one of the old 'Big Four" (FreeHand, Illustrator, CorelDRAW, Canvas). A lot of redundant clutter lingers from the ad-hoc development since those days and elegance is lost when new offerings just 'copy what [historically] sells.' Elegance is achieved by providing fully thought-through and integrated functional power just beneath a clean, minimalist, but intuitive interface. The clutter of the older apps is nowadays nothing to emulate. My favorite example of the 'everybody now does it, so it must be right' fallacy is the now omnipresent confused, always-shifting, schizophrenic 'Bar' that can't decided whether it's a Tools Option Bar or a Commands Bar. Every graphics software developer should be required to understand and experience the advantage of FreeHand's incomparable Inspector Palette. (Closest thing to it in any program I use is in the Layout Mode of FileMaker Pro; a database program, of all things.) JET

As I've suggested in similar contexts: Commands should be provided to convert any path to either a cutting path or a marquee selection (with a Boolean option for 'contact' as opposed to 'surround'). JET

For those not familiar: Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color: It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color. One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium. However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them. The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print. So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract). Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color. Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other. JET

For clarity, I certainly hope no one is asking for this to be a default behavior. I do not want an endNode of a path to auto-join to another path just because I drag it to within pick distance of another path's end. There are countless situations in illustration in which one draws coincident paths that should not be joined. Look no further than paths of different weights, color, or other style attributes that nonetheless need to have coincident ends. What about when more than two endNodes are coincident? How is the program supposed to know which path I would want it to auto-join to? The auto-joining behavior of Adobe Illustrator's Pen, for example, is one of its most infuriatingly intrusive stumbling blocks. To avoid its infernal insistence on auto-joining to other deselected paths when drawing, you actually have to invoke this ridiculous override: Mousedown somewhere that you don't want the next node to be Press and hold the spacebar Drag to where you do want it the node to be Mouseup Release the spacebar A path drawing tool is not a selection tool, and should not act like one. It has no business affecting unselected paths just because you need to place a node within pick distance of another path's endnode. Nor should it occur when just dragging an endNode. At most, any such behavior should have to be invoked by a keyboard shortcut. It should not be default behavior. The task of cleaning up DXF files is an oft-cited use case, and one with which I am quite familiar, having been doing technical illustration since well before personal computers. But it's still a specifically vertical use case; nothing that should be cited to justify a default behavior. Other programs accommodate it with separate, explicitly-invoked menu commands. You select the paths you want to be affected and then invoke the joining command (with whatever parameters offered in a dialog). If that's what you're recommending, I'm fine with it. But auto-joining as default behavior is bad. JET

Bah.

Multiple discussion threads on it in the Beta forum. JET

There is a lot of functionality in a dedicated standalone cutting application, too. As for steps 2 and 3; no. That's what enables me to use the single familiar cutting / driving application with all the vector-based drawing program I have, and to use files provided by others outside my shop. But again, the primary advantage is avoiding mission-critical dependency upon a single drawing software 'host' for the plug-in. JET

This is why you're really better off using a separate standalone cutting software to drive your cutter, rather than using a plug-in that traps you into dependency upon a single general-purpose drawing program. My cutters are Rowland. But if your hardware is Graphtec, have you not looked into one of the Graphtec Studio applications? With a separate cutting-prep application, you can use whatever drawing software you want, so long as it can export to a common vector file format that the cutting application can import. In the case of Affinity, that would be SVG, which is indicated on Graphtec's site as one of the formats supported by Graphtec Studio. You would: Do the drawing in Affinity Export as SVG Import the SVG into Graphtec Studio Set whatever device-specific options or features the software provides Send from Graphtec Studio to the cutter Typically, what actually drives cutters is just ordinary simple pen-up, move-to, pen-down HPGL instructions. So even when you use your Graphtec plug-in for Illustrator, what's really going on is, the plug-in is converting the Bezier curves to plotter language and then sending it to the cutter's driver. JET

JET

twopointoh, The development of Affinity applications is being openly shared with the user community in the Beta section of this forum. If you download the current beta, you will find that an offset offset path function is among the things under current development. JET

Live Text On A Path cannot actually be saved in a PDF. When you save a file as a PDF from Illustrator, you have the option to Preserve Illustrator Editing Capabilities. If you have that option turned on, Illustrator stores a full native copy of the content, stashed away in a 'cordoned off' area of the PDF file. That's why 'PDFs' saved that way from Illustrator are so much larger than if they are saved without that option on. If you then re-open that 'PDF' in Illustrator, Illustrator doesn't open the PDF content; it opens the stashed-away native copy. That's why the Text On Path object is still editable. When you save a file as a PDF from Illustrator with that option turned off, and then 're-open' that PDF in Illustrator, you will find that there is no live editable Text On Path. Affinity Designer does not 'open' native Illustrator files, just as Illustrator does not 'open' native Affinity Designer files. Both can export and open PDFs. Illustrator does the inverse with its 'native' .AI format: When you save a .AI file from Illustrator, you have the option to Make PDF Compatible. If you have that option turned on, Illustrator stores a PDF copy of the content, stashed away in a 'cordoned off' area of the .AI file. If you then open that '.AI' file with Affinity, Affinity doesn't open the native AI content; it opens the stashed-away PDF copy. That's why the Text On Path object is not editable. JET