JET_Affinity

There is no bug. This behavior is common to all Bezier-based drawing programs. Since paths can be opened, closed, cut, added to, subtracted from and otherwise reshaped at any time, it would be quite debilitating if closing of "straight" paths were somehow "disallowed" whenever a move resulted in a path's being "straight." Each "segment" of a path is a complete cubic Bezier curve. The interface of the drawing program effectively "strings them together" end-to-end. By definition, a cubic Bezier curve has four ordered XY coordinate pairs, even if it appears to be just a "straight line" with "just two nodes." The whole "nodes" thing is just an interface convention. The first and last of the four coordinate pairs are the "from" and "to", or "start" and "end" of the plotted curve, so are always located on the curve. So those are the coordinate pairs which drawing programs treat as "nodes" or "anchor points" or just "points." But the second and third coordinate pairs still exist, even with what appears to be a "straight line." They may be coincident with the first or last, or they may just happen to lie somewhere along the straight line between the first and last. Closing an open path simply adds another segment which starts where the last segment of the open path ends, and ends where the first segment of the open path starts. So there's no reason a single-segment path (your "straight line" with "just two nodes") cannot be closed by adding a second segment identical to it in shape. For example, forget straight paths and consider a curved path. There's nothing preventing you from doing this: Create a curved single-segment path; for example, a 90 degree arc. Copy it. Paste the copy in the same position, exactly in front of the original. You now have two complete cubic Bezier curves, each still having four defining coordinate pairs. Join the two identical single-segment paths at one end. You still have two complete Bezier curves. But the smoke and mirrors of the software interface treats this construct as a "single path with two segments." It's just treating the end coordinate pair of the first curve and the start coordinate pair of the second curve as a single "node" since they are at the same location. It's effectively "sharing" a coordinate pair between two Bezier curves and through the smoke-and-mirrors of the interface, enabling their associated "handles" (the third coordinate pair of the first curve and the second coordinate pair of the second curve) to be optionally "linked" in one of several behavioral ways when you manipulate them. Close the path. Now you have what the interface presents as a 2-segment closed path. It's still two complete cubic Bezier paths, each defined by four coordinate pairs, but the interface is effectively "sharing" two pairs of start and end coordinates and providing that optional "linking" at both of those "shared" locations (the two on-path "nodes.") This "closed path" still has a start and an end. It also still has a direction. But now, because of that wonderful "magic" of the software interface, you can: Select one of the two nodes. "Convert" it to a smooth node, causing the third coordinate pair of the first segment and the second coordinate pair of the second segment to act like they are interdependently "linked" so as to be constrained to make a straight line with the "shared" coordinate pair... ...and have a teardrop shape, while being confident that the two curves (segments) remain perfectly tangent at the other node. And now, just because the two segments are not identically shaped, it doesn't seem at all strange that a path having "just two nodes" can be closed. JET

That "PDF thing," though, may be a realistic opportunity for competitively exploiting Adobe's own lethargy. So far as I know, (I don't rent software) Illustrator and InDesign no better integrate the data fields capabilities of PDF "forms" than they did in CS6 (the latest non-rental version). I also don't know whether the "forms" functionality of PDF is as "open" as the rest of the PDF standard in general; but I'd bet some particular enterprising software developers know (or know how to find out). JET

They've heard me (and others) suggest it multiple times before at FileMaker DevCon. A great advance in the right direction wouldn't take much more than a few enhancements to its presentation layer: Full display of SVG in regular Container Fields. (I mean c'mon; it's already in buttons.) A Bezier path tool. Paragraph Styles. (It already has the corollary to object styles.) Embed fonts. (Needed for web-centric delivery, too, which after all, is an area of high FileMaker focus.) Oh...and "de-depricate" standalone runtimes. I don't mean to derail the thread. At least a basic data merge feature in Affinity Publisher should of course be expected and would be better than nothing. My general points are: "Better than nothing" is a pretty low ambition, especially for the bent toward innovation evident in Affinity. The rapidly growing need for seriously data-driven graphics is much bigger than just another "mail merge" feature, and I'm not sure its answer really fits the framework of conventional page-layout software, even when used in conjunction with the comparatively cumbersome data-driven capabilities of PDF. For now, the combination of one's favored graphics programs and FileMaker Pro can powerfully broaden the scope of enterprising graphics people, and is more approachable than many may assume. JET

Refreshing. It seems that with very few exceptions, user requests for adding features to this exciting new Affinity platform are couched in "me, too" terms. ("I need this single deal-breaking feature now, just as it is in [my pet program], or I'm outta here!"). There's not really much new under the 2D graphics software sun, and hasn't been in a long time. I blame that on the continued dominance of the market by a few historic monoliths. The good news is, almost every "me, too" feature request is a potential opportunity for breaking beyond the lockstep lethargy of current offerings. My constant hope is that the Affinity team is striving for something more innovative than the conventional wisdom standard-fare. One of the macro consequences of the decades of micro improvements to the mainstream titles is that in today's increasingly data-driven world, publishing and illustration programs seem farther and farther behind the times. Just another "me, too" data merge feature like those typically used for recipient address labels, etc. is already passé. Juha7one mentioned FileMaker and made my heart sing because I've used FileMaker to build fairly ambitious fully data-driven publishing solutions. Two examples: A 1000-page aftermarket parts catalog, the content of which is directly and continuously updated by parts information experts, not graphic designers, using straightforward data-entry screens, designed to precisely fit and streamline their tasks. The dataset is much larger than what will fit in a thousand-page print, and includes relational tables for brand-to-brand cross-referencing, live pricing, and more. The design is built in, up-front, and is flexible. The layout assembly and export to print-ready PDFs is entirely automated, requiring no "desktop publishing" whatsoever. Workers can on-the-fly isolate focused content by section or part type, and automatically generate print-ready "extracts" from the catalog for monthly specials, trade-show handouts, etc. An application that empowers Dealers to automatically generate their own individualized dealership-branded sales promotions (electronic or in print, in various formats) while keeping in full agreement with the factory branding standards. The application is a tidy six-step interface start-to-finish. Its dataset includes everything from the above-described product catalog database (access to tens of thousands of items), lookup functionality for current Dealer pricing (including a handy calculator for pricing on a per-item basis), the Dealer's Direct Mail info and indicia, and customer mail list. Those and other projects like them have convinced me of this: It would be far easier to turn a version of FileMaker Pro into a graphically-powerful data-driven publishing platform than to turn a conventional page-layout program into a powerful data-handling solution. All that would be required is to flesh out FileMaker's Layout Mode with a few more graphics-oriented features. I'm just an enthusiastic FileMaker user, and just mention it from that standpoint. When asked what my favorite "graphics program" of all time is, I only half-jokingly reply, "FileMaker Pro." Its approachability is well within the capabilities of most graphic designers, and for creative minds its use opens a whole world of data-driven publishing capabilities, either standalone or in conjunction with conventional graphics programs. JET

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

But why only the midpoint of a segment? What if I want to snap to thirds of a segment? Or divide a segment into fifths. An Add Nodes Per Segment command would enable one to create snap candidates at any fractional increment along a segment. JET

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

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

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

Again, a topic conjures up fond memories of FreeHand. FreeHand had just one kind of text object. It could be set to auto-expand horizontally (i.e., becoming functionally equivalent to a so-called "art text" object in other programs) by simply doubleClicking the right middle handle. It could be set to auto-fit its contained text vertically by doubleClicking its bottom middle handle. The text objects could be bound to and released from paths (instead of being treated as a separate "path text" object). They could be threaded, whether bound to a path or not. They could be set to auto-expand when bound to a path, thereby preventing the problem of accidentally truncated text in complex maps, as is so chronically common in maps built in Illustrator. This is conceptually parallel to the fact that FreeHand also never had any need for two separate selection tools. Its single selection tool enabled you to edit paths at the whole object level and at the node editing level. That elegant interface design made path drawing far less tedious, more fluidly efficient, and more powerful than any drawing program that insists on following Adobe's hideous model of two primary selection tools. Macromedia finally gave in to ill-advised "demand" from Illustrator users to add a second pointer tool. When added, it provided absolutely no additional functionality. It was literally nothing but an accommodation to Illustrator-habituated users who just refused to learn that it was absolutely unnecessary. FreeHand users simply ignored it. It was not until FreeHand's very last version that its white pointer did anything that the black pointer didn't, and even that was a minor detail that could have been implemented without adding another tool. Despite Illustrator's two selection tools (three, really, when you include the ill-conceived "Convert AnchorPoint Tool")--actually because of it--Illustrator to this day does not "know the difference" between a path being selected at the object level versus merely having all its AnchorPoints selected. This causes all kinds of silly inconsistencies such as being unable to use the Break Anchor Point command when all of a path's Anchor Points are selected. (You have to unintuitively de-select at least one Anchor Point for it to work.) Because object selection is so bedrock foundational to an object-based program, its tedious effects "cascade upward" throughout the program's interface. In a nutshell, it's what makes working in Illustrator feel as frustrating to beginners as trying to eat spaghetti with a single chopstick. It's because Illustrator's white pointer behavior is conceptually "upside down" from intuition. It's the selection tool you have to use to edit a path. But its first click always selects the most "internal" sub-part element of whatever construct you are trying to manipulate. Rather than intuitively selecting an object of interest and then "digging down" to its subparts with subsequent clicks, Illustrator's scheme first selects some "molecule" of the object of interest and requires use of a modifier key and subsequent clicks to "back out" of it to each next higher level. It's metaphorically like getting up in the morning and needing a pair of socks. So you intuitively try to open your sock drawer. But your hand passed right through the closed drawer, and the only thing you can grab is a single thread of a single sock. So you have to then use both your hands to select a single sock, and grab again with both hands to grasp the folded up pair. All this "Bizzarro World" behavior instead of simply opening the drawer and grabbing the pair of socks. The beginning of the end of FreeHand was not the Adobe acquisition. It was when it started to emulate Illustrator's hideous interface. Unfortunately, because things like selection tools and text objects are foundational to the program built upon them, I'm sure it's too late to back-track the existing conventional-wisdom (i.e. "like Illustrator") in either case. But I say again: If you want to build a better drawing program, Adobe Illustrator is not the program to emulate. JET

Nah. Sights set way too low. Anyone who has experience with Freehand's Graphic Find & Replace palette knows we don't need no cheezy magic wand tool. JET

I'm just not finding that to be the case. I'm an illustrator. My interest in scripting is not just a glorified macro; I use Javascript to programmatically draw things. I'm not a programmer per se, and don't play one on the internet. But I've been able to accomplish profitable things with JavaScript in surprisingly short order and with quite productive results: FlashScript interactive simulations which replicate the behaviors of real-world mechanical systems (multiplex wiring, regenerative exhaust systems, air brake systems) for training. A whole library which effectively adds important missing features to AI, including a set of non-modal palettes for facilitating axonometric drawing in any isometric, dimetric, trimetric orientation. Similar interactive axonometric tools by using Javascript to manipulate SVG in ordinary HTML. Integrating Javascript into FileMaker Pro calculations to build interactive axonometric "visual calculators" that run in FileMaker's WebViewer objects. I quit expending energy developing AI-specific Javascripts the instant Adobe started its Captive Customers scheme. But found it easy to lateral my developing Javascript familiarity from FlashScript to so-called ExtendScript to plain vanilla Javascript in HTML, and even into FileMaker Pro. I did all the above without reading tomes on Javascript. I've done it by just learning the basic syntax logic on W3C, looking at a few examples, and referring to the program-specific Object Model documents. Looking to do similar things in Inkscape meant getting familiar with Python. I've expended way too many hours of precious little spare time reading various Python books, starting with downloading the resources that have to be installed on the machine, dinking with the command line interface, yadda yadda. While there's nothing "difficult to understand" per se, I have yet to accomplish anything actually useful with it, don't find it any more intuitive than JavaScript, don't particularly care for its sensitivity to white space. Can I do it? Sure. But I've already found the afore-mentioned ubiquity of JavaScript across platforms and disciplines advantageous. I have yet to see any compelling reason to "start all over" with Python, other than it's been adopted by Inkscape for developing extensions. But that already seems more cumbersome than what I was doing with Javascripts for AI. (And yeah, I know this is mainly just a matter of my familiarity.) Again, I'm not the expert in this. But every time another language comes along, its devotees start over-evangelizing it as a replacement for everything pre-existing, and frankly I've grown weary of that over the last few decades. It's not that I have anything "against" Python. My own daughter-in-law uses it for various things (mostly related to gaming). But I also don't see JavaScript "going away" by any stretch and even in my modest experience, I have had much opportunity to appreciate its general versatility. So, for what it's worth, and since we rather presumptuously seem to think the Affinity Team's decision is going to be driven by a "scripting election" in this thread, my vote is for Javascript--and a very thorough object model document. Seems a safe bet to me. Oh...and having abandoned MacOS almost two decades ago, and despite being an avid FileMaker Pro devotee, I have no more use for scripting anything with a proprietary language prefixed by "Apple…" than anything strictly proprietary to Adobe.

Your use of "transformed" and "morphed" suggests the feature generically referred to as blends. But your screenshot depicts and your use of "rotate and scale" suggests a reiterative transformation, often called "power duplication." Results can be similar, but they are not the same thing. Object blending is not yet offered in Designer (nor, therefore in Publisher). But because it's been regarded sort of a staple for vector-based drawing programs since the early days, I'm sure it's planned. (As I recall, it's probably already on the road map.) Most mainstream drawing programs at least provide for ordinary path blends (interpolating between constructs consisting of Bezier paths). Illustrator's Blend feature can blend between most anything, including most anything stored as a Symbol, and live effects applied to the key objects. In this sense, "live effects" means most object attributes (Graphic Styles, for example), whether they are actually called a "Live Effect" in Illustrator's interface. For example, in Illustrator, you can blend between instances of paths to which its 3D Effect has been applied (with the potential for memory problems if done too cavalierly). Reiterative transformations, however, are provided for in Affinity Designer, by use of the Transform commands in combination with the Duplicate command. So that may be accessible in Publisher, too. (I just haven't had more than a few minutes' time to explore Publisher yet.) Try searching for "duplicate" in its documentation. Generally, the differences between blends and reiterated transforms are: As usually implemented, Blends start with "key" objects and then automatically interpolate the intermediate steps between them in terms of decoration attributes (strokes, fills, other effects) and some transformations (scale, rotation, skewing) and initial positions. For translations (movement) along curves, though, they rely on following a separate path used as the spine. Because the intermediate steps are automatically interpolated, your control over certain things like precise spacing is somewhat limited by whatever parameters provided in the specific program's Blend interface. So, for example, in the typical spiral-like transform as in your screenshot, the spiral is usually a separate path, and your control over the spacing is somewhat limited, but still adjustable after the blend is made. In reiterated transforms, the spiral is just a consequence of the precise values you've entered for the scale and rotation transforms. After it's done, it's just a stack of separate and individually-sized, scaled, rotated copies of the original. So blends would be more in line with the concept of "morphing one object into another." So-called power duplication would be more in line with just generating repeated transformations of copies of the same object (as in your screenshot). JET

Wosven, In Beta 1.7.0.58, I don't see any ability to access the center-of-transform anchor when editing Nodes. JET

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

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

Regardless, the request for a hairline stroke weight setting is valid. (It's been brought up before in other threads.) For those not familiar, a hairline stroke weight always renders at the smallest width possible on the output device, be it your monitor or an imagesetter. This is advantageous when drawing paths in detailed illustrations, during which we are constantly zooming in and out. Having stroke weight set to hairline feels more precise and is less distracting because the stroke weight is always drawn the same, regardless of zoom. The extreme zooming capabilities of Affinity as compared to other programs buttresses the point. It's a great feature, a standard setting in PostScript, and it should be provided in every vector drawing software. JET

I just want to know where my nearest Affinity GT dealer is. That would be a pretty neat car for $50. JET

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

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

I've long argued that in a vector drawing program, any path should be able to be converted to either a selection marquee or a cutting path. JET

I know I don't. What I favor is something that removes the redundancy of ordinary old fashioned arrowheads and more modern related features (vector brushes, symbols) treated as separate features, but that is more powerful than both. And as a technical illustrator, I assure you, I fully understand the need for traditional arrowheads. But they don't have to be implemented as the kind of limited feature they historically have been in other programs. Often, that kind of archaic treatment is just kept for backward compatibility with previous versions. That is one area where Affinity should have the luxury of moving beyond conventional wisdom. JET

Exactly. It's not just about circles. Or icons. Far from it. Because although it's not traditionally been called that, being so basic a feature, stroke weight is really just an effect rendered at output. Effects don't cut it for anything requiring actual path geometry. Ordinary Boolean path operations (subtraction, union, intersection, exclusion, etc.)—required for all kinds of common drawing constructs—are all based on the actual path geometry, not on the merely visual appearance of a stroke weight. Anything destined for physical reproduction via NC cutters, plotters, routers, etc., also must be actual paths that the tool follows, not just appearances painted on your monitor or rasterized by a RIP. We all want more sophisticated and functional vector-based brushes in drawing programs. Those constructs and their interfaces are entirely program-specific proprietary. But we all also have to transfer our vector-based artwork to other programs. So such features are pretty much useless if artwork employing those features cannot be reliably normalized to basic paths that survive export to common exchange formats. Having to resort to rasterization in order to reliably keep shape is not acceptable. Back when drawing program first started acquiring the ability to "convert" text to paths, the differentiating factor was this: Some programs (properly) did it by actually accessing the outlines contained in the font. Others didn't. As I recall, one example was Quark XPress. At the time it was the "standard for professional quality; the industry leader" (i.e., all that jazz Adobe devotees like to say about Illustrator nowadays). But its first conversion of text to paths was hideous until corrected. That's similar in principle to the now expected quality of "outlining" stroke weights. One of the first things experienced vector graphics users check when evaluating a new program is the quality of expanding strokes and other effects. If it results in excess nodes and visible changes in the shape, it is a very poor implementation and can be a deal-breaker if not soon rectified. It is a very serious problem in Affinity Designer, but I believe the developers have acknowledged it and probably planned for addressing it. JET

Yep. That's the kind of functionality FreeHand's wrapping tab provided; effectively rows that auto-fit vertically the text in any column(s) that are defined by the wrapping tabs. The beauty of it is the simple elegance of its implementation (typical of FreeHand). It's simply another kind of tab settable in the text ruler, just like left, center, right tabs. I never had opportunity to use Ventura Publisher. But I've always considered its discontinuance to be Corel's largest competitive disadvantage re Adobe. Corel's bundles offer much more than Adobe's for the price. But the lack of a page-building application dissuades too many graphics users. JET

I seldom use them, even a page-layout program. I construct my tables with tabs and proper paragraph styles. FreeHand had an unobtrusive little feature in its text engine called a wrapping tab. I've never seen it in any other program, but it is such an elegant solution for much of what one typically does with tables. Now, if the program had a "table" feature that could actually function as spreadsheet or calculator for purposes of data-driven text and graphic content; I could go for that. JET