JET_Affinity

Illustrator is now, what, 35 years old? When was the last time you keyed a trig function into a geometric value field in Illustrator? JET

At any price, it's a matter of principle, and something I simply will not do. Subscription licensing is a means by which to entrap customers, and it effectively holds your own working files "hostage." My wife and I have been married for 40 years (a little longer than I've been paying for the majority of the mainstream drawing programs). But I don't marry software vendors, wise guy. JET

Ashf, In a situation like your screenshot example (in which you have a single open path selected), click the Close Curve button on the Node Tool's Context Toolbar. If you're talking about joining two open paths at end nodes other than the nearest, then yes, the Join Nodes command should join between selected end nodes (if any). That seems a pretty obvious overlooked need. I wouldn't be surprised to see it fixed soon. The Devs seem pretty responsive to such things. JET

And yet it already has a feature set explicitly designed for axonometric drawing that is well on its way toward surpassing that in $1000 Corel Technical Designer; and something not found in Illustrator or Draw. Axonometric drawing is perspective drawing. It's result is parallel perspective, not converging perspective. As such, it is actually more accurate than the kind of converging perspective commonly taught in art classes, is eminently appropriate to a 2D vector-based drawing program, and as something heretofore utterly neglected by this entire software segment, represents significant additional potential profitability for illustrators who have never delved into it. JET

Now owned by Corel and only licensed by subscription. That's precisely when I stopped "following" it. JET

Practically everyone couches their pet feature desire in terms of the "most fundamental, basic, must-have deal-breaker preventing my being able to do anything with Affinity," and "the one and only thing preventing my ceasing paying Adobe's extortion fees." And I still say that emulating Illustrator is the last thing I want to see. I don't want "me, too"; I want better. No matter how long it takes. The video of using an envelope distortion in Illustrator to apply a dimple texture to a bullet is a case-in-point, because its result is actually wrong, and not even marginally convincing. The view of the bullet is obviously orthographic: a "side view." Therefore, drawn correctly (or at least convincingly), the circular centerlines of all of the rows of dimple dots would appear not as curves, but as straight lines; not just in the cylindrical portion of the bullet, but in its dome as well. (Think of latitude lines on a globe when viewed the globe is oriented such that its equator is viewed "edge on.") In all of the rows, the dimples (and the spacing between them) would increasingly narrow in width as they progress toward either side. But in the warp result, they are of uniform width and are even wider than they are tall. In the dome portion, each dimple ellipse would also increasingly rotate depending on its elevation toward the top of the dome. I'm not insulting Poptoogi's drawing here; I'm just making my point about feature requests. The video used to exemplify the "critical need" is an example of the classic "golf ball" projection problem: Even Illustrator's 3D Effect feature cannot correctly map that texture to the half-sphere portion of the bullet, because 3D Effect's mapping onto a sphere always "pinches" the mapped artwork at the poles. But it gets worse: Even Illustrator's explicitly-named "fisheye" envelope also fails for this kind of commonly-needed distortion, resulting in a "squarish" distortion. That's not because automation of such a distortion is impossible in a 2D program; I've automated it myself by use of simple 2D geometry in an AI JavaScript: (This is not an envelope distortion, but an entirely different approach toward achieving more exactly and correctly what has been posited as an example of why envelope distortion is so "fundamentally" needed.) I dare say if the functionality of that JavaScript were enhanced a little bit and implemented with a nice interface in a mainstream drawing program, it could end up being called the most "fundamental, basic, must-have deal-breaker preventing my being able to do anything with [any other program]." That's all I'm saying: Set your goal higher than Illustrator. And be willing to wait for it. Because if you're not, we'll just end up with "me, too" functionality. New-from-the-ground-up Affinity is the kind of opportunity that doesn't come along very often. Let's not squander it by demanding the mediocrity of Adobe Illustrator. JET

I suspect most everyone (including the developers) recognizes the need for a well-implemented (frankly, that rules out Illustrator's) offset path function. But Affinity presently has some well known frequently discussed (including the developers) problems with results of its outline stroke command, which I'd assume is closely related. So my guess would be that there is a kind of shared foundational fix that has to be addressed before piling on related features and commands. JET

Bear in mind: What's "great" in one scenario can be quite undesirable in another. Trying to "preserve" the existing path shape when deleting a node may be arguably more desirable when drawing font glyphs than when doing other kinds of illustration. But, of course, unless one is just sloppy about drawing paths with too many needless nodes, it is often not even possible for the path to keep the same shape (or even anything "close" to it) when deleting a node. So you have to go back and re-adjust the remaining handles anyway, which is also depicted in Benny's video. Users of (gag me) auto-trace features no doubt like to have the program try to maintain the current shape when deleting nodes. To me, that's like using a crutch on a crutch. A more legitimate use is for converting polylines imported from CAD exports into more sensible Bezier curves. That's more of what "path smoothing" features are for. As a general rule, I don't want the program "helping me" as if I don't know what I'm doing with curve handles I've already positioned. I'm more often deleting a node because I want the resulting difference in the path shape, and I don't want the program messing with handles I've already carefully placed. That's why such behaviors need to be deliberately invoked with optional keyboard modifiers. JET

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

I'm not saying modal dialogs are desirable if they are better avoided. I'm saying that Illustrator is replete with archaic modal dialogs, but even in spite of that, its transform tools still provide the greater functionality described and presents it more concisely. JET

For decades, there was a common comeback whenever FreeHand users complained about Illustrator's cumbersome two separate selection tools (and their associated problems): Many, if not most, longtime AI users (including at least one of its developers) would claim to "never use the black pointer", but to always use the so-called "Direct Select Tool," as if doing that were some kind of indication of "greater expertise" with the program. I would always counter by pointing out that, in Illustrator, that would mean they never used the bounding boxes, which I would further demonstrate are useful for such things as scaling an ellipse by its major or minor diameters (assuming the BB remembers its original orientation). So again: Yes, there are many who eschew bounding boxes, and no, I am of course not opposed to a program having bounding boxes. I am opposed to on-page transformations being dependent upon them. The transform anchor can be set anywhere. With a transform tool, it can be set by merely clicking where you want it, without having to find an icon to click in a control bar to display it, and then dragging it to where you want it. And a typical rotate tool effectively provides you with a "rotation handle" located anywhere. How is that less convenient (let alone less powerful) than having to used one of five hot spots that aren't even located on what you usually want to snap to something else anyway? I mean any detail of any selection. Suppose that on the page you have a raster image of Orion, the cat, and a path with an arrowhead, which is already where it needs to be. You want to rotate the raster image by mousing down on the center of the jewel hanging from Orion's belt (the detail of interest) and dragging it such that the arrowhead would be pointing at the jewel. You can do that with a typical rotate tool in one move, and the bounding box of the raster image (and its various rotation hot spots) is completely immaterial to the desired move. So by "detail of the selection", I'm not just talking about the snap-sensitive subparts of vector paths, like nodes, although that is certainly one of the most obvious applications. I acknowledge and applaud that. But there's more. As I've said many time, I'll never consider Illustrator the default program to emulate. But with its fairly customary transform tools you can: Click to set a transformation center. Then mousedown and drag anywhere to perform the transformation. The tool is snap-sensitive. So if you mousedown on a node, you can drag the selection by that node and snap it to any snapping candidate, including candidates beyond the reach of the selection (thereby "aiming" the node you are dragging at that remote snapping candidate). The same transformation tool can be used exactly the same way on any current selection, be it whole paths, partial paths, raster images, symbols, clipping masks, text, or any other kind of construct. This is pretty much what the Affinity beta Point Transformation Tool does, except that in Illustrator, All of the various transformation tools (Scale, Rotate, Skew, Reflect) work the same way. So although there are several transform tools, that in itself is intuitive, and there is consistency in the interface. DoubleClick any of the transform tools opens a dialog for numeric entry of values appropriate to that tool, including the option to transform one or more duplicates of the selection instead of the original. (FreeHand was even better at this, because it did not disjoint a path at its unselected nodes during so-called "power duplication" of sub-selections. This empowered certain reiteritive transforms which Illustrator cannot do.) So yes, there are four icons in the toolbar, and I'm as opposed to "tool glut" as anyone. But this is more concise and tidier than having to select a tool, then traverse to an options bar to put it in some other "mode", click a series of other icons to set its other behavior details, and then finally mousedown and drag on the page. All that comprises more "tool glut" than four grouped transform icons in the primary toolbox. And there's more: I'm also not entirely crazy about modal dialogs. But in this case, they have the advantage of storing their respective last-used settings. This is powerfully useful for many things, and not just in conjunction with the Transform Again command; the last-used transformation performed by each tool can be recalled no matter how many other things you've done since, including changing the current selection. Just doubleClick the pertinent tool and tap Enter. If you can accommodate all that for all of the usual common types of transformations into a single transform tool, my hat's off to you (as it always is anyway). But in terms of intuitive, powerful, and easily discoverable interface design, there may be good reason why mainstream drawing programs have gravitated toward toolbox tools for performing tactile transformations. JET

Oh, c'mon, guys. "Having" bounding boxes is not the problem. I fully understand their utility. The problem is having on-page transformations dependent upon them, in lieu of proper (and cleanly implemented) transform tools. That is substandard. The core problem is very simple: You can put any number of superfluous "handles" or "hot spots" along or near the edges of a bounding box and they all still have the same problem: They are not located on the details you are manipulating. To use them for transformations, you mouse down somewhere else. That fails to clarify what you actually want to drag and snap to something else. Users struggled with this and couched their complaints in terms of needing to transform sub-selections. So the awkward Transform Mode of the Node Tool (already an unintuitive interface approach) was added. But alarmingly, that committed the very same core fallacy. It also is dependent upon silly bounding box handles for transformations of sub-path elements. To ostensibly provide "direct" and "accurate" manipulation of details of paths, you again require dragging something other than what you are actually manipulating?! What other program does that? So next, the awkwardly named Point Transform Tool is added. It has a few subtle innovative behaviors which I like. But it has the same problem that gave rise to the demand for the Transform Mode of the Node tool; inability to manipulate sub-selections. I'm as opposed to unnecessary "tool glut" as anyone. But now, evidently in order to avoid adding conventional transform tools, we have two awkward and rather unintuitive feature sets which, combined, still fall short of the functionality more directly and economically provided by (much as it pains me to say it) the conventional transform tools in Adobe Illustrator. As it stand right now, we have less functionality with more interface clutter, requiring more clicks. And I'm still waiting for someone to explain why one needs five rotation handles on every bounding box. JET

And, unless I'm missing something, doesn't work on a subselection of nodes. Typical transform tools work the same way on current selections of any kind. Why do we need both a special "Point Selection Tool" and the separate and cumbersome Transform Mode of the Node Tool? I'm sorry, but this is not interface elegance. It feels like afterthought scattered functionality just to stay married to the infernal bounding box fixation. JET

Bah, it is merely visual clutter. If I'm going to rotate a tiny object by dragging it, I'm going to zoom in, so I can see what I'm doing with at least some measure of accuracy. Dragging a handle that isn't even located anywhere on the object nor even on its bounding box is superfluous junk. I've got along fine without it for about 35 years. I think it's a mere accommodation to finger painting on a mobile touchscreen with one's blunt thumbs and digits; an inappropriate interface and something I do not want when doing serious illustration on a proper desktop. A well-implemented rotation tool, on the other hand, lets you mousedown literally anywhere to rotate a selection about its transformation center–which it can also set anywhere–without switching tools, while abiding by all snaps both upon mousedown and during drag, and regardless of zoom. I know how the BB handles work, RC-R. There are four other rotation handles on the BB. JET

I have big problems with any program that requires dragging stupid bounding box handles for all its on-page transformations. Like you, I have no use for the countless situations in which the default bounding box doesn't even reflect the actual bounds or dimensions of the paths. (And while I'm at it, I despise the current fad for those stupid rotation lollypops. Why does one need four, let alone five handles for rotating a bounding box?) Example: Draw a square. Draw a circle inscribed in the square. Rotate the circle 45 degrees. Group the two paths. Rotate the Group 45 degrees. The resulting bounding box and its dimensions are utterly useless, reflecting the bounds of the corners of the rotated circle's bounding box, and enclosing a bunch of white space. Cycling the bounding box, the unwanted bounding box is still displayed and looks like an object that isn't even there. That's a hideous interface treatment. But let's not throw out the baby with the bath water. The ability to retain and recall a bounding box that has undergone some rotations can be quite useful, as in the common case of needing to scale a rotated ellipse by its major or minor diameter. It's not that object's being able to remember and recall their rotations "makes no sense." That ability is one of the historic advantages of, for example, Deneba Canvas. And it is also potentially advantageous over Adobe Illustrator, which often "loses" that information when you need it. It's just that the current treatment in Affinity's interface needs some serious work. Yes, making a reset of the bounding box permanent should be possible (and not require a goofy workaround), but optional. JET

Just by way of explanation… Have you ever wondered why isometric drawing can be done with a single grid, but any other orientation (dimetric or trimetric) requires three grids? That's because, by definition, all three axes in isometric are equally foreshortened. The same measuring scale works for all three. So in effect, "all three grids" and their increments are superimposed precisely on top of each other in an isometric orientation…but not in any other. That's one of the problems inherent to grids-based approaches to axonometric drawing. In your example, you've drawn a square on one grid. The other two perpendicular grids don't know which corner of that square you currently consider "the origin." Continually moving the artwork as in your screen clip is, of course, unacceptable. So using grids, you have to be able to continually "reset" the origin to whatever point of the drawing you at the moment consider the "origin" of your next measure. Doing that needs to be as fluid and instant and natural as possible. Since emulating pre-computer physical media is usually the goal of user interface design, It needs to be at least as fluid and instant and natural as it was before computers. But it's not. In the pre-computer days of productive isometric drawing "on the board," there were no "grids" on our drafting tables. There were (appropriately) just axes. (It's not called axonometric drawing for nothing.) The "axes" were the ruler scale(s) attached to the head of the track drafter, which you held in the palm of your left hand (if you were right-handed), and thereby fluidly glided to any point of interest in the drawing while maintaining the same angle. The illustrator effectively and intuitively "zeroed" the origin of the appropriate axis each time he started a new measure, pretty much without even thinking about it. Grids just don't emulate that very well. For flat graphic page design, a designer cares about the orientation of a spacing grid relative to some corner of the page. But for illustration, an illustrator doesn't care one whit about the "origin" of a grid relative to some corner of the page; his measures are made along the angles represented by the grids, but must be zeroed at any current point of interest in the drawing. (I don't have Affinity installed on this machine, so I'll leave it to someone else to tell you how to do that.) JET

Agree. EVERY vector based drawing program should provide for user-defined ruler scales. There is no need for any CAD related "apologies." User-defined drawing scale is just as basic to general-purpose illustration for print, signage design, whatever. I've been saying this for decades. And it's yet another no-brainer, low-hanging-fruit opportunity to exceed the archaic functionality of Adobe Illustrator. JET

Believe me, I understand the need and the concept. But let's not set our sights too low. As far as programmatic selection features, I will never be satisfied until I see something at least match the elegance and power of Macromedia FreeHand's Graphic Find & Replace palette, which did far more than Illustrator's anemic Select Same commands and far more than you describe. It could find user-specified combinations of attributes and, when appropriate, within user-defined ranges. And not just styling attributes. The list of combined possibilities would be very long to list, so by just one example: Beyond finding mere stroke weight, it could select path lengths within a user-specified range. Much of the time and tedium I spent writing Javascripts for Illustrator was to make poor-man's substitutes for some of the functions for which I most often employed FreeHand's GF&R. But frankly, I think "global swatches" is the more appropriate way to do this. Again, I'll refer to FreeHand. To users first accustomed to FreeHand, Illustrator's whole "Global Swatch" thing was just one of many needless stumbling blocks. In FreeHand, every Color Swatch which the user took the time to store in the Swatch Palette was functionally "global." And why wouldn't it be? Why would I ever want to define and name a Swatch that I could not use to programmatically update objects to which it is already applied? FreeHand's treatment of this gently but effectively enforced a much needed measure of organizational discipline as the user worked. Knowing that Swatch edits updated objects to which it was applied, intuitively trains the users to define a differently named Swatch (even if it was of the same color values as other Swatches) for objects which should, for any reason, be treated separately in terms of color. That's a simple matter of duplicating a Swatch and changing its name. This largely prevented the common beginners' bad practice of just applying colors willy-nilly, and then wishing they hadn't later. JET

You would just create the offsets by sequentially specifying strokes of those weights, aligning the strokes to the appropriate sides of the path (or just leave them centered and use twice the width). Cut and delete the portions not needed. Clean up the necessary joins at the corners. You'd similarly have to do multiple offset commands, even in other drawing programs like Illustrator. Typical offset path commands don't let you specify distances from a single path on a per-side basis, because the original path could be of any shape, so a "side" is a matter of interpretation. Illustrator has a feature that lets you set different "stroke widths" wherever you want along a path, but that's more intended for a variable "brushstroke" effect than for something that would maintain, for example, a continuous width along a portion of a curve. Affinity provides similar "brushstroke" functionality in the Pressure dialog, not directly on-the-path. JET

I won't. And I doubt that Serif is offended by my saying that, because... Serif is changing the 2D graphics game in many ways, a large part of which is cost and value. That in itself is a long overdue aspect of innovation in this software segment. I've long held that the historic "big four" of the 2D vector graphics world (Illustrator, CorelDRAW, Canvas, FreeHand) are grossly overpriced for what they are. Their vendors desperately cling to an outdated pricing model that stems from the heady days when it was all a major paradigm shift. But that was almost four decades ago. I see Adobe's take-it-or-leave-it subscription licensing scheme as a manifestation of that desperation. Many product categories enjoy "they'll pay anything" pricing when new technology disrupts whole industries. But fervor settles as the new way become the new standard. I remember paying $650 for the first HP color inkjet DeskWriter. That's CMY. No K. Competition is what gets prices back in line, and 2D graphics, much as we love it, is not rocket science anymore. Goliaths do fall when they can't conform to the times. Serif seems to know what it's doing in more than just coding very promising software. JET

Not sure I'm understanding the seam allowances, but I suspect that's addressable by keeping in mind: You can set the stroke's alignment to centered, inside, or outside before expanding it. So that should be useful for specifying an offset distance on either side of the base path. After expanding the stroke and releasing the compound as mentioned above, you now have two separate paths. So you can repeat the process for either of those paths: Give either of them a thick stroke Set it to centered, inside, or outside Expand the Stroke Divide Using Expand Stroke for this is, of course, what I'm confident will be just a temporary workaround until Affinity acquires a proper Offset Path or Contour feature or a more fully-featured implementation of vector Brushes. It's just an educated guess, but I rather suspect that one reason such features have not yet been added is because the developers are aware of the problem that an inelegant number of nodes are created whenever paths are expanded and Brush paths are converted to outlines. (A problem I've seen in early releases of other programs, too.) I assume they are closely related functions. That's what I sometimes refer to as multiple similar features probably sharing the same functional "foundation" when impatient users complain about what seems an obvious feature "omission." I'm confident the Affinity devs intend to get the underlying foundations optimized before building a bunch of features onto them, and applaud them for that. By the same token, for example, I'm confident the devs are aware that the result of Expand Stroke on a closed path results in a compound path, and therefore the Release Compound command should work on them instead of using the Divide Boolean button. But presently, Release Compound is grayed out after using Expand Stroke on a closed path. Affinity Designer is still very much a work-in-progress. But it's a game-changing bargain for what it already delivers and so far, we're not being charged for significant improvements between integer updates, such as those presently being developed toward the 1.7 release. For the price of the Affinity apps, we're getting a lot of value. So I have no problem cutting the development program some slack as the applications continue toward a more full-featured state. JET

AffinityBrah, After Expand Stroke and flipping the Fill and Stroke: Select the black pointer. Click the Divide button in the control panel. This releases the compounding of the two paths. Now you have two individual parallel paths that you can style as desired. JET

Especially when trying to develop something innovative as opposed to just more "me, too; same ol' same ol'", solid foundations have to be laid for what users consider "basic things." I have plenty of "me, too" programs. I don't need another one. If all I were seeing in Affinity were just another "me, too" approach, I'd just yawn. Who's not "letting" you? Fact is, B13eL's post that started this thread was just a useless, unproductive rant. It doesn't even mention any capabilities he's (she's?) so upset about. And your "fanboy" nonsense is just a childish insult to fellow users who don't agree with you. No one "prevented" either. And no one is prevented from disagreeing with them. Resorting to ad hominem insult is a dead giveaway of weak argument; and a sure way to lose respect. JET

Paul, It sounds like you are looking for what is usually called an "offset path" command or a "contour" command or tool for vector paths, to create paths that are offset from existing paths, but parallel to them. Does that sound right? JET

Exactly. And that's the misconception that is so pervasive nowadays; that isometric drawing is nothing more than just distorting a plan view into "30° angles" and extruding it into blocky shapes. I blame that largely on two things: The misappropriation of the "isometric" term by those creating old-style aliased computer game artwork using a 1:2 rise-to-run pixel grid (which is neither isometric nor dimetric; it's just an arbitrary oblique). The nearly complete absence of features in the vast majority of mainstream vector-based drawing programs expressly supporting axonometric drawing, ever since the advent of the "desktop revolution" in the mid-80s. The latter is an ironic and tragic pity, because: Axonometric drawing is, by definition, a 2D drawing discipline; and one every bit as venerable as the 2D converging "vanishing point" perspective still universally taught in common art classes. Axonometric drawing is applicable to all styles of commercial illustration. It is not just apropos to the purview of mechanical engineering departments. 2D axonometric drawing is no more "obsoleted" by 3D CAD than 2D "vanishing point perspective" is "obsoleted" by 3D artwork modeling programs. Mainstream Bezier-based drawing programs are 2D drawing programs used for all kinds of commercial illustration. Mainstream Bezier-based drawing programs do, in fact, provide the geometry necessary for axonometric drawing; their interface design just tends to hide it. The result is three and a half decades of neglect of one of the most important 2D drawing disciplines by most of the largest vendors of ostensibly "wide based" commercial illustration software. That's three and a half decades of software advancement and users' potential for skill-broadening fun and profit already lost. JET