JET_Affinity

I'd prefer the momentary press of a modifier key over a separate setting that makes you leave the path in progress. When drawing vector paths, one uses modifier keys continuously; to constrain to horizontal or vertical; to break a tangency when dragging out a curve handle, to sense snaps, etc. Bending a segment is the same kind of thing. I certainly would not want it to always constrain its associated curve handles to their current angles. I might want that behavior in one segment of a path, but might want the other behavior at another segment of the same path. In fact, I very well might want to freely alter the skew of the associated handles initially, and then constrain them to their new angles the angles in the act of performing a single bend. JET

It should be optional, invoked by a momentary keyboard shortcut, as described in the original thread. Either behavior is equally advantageous in as many situations. JET

My point is what I said, Luis: A bit of perspective. I'm not attacking your feature request. I am saying that its "essential" claims are grossly over-stated. Practically everyone with a wished-for feature claims that theirs is "so basic to drawing programs that Affinity Designer is rendered useless without it." Yet I dare say most never even heard of "Isolation Mode" until Adobe called it that in 2007. You've received replies from Serif on this. There's no need to "pile on" about it. If that were all it is, it would just be an email direct to Serif. It's not just where we ask for features; It's where users of varying experience also discuss the merits of those features. JET

For perspective: Illustrator's "isolation mode" did not appear until CS3 (2007). If it's such a 'deal breaking, bedrock essential basic' feature (just like everyone's pet feature request is), how did anyone use Adobe Illustrator for the two prior decades? I paid $50 for Affinity Designer. You know how much money I spent on Adobe Illustrator prior to 2007? My use of Illustrator's Isolation Mode is only occasional. And I certainly don't judge any program that doesn't have something like it "unusable." JET

Correct. Proper logo designs of all things should be created with the most painstakingly efficient and elegant paths. The more vector-appropriate the artwork, the less excuse for auto-tracing. Else, you lose the resolution independence advantage that vector-based graphics exist for in the first place. Certainly anyone claiming to do commercial quality vector illustration (i.e., charging money for it) should be proficient in drawing optimal paths with the appropriate tools. And that's where anyone learning to create commercial-quality work should expend energy; not in tweaking a bunch of tolerance settings in an auto-trace feature. The more vector-appropriate the artwork, the fewer and cleaner the paths should be, so the less "time consuming" it is anyway, for someone who knows how to do it right. So when it comes down to it, the only few-and-far-between excuse for resorting to auto-tracing is for things that are just too complex for drawing with deliberate and intelligent discernment. And even in those cases, one should always ask oneself if auto-tracing is going to yield any technical advantage anyway. See the self-cancelling cycle? It's not the beginning users' fault. The software vendors grossly over-glorify the "automagic" of auto-tracing features with claims like "Instantly convert raster images into resolution independent vector graphics!" That's the myth perpetrated among hobbyists. There is no "conversion" to it. Raster-to-vector is not some kind of unambiguous code translation, like converting a TIFF file to a PNG file. The only lossless 1:1 "conversion" from a raster image to a vector graphic would be literally tracing a square path around each and every pixel. And that would have absolutely zero resolution-independence advantage over simply using the original raster image. That technically "perfect" auto-trace would also be perfectly useless. No, there's just re-drawing the subject. And auto-tracing doesn't even make any attempt to re-draw the subject, because it has no idea what the subject or its purpose is. It merely tries to draw paths around contiguous clusters of similarly-colored pixels, utterly regardless of shape or meaning. So you either re-draw the subject with meaningful (and hopefully aesthetic) human discernment, or you entrust it to a completely dumb algorithm that has (as of current standards) absolutely none. JET

I don't know what that has to do with this thread (which is just a repeat of existing auto-trace threads). But if you want to see, say, a thoroughly well-done Javascript implementation in Affinity, I'd be right there with you. I've said as much in existing feature wish threads. (I'm not really interested in coding—or buying—plug-ins.) But now may not be the time since the feature set (and therefore, I assume, the object model) of Affinity Designer is still very much under development. JET

No. Just slightly more convenient. For other examples in addition to the scanning utility already mentioned: I use the Windows Calculator utility quite often, every day, while working in most every program I use. Same thing goes for the screen capture utility, TechSmith SnagIt, and the standalone Bitstream Font Manager that comes bundled with CorelDraw. Launching any of them is, at worst, a single click on the TaskBar. (SnagIt is invoked by a keyboard shortcut.) I find that no more arduous than clicking a tool button or making a menu selection in order to invoke yet another auto-trace feature to twiddle with yet another UI, just to get pretty much the same result. I use multiple programs all day. I also use multiple vector drawing programs. I don't need a differently-branded UI corresponding to each different drawing program for every calculation, screenshot, scan, or auto-trace. I actually prefer using the same familiar interface for scans and screenshots and font management, regardless of what graphics program I'm using. It's actually more efficient that way. Auto-tracing is just as appropriate for that kind of "standalone" use. It doesn't need to be re-invented in every drawing program. There are decent auto-trace solutions (at least as defined by the current state of it) available to everyone for free, even. Unless and until Serif (or anyone else) has some kind of game-changing functionality to make it more than what it currently is (generally bad practice anyway), it's not even on my "missing features" wish list. For example: I have yet to see any auto-trace program (targeted to mainstream general graphics users) that knows what a child knows: that when it's scanning the pupil of my puppy's eye, the resulting path should be an ellipse. So yeah, if and when the Affinity team happens to have in its secret closet an auto-trace feature with sufficient artificial intelligence for at least basic shape recognition, that might be something worth introducing. JET

Yes, Illustrator has an auto-trace feature, as do most similar programs. Not that it matters. What many don't know is that Illustrator was very late to the whole auto-tracing thing, as it was in many other features. All three of its main competitors (FreeHand, Draw, Canvas) had full auto-trace features, while Illustrator (up 'till around version 9, as I recall) had only a crude trace command that only traced one color at a time. Nowadays, auto-trace features are very common both as built in features and as online services, and there are even free implementations of both. Tourmaline mentioned Inkscape and you yourself mentioned Vector Magic. And although their user interfaces differ in terms of eye candy, they all do pretty much the same thing, and results are all pretty much alike: "Garbage in, garbage out" very much applies. So as for "why," consider that in context of Tourmaline's first reply in this thread, in which he paraphrased Serif's replies (which you can read if you do a quick search for the already-existing threads on this commonly-requested feature). Unless and until Serif has something game-changing to bring to the auto-trace table, there are more valuable things for its dev team to focus on which constitute real opportunity for long overdue innovation in the vector-based drawing arena. I am among those who see no need for yet another "me, too" auto-tracing feature in Affinity. It's no more onerous to switch to another program for this very single-purpose function than it is to, for example, launch the scanning utility of my scanner. Even Corel long delivered its auto-trace solution as a separate standalone utility that was simply bundled with Draw. Moreover, when it comes down to it, auto-tracing is a bad practice that usually just swaps one kind of resolution-dependent ugliness (bitmap pixelation) for another (poorly-drawn vector paths). JET

Hear hear! It's been demonstrated that a lot of nice things can be done with the brushes in Designer, but calling them "vector" brushes just because the raster images they contain follow a spline path, is entirely misleading. Actual vector brushes (in which the brush's base artwork is vector paths) enable you to do an entire world of more powerful things: For example, A single "Pattern Brush" in AI can be built to enable creation of a mechanically correct hex bolt of any length and diameter. As always, Illustrator's implementation could be easily exceeded in power and versatility, and that's what I want to see in Affinity Designer. Hopefully, that's what the eventual goal is (perhaps after sorting out the problems associated with the present sub-par expanded stroke results). But it is disconcerting that the current brushes are called "vector" brushes. That doesn't suggest that what you (and I) would call "real" vector brushes are on the unpublished road map. This is also why I am so very disappointed in the merely "me, too" treatment of arrowheads. I am convinced that a truly innovative implementation of what I call path stokes and path ends that could be combined into user-defined path styles could yield both a much more powerful "arrowheads" feature and a vector-brush feature more powerful, versatile, intuitive, and elegant than Adobe's treatment. It would be a true game-changer even for long-time AI users who have never really discovered the kind of brush-based applications I'm talking about, just because Adobe's treatment is too "standalone" as opposed to being truly integrated with its own preexisting features of the program. That is what I see as the core of potential advantages over Illustrator: The fact that it is a decades-old stack of newer features merely "bundled with" a bunch of outdated basic features. I see that opportunity diminish whenever I see a feature implemented in a mere "me, too" fashion, as is arrowheads. JET

It's called applying pressure. It's called the silly belief that if you merely scream the loudest and most repetitively ask "When? When? When?" and make ridiculous claims that the program is absolutely useless without your pet feature, then you will somehow win out over every other person who employs the very same tactic about their pet feature. JET

Butting in? This is a public forum. I'm here because I do not find Affinity "useless" just because it doesn't yet have every feature it eventually will. Your questions have been answered. Serif is not going to tell you "when." I wouldn't expect them to. JET

Then "some other people" are lucky enough to be like me. What do you people expect to get from demands like this?: User: "WHEN IS [my pet feature] GOING TO BE PROVIDED?" Serif: "December 25th, 9:15 AM." ? JET

There are plenty of programs I have no use for. So I don't use them. And I don't waste my own time repeatedly asking their makers "WHEN is such-and-such going to occur?!" JET

You obviously have no idea how long it took Illustrator to acquire its meager Select Same... commands—and many other things people here call "must have deal breakers." JET

va2m, I am on topic. As I said: That's not to say that the willy-nilly kind of informal converging perspective is "illegitimate" as an illustrative style. It's not. Grossly exaggerated perspective is commonly used just to add overstated drama in everything from Marvel's super hero comic books to the Marketing Department's rendition of the corporate trade show booth. My point is that "vanishing point perspective" is a broad subject encompassing methods and purposes that range from rigorous to whimsical. So a "good" software implementation of it is an ill-defined target. Again: The familiar kind of 2D "vanishing point" perspective drawing as taught in general art classes and as usually practiced, it is not a consistent, specific geometrically-derived construction discipline. It is done differently by different people for stylistic reasons. And there's nothing "wrong" with that. I'm saying because it is more style-driven than geometry-driven it is rather ambiguous; there is not a single clear-cut, well-defined, consistent construction method for it that embraces all that arbitrary stylistic freedom. 3D modeling software does indeed emulate what a lens sees. But that's an entirely different thing from just setting up one or two or three 2D converging grids in a 2D drawing program based on a few arbitrarily placed "vanishing points." Okay, so now you're more specifically saying you want something like Illustrator's (i.e., FreeHand's) feature. Frankly, I don't. It is stylistically limiting. You can't, for example rotate its horizon. It's always assumed to be horizontal. Again, look at comic books. The common bird's-eye-view perspective of a super hero soaring above NY sky scrapers often has non-horizontal "horizons" just as do views from the perspective of inside an airplane cockpit. And why just three vanishing points? "Vanishing points" are not based on any three universal "locations in space", they are really just based on lines that an illustrator extends from parallel lines in whatever objects he is drawing. That works fine for cliché' rows of boxy objects like tall buildings conveniently oriented parallel to each other on streets that all conveniently intersect at right-angles. Depending on what you're drawing, you could need any number of "vanishing points." Said another way, there is only one "real" vanishing point; the one corresponding to your line-of-sight, located at the center of your field of vision. So how do you emulate that as guides in 2D drawing software? You'd need to provide as many arbitrary focal points as the illustrator wants to place on the page, and somehow make the all their envelope distortions interdependent relative to a center-of-vision. Which requirements? The ability to freely add and remove drawn shapes to and from the "planes"? No, LNP does not do that, because LNP is just providing you guides on your screen, not creating actual envelopes in your drawing program. That's what FreeHand's / Illustrator's Perspective Grid feature is: a set of envelopes. Affinity doesn't yet have an envelopes feature, but mesh and warp envelopes are on the planned feature list. Depending on how innovatively implemented that is, as far as we know, it could serve for "vanishing point" perspective among the other things for which envelopes are employed. JET

Convincing 2D converging perspective is not that simple. If it were, we wouldn't need any special features for it. We can already just draw arbitrary horizon lines and perspective rays like we do on paper. Nor do I assume it's that simple to implement in software. Have you tried the Perspective Grid feature in Adobe Illustrator (which it copied from FreeHand)? Many users no doubt think it must be rigorous just because it's in software. But it's easy to catch it committing the common error in which foreground grid "squares" become less foreshortened vertically than horizontally and therefore look like elongated rectangles instead of squares (not at all how the eye would see it). Here's the thing: The kind of casual "vanishing point" perspective typically taught in basic art classes is actually not very rigorous. Students get exposed to so-called "one-point", "two-point", and "three-point" perspective and are led to assume that three-point perspective is some kind of end-all of ultimate realism just because the subjects we draw reside in 3D space. It's not. A view of 3D objects in 3D space can have an infinite number of "vanishing points." (Think of tossing your toddler's collection of building blocks upward into the air and taking a photo.) Yet just watch a few of the many amateur YouTube videos on the subject and listen to how many times you hear the demonstrators use phrases like "There you have it; a perfect perspective of [this or that]!" Also note that they typically just place their vanishing points at any random locations relative to each other, without any kind of actual geometric basis. Rigorous converging perspective must be based on the geometry of optics; of conic vision. Grid squares don't merely shrink toward the distance, they change in shape. (I wonder how many graphic designers and even illustrators understand that if you take a photo with a "normal lens," crop it down to a distant part of the subject, and then enlarge it, the resulting image looks like it was taken with a more "telephoto" lens.) There are more formalized methods of constructing converging perspective. For example, before computers architects used a more elaborate construction method which did a better job of constraining things to realistic proportions. Technical illustrators had special equipment like Klok Perspective Boards and Tables and their graduated ruler scales. That's not to say that the willy-nilly kind of informal converging perspective is "illegitimate" as an illustrative style. It's not. Grossly exaggerated perspective is commonly used just to add overstated drama in everything from Marvel's super hero comic books to the Marketing Department's rendition of the corporate trade show booth. My point is that "vanishing point perspective" is a broad subject encompassing methods and purposes that range from rigorous to whimsical. So a "good" software implementation of it is an ill-defined target. Axonometric drawing, by comparison, is not like that at all. There's nothing ambiguous or arbitrary about it. It is either geometrically correct or it is not, in fact, axonometric. Again, the Lazy Nezumi Pro approach to interactive drawing aids causes me to re-think the need for program-native features for converging perspective. For example, one of the demo video clips on the LNP site demonstrates its Fisheye perspective variant. How often have you ever seen that kind of 2D perspective convincingly executed by the traditional "vanishing point" methods? That novel implementation alone represents a lot of potential. In my previous post, I mentioned that the applicability of LNP to vector-based drawing is largely dependent upon the number and quality of Bezier path drawing tools that are used by dragging along the onscreen guides. It may be more advantageous for Affinity development to simply focus on optimized Bezier path tools that are of superior quality in terms of functional economy and editing elegance; i.e., the number and placement of nodes and handles automatically generated when the tool is dragged. JET

Meanwhile, as Frozen mentioned, to those who haven't yet, it really is worth looking at Lazy Nezumi Pro. LPN's claim-to-fame is that it is not an "add-on" for any particular graphics program. It sort of gives your computer some drawing smarts, instead of just a particular graphics program. The drawing or painting program you're using doesn't even know it's there. You just launch it and then click the application window that you want to work within. It works by affecting cursor movement at the system level, "smoothing" your pointing device movements to constrain to the on-screen guides that it effectively "overlays" within that window. It's the closest thing I've seen to software actually emulating the use of physical drawing aids like rotatable rulers and ellipse templates. The way it works gives it these huge advantages: Although it has a quite sophisticated collection of setup options, it's worth the learning curve because you learn it once and it works the same way regardless of what drawing or painting program you're using at the moment. Although originally presented as a drawing aid for raster-based drawing, it's not just for raster imaging. It's just as applicable in windows of vector-drawing applications; it just depends on your having selected an appropriate drawing tool. Yeah, it works with path drawing tools you think of as "freehand" (pencil, brush, etc.), but it's just as useful for a line tool (or Affinity's Pen Tool in Line Mode). It's basically appropriate for any tool you drag along the desired direction because that's what it does; it affects the smoothness or straightness of your drag inputs. Its perspective features include configurations for constructing both converging perspective and parallel perspective. Contrary to common misconception, it is not just for using a stylus (which I very seldom use). On desktops or laptops, it doesn't know or care what you are using for a pointing device. (I can't speak to the matter of finger gestures on cell phones because I quit finger painting before kindergarten. So LNP is not something that competes with Affinity, it just serves as a drawing enhancement for it or whatever graphics program(s) you are using. I think you can download it as a demo to try it out in whatever program(s) you have in mind. JET

While I'd wholeheartedly agree with the practical usefulness of a vector-based halftone feature, Illustrator's is not a "true" halftone effect. In a true halftone, the black round dots do not simply become larger as they transition across the 50% threshold and then start to overlap each other. That results in 4-point convex "star" shapes beyond the 50% level, which are not round at all. In a true halftone, dots in both the highlight and shadow areas are round. As the round black dots approach the midtones, they begin to change shape and merge into what is sometimes nowaydays called "meta balls," so that as they continue beyond the 50% value, they transition into white round holes in a black "background." Since its early years, Aldus FreeHand provided halftone fills at the individual object level. These were actually based on true PostScript halftoning. Back in those days, they did not actually render to the screen in FreeHand's interface; to conserve resources, they displayed on screen as a pattern of "PS" letters. But they provided control over frequency, shape, and angle and printed as true resolution-independent halftones on a PostScript printer or imagesetter. They were immensely practical not just for special effects, but for low-res repro methods like screen printing or flexography. Despite its being a full-blown PostScript interpreter, Adobe Illustrator has never provided that kind of halftone control at the object level; only at the whole document level. FreeHand even had a feature in which you could code your own PostScript for other PostScript fills, not just halftones. Olav Martin Kvern demonstrated examples of that in his excellent Real World FreeHand book. Nowadays, faux halftone effects (which merely scale the "dots") can use any piece of artwork as the "dots." I devised some Javascripts for Illustrator that let me use any kind of little shape ("atoms," a logo, even Lens Flare objects) stored as a Symbol as the "dots." As always, we need to set our sights higher than the current implementation of some feature in Adobe Illustrator. JET

The kind of "vanishing point" converging perspective va2m is describing is entirely based on 2D construction. And it's nothing new. Macromedia FreeHand implemented a grid system for it way before it was copy-catted into Adobe Illustrator (after Adobe's acquisition of Macromedia). But I'd suspect it would be cleaner (both from the programming perspective and for the user interface) to implement it separately from the parallel perspective grids feature still under development in Affinity. JET

Mithferion, That quote sounds to me more like it's all about third-party commercial plug-ins, not about an end-user scripting implementation. I don't get excited about plug-ins. I learned early-on in the 80s to avoid dependency upon third-party plug-ins marketed toward users like the plague (as opposed to those aimed at things like production; pagination tools, drivers for NC devices, etc). Illustrator is the case-in-point. AI users spend a lot of money and time on third-party plug-ins just to add "missing" functionality, like dimension tools, or halftone effects, or better path manipulations. Such plug-ins are typically disproportionately expensive; often costing half-again the cost of the host program, or more. They chronically (and understandably) fall out of sync with the current version of the host program, sometimes lagging behind version changes by months. That is likely to worsen as most of the old-world software vendors have moved toward annual version changes (providing less and less in the way of substantive improvement per version) in attempts to smooth revenue flow. User plug-ins are seldom as smoothly integrated as would be native features. CADTools, for example, much as many like it, practically constitutes a whole other interface when its active. That's not functional elegance. To the user, third-party plug-ins are additional licenses and version updates to maintain. Their creators are usually comparatively small firms, which come and go. Moreover, third-party feature add-ons from all these varied sources are written to interface with the host program, but are effectively oblivious to each other. So adding a collection of plug-ins to a drawing program's interface tends toward grab-bag clutter and sometimes even redundancy. For example, suppose instead of waiting for Affinity to gain its arrowheads feature, we bought a popular plug-in called Pointers4Affinity from a company called StartupA. Instead of waiting for Affinity to gain a dimensioning feature, we buy a plug-in called Rulers4Affinity from a company called StartupB. What's the likelihood of being able to use our arrowheads in conjunction with our dimensions? That's why Illustrator's 3D Effect resides in its own modal dialog. It's just a plug-in based on a very limited functional subset of the defunct Adobe Dimensions application. Apart from its ability to import a Symbol from the current document's Symbols library as mapping art, it is essentially separate from the rest of the program. Each instance of it on the page is conceptually a "separate document" of that plug-in. It can, for example, turn a circle into a torus (by revolving the circle) OR it can turn a circle into a cylinder (by extruding the circle). But it can't make that torus orbit that cylinder within the same model space. In short, I consider it potentially self-defeating folly for creatives (freelance illustrator and designers) to allow themselves to become habituated to (i.e., make their businesses mission-critically dependent upon) such add-ons. To my mind, the "plug-in architecture" concept, loudly marketed to end-users as the "next big thing" in the 90s, has been largely a failure. A well-done scripting implementation is another thing entirely. It empowers the user to autonomously automate his repetitive routines far more powerfully than with just a macro feature (like Adobe's Actions) that merely records a sequence of (some of) the commands available in the standard UI. But moreover, as the user gets his feet wet, he finds he can essentially create his own vertical-need "features" that do exactly what he needs, by using variables, calculations, and conditional logic while accessing the actual objects, methods, and properties of the elements that lay beneath the standard user interface. Scripting is not for everyone, because it assumes at least beginner level understanding of the language used. But those languages are openly, widely, and freely used standards accessible to any interested user. JavaScript, Python, VBA, AppleScript, etc. By "well-implemented" I mean: A thorough, well-organized, and reliably updated documentation of the program-specific object model (not of the scripting language itself; that's up to the user to obtain elsewhere). Inclusion in that object model access to at least the basic objects for UI alerts, modal windows, and non-modal palettes, so that the scripter can cleanly present the necessary script-specific user options when the script is run. Clear, simple, and practical examples of using each object. Adobe has done a pretty good job of this; arguably too good by including not just Javascript, but also platform-specific languages (VBA and AppleScript), each of which requires its own documentation. Instead of platform-specific scripting languages, I'd frankly rather see a native program-specific scripting model like in FileMaker Pro. That has a full user-interface, excellent documentation, and being native, empowers the same script to work on any platform on which FileMaker runs, including FileMaker Server. Inkscape, on the other hand, now sort of "favors" Python, but its documentation (being dependent upon volunteers) is weak and scattered. "Examples" in its case pretty much involves dissecting existing "Extensions" that are bundled with the program. That's not an easy path for scripting newcomers. Also, bear this in mind regarding the best language to support: Adobe apps are scriptable in Javascript, not Python. Many users, like me, have cut their graphics scripting teeth on Javascript. It would be a relatively short transition for us to Javascript for Affinity. That consideration is compounded by the potential importance of embedding scripts in PDFs. Acrobat is still unavoidable in my workflow, and you can do wonderful things with Javascripted PDFs. So if I had my heart's desire, Affinity would focus on developing an excellent (as described above) single-language (Javascript) solution to empower its users. That's cross-platform, open-source, full-featured, and has a long-established ubiquity in other environments, including the web. I would think Affinity has this huge potential advantage: Adobe has to provide and maintain separate and different scripting implementations for each of its products, because they were developed (or acquired) separately. As I understand it, having been developed concurrently from the ground up, the three Affinity apps have the same underlying object model and code base. So I welcome correction if I'm wrong, but I suspect one thorough implementation and set of documentation could enable the Affinity scripting user to learn a single object model for the whole suite. Trust me, that would be a much less intimidating learning curve than gaining proficiency in scripting Illustrator, Photoshop, and InDesign. JET

Personally, I'd prefer a Javascript-based scripting implementation (with a thoroughly-documented object model). But now is probably not the time, since the program's functionality is still very much a work-in-progress. JET

Another detail worth mentioning along these lines is a keyboard modifier that would control whether or not preexisting extended handles are respected when joining. Back when Illustrator couldn't join more than two paths at once (not that long ago), I hacked out a couple of Javascripts for that: JET

The "old model" is clinging to absurd prices for mediocre 2D graphics software as if the "desktop publishing revolution" of the mid-80s is still in bloom. It isn't rocket science anymore. That's another example of Serif's innovation with the Affinity line. JET

Egads! You mean you're a genuine flesh-and-blood heavy duty professional? I'm impressed. My roof, by the way, is paid for, free and clear, as was the previous one, as are my three motorcycles, the 40 acres of woods I ride them on, and both my sons' masters degrees; all by my 45 some-odd years of what I guess you would call full-time "amateur" (you're not a professional proof-reader, I hope) graphics work using everything from lettering quills to airbrushes to Mutoh track drafters to software ranging from FreeHand to Solidworks and most things in between. And yes, now also Affinity. JET

You mean the Corel that doesn't have a page layout program? JET