JET_Affinity

Just pragmatic. Masochists are those who put up with the long drawn-out, over-hyped, on-again-off-again, compatibility-breaking, Gershwin, Rhapsody, etc., etc., ad nauseam transition from Mac Classic to OS10. That's when I quit kicking against the thorns, well after the significant MacOS advantages had been rendered moot. I still have the pinstripe G4, complete with its DVD-RAM and SyQuest drives. I'll make you a good deal on it. That's okay, though. We Windows users need you 20% ers to keep buying your stylish Macs, 'cause Microsoft always needs somebody to copy. Otherwise, we'd still be looking at green 80 column letters on black screens. JET

I left MacOS behind almost two decades ago and haven’t looked back. JET

If I may… I don't mean to come across like some kind of self-appointed "forum sheriff", but you guys would do well to better explain the specific functionality you desire. You're referring to a proprietary tool in a specific program; Illustrator's so-called Free Transform Tool. No doubt countless skilled users of programs other than Illustrator have no idea what you're talking about as a "real free transform tool." In fact, having spent decades in the Illustrator user forums, I dare say even many, many Illustrator users don't know what it's for, and seldom touch it. It's certainly not among the most commonly used features. When it comes down to it, Illustrator's Free Transform Tool is just another bounding box based scaling tool. As such, its behavior probably could be integrated as a few more keyboard-modified behaviors of Affinity's existing and (sometimes oppressively) omnipresent bounding boxes, rather than as another dedicated toolbox icon. Illustrator's Free Transform Tool is kind of a pre-cursor to more capable envelope-based distortion features that came to most programs later. (And envelope-based distortion—warping, etc.— is on Affinity's roadmap, and none of us, as yet, have any idea how the interface of that will work.) That's why you need to describe or demonstrate the specific functionality you are desiring instead of just invoking the little-understood proprietary name of a program-specific feature. Illustrator's Free Transform Tool is, frankly, also rather poorly implemented. Long time Illustrator forum regulars (including myself) have many times tediously explained to other users (and not just beginners) the tedious sequence of multiple keyboard momentary modifiers required to invoke its faux "perspective" thing ("mousedown then Ctrl-Alt; mousedown then Ctrl-Alt!"). Further tedium stems from its most potential-killing aspect: that its bounding box resets to a rectangle after each and every move of one of its handles . FreeHand's similar tool, for example, didn't do that. It held its transformed shape (like an envelope), so it was much more useful for the most common purposes, like moving each corner of the bounding box to corresponding corners of an obliquely-viewed surface by a series of moves. But my larger point is this: In this thread, some of you associate words like "crippling" with this request. But if there's anything actually debilitating about Affinity transformations at the moment it's that all of its on-page interactive (pointing device driven) transformations are based on dragging the infernal bounding box handles. That's the real issue that needs to be addressed; not just a "me, too" copy of Illustrator's specific treatment of a rather dated and limited bounding box-based warp behavior. Think bigger. Forget Illustrator. JET

I'm not an insider; just a user like you. But I certainly assume that vector based "brushes" (i.e., ability to stretch, repeat, or blend vector objects along paths) are planned. However, I would just as strongly think it unrealistic to expect a reverse-engineering of Adobe Illustrator's specific treatments of "brushes". So I'd expect any ability to directly import Illustrators' brushes as still-live constructs to be just as unlikely for Affinity as it is for any other competitive drawing program. Corel Draw, Canvas, etc., can't directly import Illustrator brushes, either, just as Illustrator can't directly import working copies of proprietary constructs in those programs and just as Illustrator can't directly import Affinity's raster-based brushes. Nor would I even want that. Illustrator's vector-based brushes are one of its few truly differentiating features, and I even dare say I use them more elaborately than most users do. But that doesn't mean it can't be done better. Illustrator's Art, Scatter, and Pattern Brushes are full of unnecessary limitations and they are too "standalone" in nature; "ignorant" of other Illustrator functionality that should be integrated with them. Think about it: Such a feature ties in with a lot of other more foundational functionality (path strokes, fills, ends, Symbols, envelope distortion…). Affinity is still only approaching version 2, and its functional foundation (like transformations) is still very much under development. To build something better than standard fare, you don't put the cart before the horse, just to be able to claim "me, too." JET

For those not familiar, the behavior result that Rudolphus is depicting here… …is reminiscent of FreeHand. Unlike most drawing programs, FreeHand did not just provide two node types ("smooth" and "cusp" or "corner" and "curve"). It also provided a third node type called a "Connector Point." A Connector Point was a node with just one handle, the length of which affected the curvature of the next (outgoing) segment. But that single handle always maintained tangency with the end of the preceding (incoming) segment. Its purpose was to always ensure perfect tangency between a straight segment and a curved segment, no matter what you subsequently did to those adjacent segments. Particularly important in drawing font glyphs, but just as useful in accurate general illustration. Most vector illustrators are not even aware of it, because it was never a feature of Illustrator. So the behavior which Rudolphus is suggesting could be useful for the same purpose. But since Affinity also only provides the two most common types of nodes, the tangency would not be maintained if the two associated segments are thereafter altered. The node is still just an ordinary smooth node with one handle retracted. But it would be a great thing if the concept of FreeHand's Connector Point were "resurrected" in a modern drawing program. It's just one of many "long lost" superiorities of that program. JET

Version 1.7.0.188 Rectangle Tool: Drag to draw a rectangle. Transform palette: Proportional link off. Key "Sqrt(2)" into W field. Tap Enter key. Nothing happens. JET

Thanks for the interest, Ben. Tactile transformations (with the mouse) really are deal-breakingly important. It makes all the difference between drawing accurately as opposed to having to merely "eyeball" things. Some programs (those without dedicated Transform Tools in the toolbox) do it when the bounding box is visible (as in the Corel screenshot in my previous post), but they don't require you to mousedown on the rotate handles of the bounding; they let you mousedown on any node or edge with full snapping ability for all candidates. When doing serious illustration, the object(s) you are rotating (including groups, symbols, sub-selections of nodes of single or multiple paths) are all kinds of shapes, and the detail you are interested in snapping into rotation alignment with other objects edges (and not necessarily straight edges) or guides have nothing at all to do with the locations of any of the bounding box handles. So in most situations, the bounding box is immaterial and just makes for annoying visual clutter. Other programs (Illustrator, FreeHand) do provide dedicated Transform Tools. This is far cleaner, more consistent, and more intuitive to use, because they work the same regardless of the selection; whole objects, sub-selected partial paths, or combinations of both, and show no unnecessary bounding box that is totally unrelated to what one is trying to do. That's the huge advantage to having actual Transform Tools in the toolbox as opposed to merely having transform handles on a bounding box. There are multiple important subtleties involved. For example, In Illustrator, when you mousedown on the node to be dragged, that node becomes the snapping object of interest, even if while dragging, the cursor moves off that node. That enables you to, for example, snap that node into rotational alignment with object edges which are shorter or longer than the radius of the node's rotation. A simpler, but just as important behavior detail intimately related is the mere matter of what happens when you switch tools. In Affinity, when you move a path with the Move Tool, and then simply switch to the Node tool, or doubleClick the path to invoke the Node Tool, all the nodes are indicated, but none are selected. This is maddeningly annoying when your purpose for switching to the Node Tool in the first place is to drag the whole path by one of its nodes so as to snap it somewhere, even for mere translations, let alone rotations or other transformations. When you select something with the Move Tool, the selection is selected as a whole. Therefore, while it is still selected and you switch to the Node tool, it should still be selected as a whole (all of its nodes selected). There is no justification for changing the selection just because you switched to the other selection tool. And by what rationale should the transform anchor disappear when the Node Tool is selected; even when in it's "transform mode"? One would expect to at least be able to perform the accurate rotation numerically as a tedious workaround. But that's frustrated by the matter of not being able to know or measure the angle of a straight segment that was originally drawn diagonally, as opposed to being first drawn horizontally or vertically and then rotated. There's no measure tool, and that omnipresent bounding box doesn't know didly about the angle at which the line was drawn. (This problem, of course, pertains to angles between any two coordinates; not just straight single-segment paths.) And really, it's not just about rotation. Skewing and reflecting should also be possible to do with the mouse while snapping along other guides, pathGuides, or unselected objects at any arbitrary angle (as could Freehand), but rotation is the real deal breaker here. JET

Hi, Ben. It certainly does need work, and I was sure hoping to see it addressed before the release of 1.7. This is something that mainstream drawing programs do. One obvious and very common use case is the one I depicted: The need to align the minor diameter of any ellipse (i.e., any foreshortened circle) to its thrust line (i.e., its axis; the perpendicular line about which it "orbits"). This is a fundamental principle of any kind of realistic illustration, and not just in axonometric, but in converging perspective as well. And it's not just about aligning ellipses with their thrust lines. The need to rotate with reliable snaps when dragging by a node is very commonly needed in countless general drawing and design situations. Having rotation with reliable and accurate snapping based only on bounding boxes is sub-standard. Couple of quick screenshots from Illustrator and CorelDRAW:

What am I missing? JET

All this discussion buttresses my point, which I clearly stated: We users have no idea how a decision by Serif to make Affinity core functionally dependent upon back-end licensing of code from a third-party plug-in developer would affect us and the future and marketing direction of the product. And end users are effectively being urged to back that licensing — by that third-party developer—in a Serif user forum. (Try doing that on, say, Adobe's forum.) There are sound reasons why it's illegal to campaign within a certain proximity of the voting booth. Yes, I'm familiar with the product. I don't buy it for the reasons I already explained re avoidance of my own dependency upon third-party add-ons. Sure, I'd like to see whatever I consider better functionality or interface approach in whatever drawing program I license, regardless of where I see it. I like, for example, some of the new wrinkle interface stuff I see for path manipulation in FontLab. That doesn't mean I want Serif to license that interface from FontLab and pass the cost on to me. For another example, the very best thing any object-based graphics program could do is re-map the entire interface onto the object inspector concept, as FreeHand did many years ago. That certainly doesn't mean I'm going to become a volunteer campaign worker to urge Serif to license that idea from Adobe just because it now owns FreeHand's code. JET

Sounds to me like you're just talking about a proper implementation of graphic styles, in which an "Update From Selection" command (or drag & drop) is provided so that existing objects to which that style is applied update accordingly. And inclusion of the ability to use stored graphic styles as one of the criteria in a proper find & replace feature. JET

Rather inappropriate for you to be self-servingly pushing your software sale here. But all IMHO, of course. JET

I learned early-on to avoid dependency upon third-party add-ons like the plague. I consider the whole long-promised "plug-in panacea" model largely a failure. Countless such extensions from relatively small companies have come and gone over the decades. The more elaborate ones often cost half again as much as the host program. Being standalone, they lack functional integration with native features, over-clutter the interface, and chronically lag behind the host program's version changes. For users who are "married" to a single drawing program, simply buying a competitive side-grade to another program often costs less, gains a lot more for the money, broadens the user's versatility by acquiring hands-on familiarity with more than just one program, empowers them to have options when their "pet" primary program goes away (or becomes rent only) and gives them at least some validity when claiming to "compare" various programs. I understand the Astute Graphics thing is somewhat different, in that the third-party add-on developer is offering to license its code to the host programs' developers. But right now, none of us on the user side knows how that will actually translate to us or our wallets. So I do not just off-handedly advocate Serif's commitment to that kind of back-end deal without knowing how it would affect me as a customer and a user. I'd rather see Serif continue to develop its own proprietary, royalty-free code for drawing functionality using its own ingenuity. Who knows; they might be able to do it better. A scripting API is a whole other subject. That gives users willing to invest the time the ability to develop his own functional solutions which are integrated with the host program's native features, and over which he has full control. JET

I strongly agree that this needs to be in Designer, not just Publisher. It's just as important in a drawing program. (But they're not "special characters"; the command should just be "show invisibles.") (Another laughable Illustrator factoid: Did you know that (at lease as of CS6), you cannot search for and replace carriage returns?) JET

I don't mean to hijack evtonic3's suggestion here (with which I basically agree), but it's a tiny part of a much larger issue, and Aammppaa's animation serves to exemplify it: In the animation clip, the transform anchor displays, and Aammppaa demonstrates dragging it to a snapping candidate. However tedious, that much Affinity can do. But forget that for a moment. The larger issue is that Aammppaa then still has to rotate the ellipse by the rotation handles of its bounding box. Now consider: See that single parameter handle that looks like a node on the edge of the live ellipse? Note that after the first rotation, that "node" is no longer aligned to a bounding box handle. But suppose that is the detail of the selection that Aammppaa needs to rotate into snapping alignment with, say, a pre-existing diagonal line behind the ellipse. How is he going to do that by dragging a bounding box handle? In this hypothetical situation, Aammppaa needs to: Set the transform anchor where desired. Mousedown on a node of the ellipse (or any other arbitrary path) with snapping accuracy. Rotate the selection by dragging that node until it accurately snaps into alignment with the diagonal line (or any other pre-existing snapping candidate in the whole drawing). You can't do that with Affinity's rotation interface. You have to drag the rotation by a bounding box rotation handle and just "eyeball" the actual alignment you need. Yet that kind of rotation is far more commonly needed in accurate illustration work than merely dragging bounding box handles to snap somewhere, because the bounding box handles most often don't even lie on the path(s) being rotated. They are most often not even relevant to the precise rotations needed. This is why other programs (Illustrator is one example) provide transform tools, not just a transform palette, and not just rotation handles on bounding boxes. Now, you don't have to provide a dedicated Rotate Tool to perform the kind of rotation I'm talking about if you just abhor the idea of adding another icon to the toolbox. A program can simply: Put the selection in its "transform mode" (i.e., do whatever results in its rotation handles appearing). Instead of grabbing a bounding box handle, mousedown on a node (or any other snapable detail of the selection). Drag, and while doing so, sense snapping candidates within proximity to the mouse (which may or may not still be over the node being dragged). Mouseup when on the desired snapping candidate. CorelDraw is one example of this treatment. But the same principle is also valid for other transformations; scaling, skewing, and even reflection. FreeHand enabled the user to perform all those transformation by setting the COT and then dragging the appropriate tool along any direction. So, for example, you could reflect a copy of a selection about an arbitrary diagonal line, or scale it diagonally in the direction of that line, etc. It's not that transformations based on bounding boxes are useless. Affinity's ability to basically forever retain the rotation value of paths throughout their manipulations can be an important technical advantage which few competing drawing programs provide. (Illustrator does this so erratically that it's of less use than it should be.) But Canvas, for example, does this by enabling the user to toggle back and forth between a selection's "transformed" versus its "untransformed" bounding box with a click on a button. (Affinity, as of yet, doesn't even allow a hard reset of the bounding box, which raises another whole set of related issues.) It's just that bounding box handles are usually useless for transforming details of one path into alignment with another path, which is something needed countless times every day in serious illustration. Having tactile transformations (those being performed by dragging with the mouse) and their associated snaps based only on bounding box handles is absolutely debilitating. It's the Achilles' heel of this program. It flies in the face of Affinity's otherwise emphasis on accuracy, and constitutes a very serious disadvantage in comparison to other drawing programs. JET

Garry, as anyone can easily see by reading this thread, you have completely miss-characterized everything I said. I never presume to know what is "easy" for the Affinity develop team to implement. And everything I posted here is in direct context of the request for live connector paths, a common, appropriate, and very useful feature within mainstream drawing programs, and yet another embarrassingly missing from Adobe Illustrator, despite being long requested by its users. JET

So you chimed in with your objection to Randall's suggestion because you don't want to discuss its merits? JET

First, I completely disagree with your "single page" constraint. Back in the day, that was the knee-jerk outrage of Adobe Illustrator devotees whenever a FreeHand user dared suggest that many, if not most, illustration projects ( logo designs, business identity documents, projects destined for vinyl cutters and other NC machines, package designs, bottle labels, trade show displays, garment imprints, and countless other things) involved more than one sheet and that those sheets need to be independently sized and oriented. Try taking away that program's typically late-to-the-party multiple Artboards ability from the same naysayers today. So that aside, do you not consider "artwork and illustration" inclusive of, say, commercial product renderings (cutaways, phantom views, parts breakdowns, assembly instructions)? My toddler grandsons' animals books are all about illustrations and chock full of floating callouts. Later, their Tinker Toy assembly instructions will be, too, along with assembly leader lines. That will continue as they mature toward instructions for Erector Sets, installation sheets for their faucets, maintenance manuals for their cars, and sales brochures for the motorcycle of their dreams. It's all the same core functionality. Again, take a look at other mainstream drawing programs. Canvas's Annotation Notes feature. Corel Draw's and Designer's Connector Tools, and Inkscape's Diagram Connectors, (among others) are neither inappropriate nor obtrusive. Raster auto-tracing is an example of the kind of standalone feature (not to mention amateurish bad practice) that can be easily "outsourced" to a separate program in the workflow of an illustration project. But connector lines are by definition functionally attached to individual objects within the native environment of the illustration in which they reside. Saying they should be created by use of a separate program is like saying dimensions of a floorplan should have to be added after-the-fact in a separate program. And again, their use is not limited to network diagrams for the IT department. JET

The arrowheads features in most current mainstream drawing programs provide for positioning the arrowhead (or circle, etc.) relative to the path's end node. That's nothing new; that's expected standard fare these days. The defining functionality of a Connector Lines feature, though, is as Randall mentioned: the anchoring of the Connector Line to the connected objects the live updating of the shape of the path according to a few parameter options (straight, right angles, with or without radius corners) the automatic avoidance of unconnected boxes in charts and diagrams. (in some) the automatic rendering of cross-overs (humps or breaks) In some programs (typically the charting feature of "office" or "works" programs) ends of connectors only anchor to bounding boxes. In some more full-featured general drawing programs, though, they can be anchored to any node of the connected object. Anyone who has used them much in drawing programs know that the latter behavior is far more versatile and powerful for uses other than just mundane org charts. You can, for example, use them to draw the lengthwise edges of an "extrusion" of any shape, thereby creating such an extruded object that can be adjusted in length and angle at any time. JET

On the other hand, it doesn't require a well-drilling rig to simply put a screw in that piece of wood. All that's required to provide versatile flow-, org-chart functionality is a basic connector line object and an appropriate symbols library, both of which are common in vector drawing programs, and both of which can also be used for other creative purposes. (Affinity already has a suitable Symbols feature in which one can store and organize their subject-specific box shapes.) As far as "polluting" the program goes, this is not a narrowly "vertical" need. I dare say the majority of vector illustrators encounters at least the occasional need to create such diagrams for everything from org charts for the VP to decision trees in the troubleshooting manual. (Ever had to hack such a simple thing out in Illustrator, which provides no connector lines, even though all three of its historic competitors do? I have, many times.) When a connector lines feature is present, it can also facilitate wiring diagrams. And maps. And assembly diagrams. And extrusions. The key to maintaining powerful elegance is careful and innovative integration of features. Just off the top, why can't a "connector" just be a path end attribute? Or why can't a Connector Line be one of the Smart Shapes with adjustable parameters? Functionality doesn't always have to be implemented in the same way as conventional wisdom assumes. Every little added function doesn't have to be presented as an Adobe-esque overblown standalone in the grab-bag interface. I'd favor some kind of connector line functionality. It's not unduly obtrusive in Canvas or Draw or Technical Designer. But the request would probably be better received if stated as that—connector paths—instead of as something specifically for network diagrams. The basic functionality can be useful for all kinds of things. JET

Take heart, Mattie. You made a good purchase. The program has strong underpinnings, but is still under development. The request for display of path length (and area and other things) has been made several times. I'm just a user like you, but I'm confident this and related functionality will be forthcoming. If it's any consolation, I "was there" when Illustrator finally got around to displaying path length (and other specs, like number of nodes, etc, etc.), which its competitors already provided. Given the age of the program, it wasn't that long ago. Prior to that, that information was buried in a "secret" developer's dialog that could be invoked if one knew the undocumented keyboard shortcut to invoke it. As users found out about it, they demanded visibility of such info in the normal interface. That's how it finally got rather crudely tacked onto, of all places, the Document Info palette. (Not exactly an intuitive place to look for path details.) I dare say many Illustrator users are still not even aware of it. But you are right, it is essential to accurate drawing. JET

What, exactly, are you complainers comparing to? Adobe's pace of feature development has always been lethargic. Still is. I could recite a long list just off the top of my head, but just one example is sufficient to make my point: How many of you realize that it literally took decades for Adobe Illustrator to gain something every drawing program since the likes of ClarisWorks provided: live shape primitives (rectangles, polygons, stars, etc.) with adjustable shape parameters? It was in fact not until just very recently that its ellipse tool gained arc functionality; the ability to set angles for its start and end points for an ellipse, something invaluable for technical drawing. The fact that a traditional perpetual license to Illustrator—when it was offered that way—cost about eight to ten times what Affinity Designer does, really has nothing to do with it. Individual, independent talented and passionate graphics people (as opposed to corporate IT departments just tasked with maintaining a company's software) who buy into Adobe's rental scheme often don't realize they are actually paying more in the mid-term than they did with its already overpriced perpetual licenses. (Why else do you think software rental schemes are the holy grail of software companies?) And they are painting themselves into the corner of perpetual brand-specific business-critical dependency, which I, for one, will have none of. (Guess who immediately dropped all interest in formerly promising Gravit Designer upon the announcement a couple of weeks ago of its acquisition by Corel and that it will only be offered by subscription.) But it's all just a desperate move by that handful of now monolithic companies that were there in the "paradigm shift" '80s to cling to, for as long as they can, what has long since become an outdated pricing model. Adobe apps became perceived as the "leading" products simply because they carried the Adobe label (the household word in the days of the desktop publishing revolution, as creator of PostScript), not because of objective functional superiority of its desktop software. You think innovation only comes from such companies? What was the last truly innovative thing you saw done to Illustrator? It's 2D graphics. This isn't rocket science anymore. Don't get me wrong; I've got my own problems with Affinity Designer. As soon as the 1.7 beta starts, I will be all over what is really the most foundational problem of its drawing interface: basic transformations being only bounding-box based. That's got to be addressed for serious illustration work. It effectively negates the program's otherwise superior accuracy. The difference is, I rather expect that with Serif, someone will actually be listening. The rate of development of this fresh (and refreshingly affordable) graphics suite is not at all lethargic by comparison to its grossly overpriced monolithic competitors. JET

In other words (instead of couching every feature request in the exact terms of Illustrator's poorly-implemented ad-hoc commands), simply offer the ability to use any path to define a cutting path or a selection marquee, and thereby leapfrog Illustrator's lame functionality with a more powerful, versatile, intuitive, and cleanly integrated (i.e., elegant) solution. Illustrator's Divide Objects Below command has the same inexplicable problem its lame Knife tool does: Neither knows how to cut open unfilled paths (like straight lines)?! The ability to draw a path of any shape (straight, curved, or freeform), as accurately as needed, and then just issue something like a "Cut With Front Selected Path" command, would be more powerful and less cluttering than the typically awkward Knife tool. An accompanying "Select With Front Path"—with a "Contact Sensitive" toggle (checkbox or momentary keyboard press) would at long last make "marquee selection" accurate, and solve the pandemic arguments over whether a selection marquee should select everything it touches or only things it completely surrounds (FreeHand provided a tool setting option for this). JET

There are already threads requesting some kind of scripting environment, with considerable amounts of discussion. But consider: The Affinity apps are all still very much under development. Wouldn't it make sense to expect a scripting solution to be implemented after most of the development dust has settled, when at least most of the full feature set is in place? JET

Coincident nodes is something to avoid in font glyphs. As I recall, Fontographer, since way back, displayed coincident sequential nodes (adjacent in the path winding order) with a dashed circle around them. Auto-deletion or "merging" of coincident nodes is not necessarily a good idea, because you don't always want the same thing to happen in the results. Should the associated handles be retracted? Should just the two inboard handles be retracted? Should the resulting single node become a corner or a curve node? Or should the segment joining the two nodes simply be removed (i.e.; the path opened or cut between the two nodes)? It can be simpler to just highlight the coincident nodes and let the user decide what to do with them. It's not uncommon for me, upon encountering coincident nodes, to select the frontmost one, use the arrow keys to nudge it, say, six increments in one direction, delete the joining segment, and nudge the moved node back. Frankly, in general drawing practice, it's not that big a deal. One soon learns to sense when coincident nodes exist by the giveaway behaviors. But display of number of paths (open and closed) and count of nodes in the current selection should always be provided. So should path length. These are some of the reasons why I've always preferred programs with an "Inspector" based interface (as in FreeHand since around version 3) which tells you everything you need to know (and set) about the current selection in a tidy, concise palette, instead of having the information scattered all across the interface. JET