JET_Affinity

Otto, In a 2D vector environment, the kind of distortion you depict is essentially an envelope distortion. It's not "wishful thinking"; it's quite common, there are other feature request threads about it, the developers have acknowledged it and stated that it is planned. The fact that envelope distortion features are common in this software category does not make them all equal. It is a generic term, and implementations range from good to very poor. The interfaces of some are just a few lame handles that you use by 'eyeballing' the result; others are based on geometric principles of perspective projection. Envelope distortion is the basis of many different interface features. For example, Illustrator's Free Transform Tool, Warp, Mesh, and Perspective Grid features all involve different implementations of envelope distortion. So what users have in mind when asking for it can be all over the place. What satisfies very basic enveloping like your example, will no doubt invoke criticism from others. Personally, I have no use for more features rushed-out-the-door in 'me, too' fashion just because users are impatient. I want to see it done right and done well with some innovation and elegance in Affinity, not just rushed-out-the-door like Arrowheads. JET

Two weeks! Everything you need will be done in two weeks. (See The Money Pit.) Seriously, no one can tell you 'when'. And there are already other threads about this. While we anticipate possible new features, our contribution should be well thought-out ideas about how the desired feature should work and perhaps how it could improve upon standard-fare. 'Perspective Tool' is vague because 'perspective' is a broadly generic term. Multiple treatments exist for 'perspective' drawing, some more geometrically valid than others. The most exciting 'new wrinkle' I've seen in the 'perspective' context in a long time (since the advent of FreeHand's Perspective Grid, which was much later poorly mimicked in Illustrator) is Lazy Nezumi; a utility application that acts as an 'interface overlay' to geometrically translate your gestures to most any 2D graphics program you're using. But that's an entirely different thing from an envelope-based warping feature. JET

Agree. It grieves me to see new features released in a sub-par state. It needs not only multiple contours, but control over spacing rate, either uniform or increasing / decreasing. (Think of surface contour lines on maps.) See CorelDraw's Contour Tool. It's been around so long and so many use it that that's going to be expected as minimum functionality by thousands. As a minimal workaround, there should at least be a keyboard shortcut one could tap to commit a contour while dragging the tool, so one could continue dragging for the next contour, commit it, and so on. JET

To my mind, 'baking' the appearance of applied effects is an excellent term. Far more intuitively suggestive of the concept of committing to something than is 'expanding' it. What am I 'expanding' when I 'nail something down'? JET

Bah. One guy's opinion. Don't worry. I won't be surprised. I also won't be surprised if it doesn't. If it does, I'll stop buying it, just as I did with Adobe, as soon as it made that announcement. If it doesn't, I'll continue updating my perpetual license. Simple as that. As it is, Corel is getting a significant portion of the money I no longer pay Adobe. JET

Lest anyone be misled, this is not true. Corel offers both subscription and perpetual licensing; customer's choice. Corel should be commended (and supported) for not forcing a take-it-or-leave-it rental-only license scheme. I despise software rental schemes as much as anyone, and will not pay them. But let's not throw the baby out with the bathwater by spreading erroneous information. So far, Corel is still one of the 'good guys.' JET

A simple "Select Inverse" command nested with the existing Select Previous and Select Next would work for that. It doesn't need to be associated with any 'Select Same..." feature. You could make as complicated a criteria-based selection as you want, and the Select Inverse command would work for that. Or, you could simply make any kind of selection you want having nothing to do with attributes (objects within a lasso selection, for example) and the Select Inverse command would work for that, too. In a nutshell, you guys are basically talking about what has been mentioned in the various related Feature Requests: Something more akin to FreeHand's Graphic Find and Replace feature than Illustrator's comparatively lame late-to-the-game answer to it (a few Select Same... commands). Obviously (and unfortunately) Serif decided to go with the latter (I assume to assuage the incessant "must have it now!" demands), rather than the former. So now we have it, and here we are in the Beta testing and feedback forum still trying to get it turned into the former. For those not familiar, FreeHand's Graphic Find and Replace was not a clutter; it resided in a single but powerful palette. It could select or replace combinations of attributes, and with ranges where appropriate. SQL is fine for databases. I also use it everyday. But if you want to provide for user-defined logic for finds (yeah, I'm a FileMaker guy), in a graphics program, you can kill that stone—and countless more—with one bird: a JavaScript object model, API, and documentation. As with what I see as the 'we gave in' Arrowheads treatment, I'm disappointed in this Adobe-esque Select Same feature. But the ship has sailed, at least for now, and this software segment continues drifting in its 'me, too' doldrums. Hope for making it something better at this point just constitutes more Feature Request discussion. JET

I'm aware of that and quite agree. However, what got me here was clicking a Notification yesterday that responded to one of my posts. The subject caused me to assume I was in the feature request forum. This whole thread should have been moved. JET

Especially given that Affinity does not provide transformation tools, but insists upon all routine tactile transforms being dependent upon bounding boxes, why not provide a bit of innovation to make the omnipresent and cluttering bounding boxes more useful? An illustrator should be able to perform tactile transformations in any direction desired, not just in the horizontal and vertical directions of the page, and not just in the direction of the bounding box's current or original orientation. Why can we reset the bounding box and rotate the Canvas, but cannot rotate the bounding box itself so as to freely orient its transform handles in a direction that is meaningful to the illustration in progress? Affinity's tactile transformation handles are all attached to a bounding box which often has absolutely nothing to do with any detail-of-immediate-interest in the drawing. The bounding boxes have FIVE rotation handles! Not just one at every corner (as if we even need more than one), but also that additional giant obtrusive 'lollypop' lever. Why not simply provide a momentary key modifier that, if pressed when dragging the lollypop, will rotate the bounding box around its content, so that we could thereby freely and instantly reorient the scaling and skewing handles, and zero the rotation angle, to perform their transforms in whatever direction we need relative to the artwork? JET

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

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

That would seem obvious. But laboriously painting raster frames for an animated GIF is, well, laborious. But in a vector-based program with a blend capability, creating a sequence of frames is a simple matter of rasterizing the blend's steps. That can be done by simply taking a screenshot of a 'stretched out' blend and then cropping it into individual frames. But a command that simply rasterizes individual blend steps and exports them as a set of GIF frames eliminates that tedium. The advantage of starting with a vector blend is that it automates the tweening. So scaling, skewing, rotating (or any combinations of those) is much less laborious. And each frame is effectively individually rasterized from a pristine original, not a transformed raster. So just as one expects a vector-based drawing program to be able to export the whole file's content to raster formats, there's no reason not to enable it to export an object blend as a series of raster frames. A vector drawing program with a blend feature can 'break apart' or 'expand' or 'flatten' (or whatever the publisher decides to call it) a live blend to deconstruct it into the stack of individual objects that it really is. When Flash was in its hey day (before Adobe's acquisition of Macromedia), Illustrator was provided the ability to export the stack of 'expanded' blend steps as Flash frames. But frame-by-frame Flash animations—even when containing vector-based artwork—are really rather lame. They limit the whole resolution independence advantage of vector-based artwork to mere scalability of the whole movie. The real power of Flash is not frame-by-frame animation, but in programmatic—and therefore interactive—transformation at the individual object level. But animated GIF is nothing but a series of raster frames anyway. So I consider the ability to export steps of an expanded blend in a vector-based drawing program as GIF frames perfectly appropriate—once Affinity gains a (hopefully full-featured and innovative) object blend command. JET

Alfred is here for the same reason everyone is supposed to be here: to discuss a topic and it merits, not just vote yea or nay. And NOT to throw personal insults. JET

I generally have some kinds of snaps turned on whenever I'm drawing. Snapping to nodes is probably the snapping behavior I most commonly need. So an explicit "Snap To Nodes" would certainly be more clearly-defined and intuitive than "Shape Key Points" or "Object Geometry." "Object Geometry" is pretty ambiguous. To my mind, important object geometry for snapping and alignment would include V and H extrema (and other tangents) of curved segments. JET

JET

If you have several objects overlapping, having Snap to Bounding Boxes turned on is of little use when you can't see the bounding box. For example, what am I snapping to here?: And by what logic does dragging a Guide out from a Ruler cause the current selection's bounding box to disappear, but doesn't cause other selection indicators to disappear?: And why don't Guides snap to nodes? JET

Yep. If I turn that Prefs setting on, just scrolling (without modifier) zooms. But if it's off, I get the behavior I described. Affinity Designer 1.8.4.693; Windows 10. JET

On Windows, with the Text Tool (or other tool) active, the scroll wheel of my mouse: With no modifier: scrolls vertically With Shift: scrolls horizontally With Ctrl: zooms All without invoking different tools. In Illustrator CS6, it's similar: No modifier: scrolls vertically With Shift: scrolls vertically in larger increments With Ctrl: scrolls horizontally With Alt: zooms The upshot is that you really can't expect all drawing programs to use exactly the same momentary keyboard modifiers. As you mentioned re Photoshop and Illustrator, even different applications owned by the same vendor don't have perfect consistency between programs. JET

Nope. But neither does Illustrator. That's all I was saying. So it's yet another low-hanging-fruit opportunity to move this software segment out of its decades-old doldrums. It's much the same with Illustrator's Measure Tool, which is why I never use it. It doesn't reliably abide by snaps, and Illustrator snaps themselves are unreliably too zoom-dependent, even if you have Smart Guides switched on. Illustrator's Line Tool makes a much better 'Measure Tool' because it is more tactile in snapping: Drag it between two snapping candidates. Click. Its modal dialog opens right in front of you, telling you the length and angle. Dismiss the dialog and tap the delete key to remove the 'measure line' if you don't want to use it as part of a poor man's dimension object (which I do by means of a Javascript). Everything in Illustrator is a workaround. JET

Yes, yet another example of Illustrator's not being the software to emulate. I was among those petitioning Adobe for years to provide access, within Illustrator's normal interface, to the 'secret' programmer's window that could be invoked if you knew the 'Easter egg' shortcut. So Adobe finally added it to the flyout menu of the Document Info panel, which you need to invoke twice to individually turn on the options Selection Only and Objects. Not exactly an intuitive or elegant GUI implementation. JET

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

When discussed as feature requests, please try to clarify what exactly is being requested. "Dimension Tools" should be a toolset for creating live dimension objects. Constructs consisting of witness lines, arrows, and text that updates when its parameters change. (Like in Corel Draw or Canvas.) A "Measure Tool" is often just a rather lame tool that one drags between two points of interest and then presents either some readout on screen or in a dialog or palette somewhere. (Like in Illustrator; in which, by the way, the Line Tool makes a far more useful 'Measure Tool' than the Measure Tool.) Access to any path's actual length (or area, angle, etc.) is yet another thing. I'm not claiming it's any kind of industry-standard substitute for actual Dimension Objects or for display of path lengths, etc. But for those needing an occasional dimension when drawing to scale, you can use the Point Transform Tool thusly: JET

So long as its a user-defined preference. That's the problem: You're speaking of a specific task. I have no problem with your suggestion if implemented as a user-specified preference setting (although that raises the whole larger issue of Affinity's need for a seriously better preference interface.) Even then, you'd need to elaborate. For example, what do you consider the 'center' of an equilateral triangle? For most purposes, it's certainly not the center of its bounding box (which raises what I consider one of the most fundamental problems with Affinity: its insistence upon on-page transformations being based on infernal bounding boxes.) JET

'Till my dyin' day. For all the good it will do. JET

So you can delete them? In Illustrator, if you alt-click a path with the Direct Selection Tool, it will select all the AnchorPoints of that path. But then tapping Delete deletes the whole path, not just the AnchorPoints. In Affinity, if you just select a path with the Node Tool, the nodes highlight, but no nodes are 'selected'. Nonetheless, tapping Delete still deletes the whole path. Or am I misunderstanding your intent? In Affinity, if the path(s) of interest are unselected and you want to select them with the Node tool and then move the whole path(s), you can: Click an un-selected path with the Node Tool (and shiftClick to select others). Tap Ctrl-A to 'select all'. That will select all the nodes of the highlighted path(s), but nothing else. OR Without changing tools, drag a marquee selection around highlighted path(s), or a portion of them. Doing this will not select other un-highlighted paths, even if they are fully within the selection marquee. Mousedown on any of the nodes to move the selection. So you can arguably do steps 1 and 2a within a second, too, once you're accustomed to it. The problem with Affinity's behavior in this regard is that, with a path already selected with the Move Tool, merely selecting the Node tool highlights all the path's nodes, but selects none of them (which is unintuitive to begin with), thereby changing the selection state of the current selection. To my mind, this is not justified. When a path is selected by the Move Tool, the whole path is selected (i.e., all its segments and nodes). That should not change by merely switching to a different selection tool. In other words, when a path is already selected by the Move Tool, switching to the Node Tool should leave all the nodes selected, not deselect them all. As a general rule, merely changing to a different tool has no business changing the current selection's selection state. So I'm not defending Affinity's interface in this regard. Both programs' interfaces sometimes violate the base concept of "selection." But as always, Illustrator's interface is not the one to emulate or to aspire to. In multiple scenarios, Illustrator's behavior treats 'AnchorPoints' (nodes) as if they are separate and distinct entities from segments. But of course, a segment cannot even exist without nodes. There is no such thing as a 'node-less' path or segment. This is why Illustrator is more prone to creating so-called 'Stray Points' than any other program in class. It's also one of the many things that makes Bezier-based drawing seem so needlessly confounding to newcomers. If you haven't yet, you should also get fully acquainted with Affinity's Point Transform Tool (F). Once acustomed to it, you may find this a refreshing change from Illustrator. JET