JET_Affinity

It is compared to FreeHand's Graphic Find & Replace, which appeared well before, and which helped drive demand for something like it in Adobe Illustrator—which still fell short, just like other features preceded by FreeHand. Illustrator is not the model to emulate. "Select Same" is very weak compared to selecting properties based on user-specified ranges of values (again, per FreeHand's GF&R). Give Serif time to raise the bar, folks. Get over the Illustrator addiction to mediocrity. JET

Such forum sections exists so that users can not only make suggestions, but also discuss the merits of suggestions. Otherwise, there would be no need for a forum; you would simply submit requests in a one-way "suggestion box." JET

FreeHand provided a pair of simple, elegant, Retract and Auto-Extend buttons in its excellent Inspector palette; one each for incoming and outgoing curve handles. You could, for example, select one or any number of nodes, and simply click the outgoing Retract button. The outgoing handles of all selected nodes would be retracted (i.e., made coincident with the node). This did not disturb the node type (Corner, Curve, or Connector). The Auto-Extend buttons would extend retracted handles by the common 1/3 distance to the adjacent node, without altering their directions, if the node is a Curve. JET

There is nothing new about that. In other words: Reason 1 is a manifestation of the common "if it's vector, it's good" myth; the misconception that something is gained in the sense of vector-based resolution independence by autotracing a bad bitmap. Reason 2 is why—ever since the early advent of Gerber vinyl cutters in the sign trade—there are so many signs produced which, when observed up close have very jagged cuts; essentially the same conceptual problem. In other words (no personal offense intended; as I said these are both very old and common practices) you are (at least partially) in the business of using bad practice to expedite processing of sub-standard originals. That's not what I want to use Affinity for, and that's not something I want Affinity to be developed for. There are already too many other offering for that. And I'm someone who "grew up" in the sign trade. I want to use Affinity for professional-quality commercial illustration and design, not for sub-standard vertical-market production workflow. There are already many alternatives for that. It's one of the reasons why Corel Draw became ubiquitous in the US sign trade compared to Illustrator, FreeHand, and Canvas. There is nothing onerous about using a separate auto-tracing program (if one must) as a switch-to utility for offset print prep. There is nothing onerous about using a dedicated separate utility in a "down and dirty," quick-turnaround production workflow in a sign shop. There are, in fact, advantages to it, just as it can be easily more productive, to use a separate, more powerful, dedicated vinyl cutting application than to use a drawing program plug-in. There is little new in autotracing. It's a "standalone" function that can easily be accomplished by switching to a dedicated utility. We don't need another "me, too" cheezy autotrace feature in every drawing or design program. That's why autotracing is not even on my wish-list for Affinity. JET

Actually, I do, in one regard: they demonstrated the elegantly textured things one can do with diffusion-dither bitmaps. (Remember some of the beautiful games that were simply HyperCard stacks with entirely 1-bit images?) It's a pity that so few current drawing programs provide 1-bit diffusion as a rasterization option. For just one example, it's a great way to add shading to technical drawings. Okay. Back on topic so I don't get kicked out: So everyone wants a vector envelope feature. Got it. JET

There is a blast from my past. Good old System 8.6 8.6? You youngsters! I remember using it as a Macintosh "desk accessory" on a 9" monochrome monitor. Canvas is still around, and I still maintain my license. CanvasGFX is now a separate company again, which I sense (and hope) will give it the more dedicated development attention it deserves. It's treatment of switching a given object between its "transformed" and "untransformed" dimensions (and keeping it there) is representative of just one of the functions I'd like to see better implemented in Affinity. As I recall, its Lens feature appeared before something similar in FreeHand, and is one of those broadly useful things most Illustrator devotees are blissfully oblivious to. Like the other two survivors of the "Big Four" vector drawing programs, it's still strapped into an old-world pricing model. But it's a very feature-rich program any innovative competitors in the segment would do well to note (proper user-defined custom drawing scales; live dimension tools,…). JET

But Mac only. So—to appropriate the claim cited by every forum visitor angrily demanding a specific timeline for any given specific pet feature—"it is of no use to me." Just as one could do with most any other vector-based program to which one is habituated. For example, those who are really convinced Adobe Illustrator's is the envelope distortion to beat all envelope distortions, can export their paths to Illustrator, warp them, copy them back to Affinity. One could do the same with Canvas, Draw, Inkscape…anything with a reasonable exchange format path for Bezier curves. All as a workaround, of course, until Affinity has its own (hopefully better, more elegant, more innovative) warp feature. Why bother? Because enduring occasional workarounds gives you the advantage of developing proficiency in other and newer programs, thereby reducing your mission-critical dependency upon a specific software brand and the trauma of making a cold turkey "switch" when the time comes. That's how one avoids—or at least minimizes—falling victim to every machination of a single vendor. No, that is not practical for every feature and function. One cannot, for example, work around Affinity's infernal overdone bounding-box fixation, because that is something you must deal with the whole time you are working in the program. But more "standalone" functions like distortion effects or (gag me) auto-tracing are quite amenable to a little back-and-forth between separate programs. Example: Remember the days when a separate utility program called Type Styler was the de facto "standard" for any kind of text warping, before the Big Four had such features? JET

No argument there. Merely dragging something from one artboard to another, or from an artboard to the pasteboard has no business altering the object stacking order. A page (artboard) in a freeform "page spreading" metaphor should not be a mere clipping path. It should simply be a region of the pasteboard. But many users go nuts when a drawing program won't visually "clip" bleeding objects to the page or bleed area. That has never been a problem to me. I commonly store things entirely off the artboard(s), and when designing for bleeds, I manually trim bleeding objects midway between the trim and bleed area. This and several similar discussions remind me of the firestorm Corel started when they implemented page-specific Layers. JET

Stroke width settings are essentially "live effects." For any kind of NC fabrication, using stroke widths to create the appearance of offset paths does not provide actual separate paths for the NC machine to follow. Path blends and offset paths are so commonly used functions that I'm sure they are planned, and as I recall have been acknowledged by the Devs as being in the plans. Some kind of "virtual segment" detection or "path builder" tool is also pretty much standard fare these days, so I doubt that the Devs are unaware of the need. But whenever wondering why any obvious feature is not here yet, it's prudent to consider that individual features don't (or at least shouldn't) exist in their own separated vacuums. They are dependent upon each other. They often build upon each others' base functionality. For example, it has already been acknowledged that the outline path function is problematic. That seems clearly related to similar functions like offsetting paths. And we've already been told that that problem is being worked on. No offense intended to you personally, Chiefmonkey. I'm just making a general comment here. But this is why it's rather silly to expect a development team to provide any kind of set-in-stone, "hold-our-feet-to-the-fire" specific sequence and calendar schedule for their development work. Development is just that: development. It's largely a process of working things out as you go. Especially if you are developing anything actually innovative, be it software or a motorcycle, there is no precisely detailed, planned-out sequence of specific calendar days for each step of the project. There is just a general plan and direction in which allowances have to be made for whatever is encountered. That's what R&D departments do in any industry. That's how innovative things happen. The Affinity team has been refreshingly open with its customer base since its beginning. I wouldn't be surprised if that openness doesn't start lessening in the face of the constant barrage of customers who somehow seem to think that we have any kind of right to demand that a company provides us some kind of fixed outlined/sequenced/scheduled plan for how it develop its products. We pay $50 for a copy of a graphics program. That doesn't make us CEO. JET

Generally, settings for any raster-based live effect should be provided at the object level, not at the document level. JET

At least as of version CS6, Adobe Illustrator has no separate Pattern Panel. (I can't speak to rental-only versions, because I don't and won't rent software.) Patterns are stored in the Swatches palette, along with colors, tints, and grads. That panel has an option by which to filter Swatches by type, but there is no separate Pattern Panel other than the Pattern Options panel, in which you define parameters for a given Pattern. But it is not a list organizer of the Patterns in the document. JET

Amen. Illustrator's historic nemesis, FreeHand, originally had a single page residing in a limited size pasteboard, much like Illustrator. Macromedia gave FreeHand multiple pages long before Illustrator ever acquired multiple "artboards". In the arguments that ensued throughout the years between, during which Illustrator devotees insisted that giving Illustrator the ability to have a "page 2" would constitute the end of all that is holy, I explained the advantage with the following: A conventional-wisdom page-layout program has a page-flipping metaphor. All same-size pages stacked like a book. FreeHand, though, had a sheet-spreading metaphor, entirely different from conventional wisdom. It was more like gathering up all the various documents pertaining to a project, spreading them out on the office floor or conference room table, and freely arranging them. That's exactly how I use "artboards" in a drawing program. In a sign project, for example, I may have the customer's tabloid-size concept draft in the lower left, a row of three or four full-scale working drawings for the construction above it, and six full-scale sheets of various lengths on each of which all the vinyl cuts for a specific vinyl color are nested to save materials. Those are the sheets that are exported to the cutter. For an identity package project, I can have all the different press-sheets for the letterhead, business cards, note pads, etc., etc., each ganged appropriately for the specific press-runs. FreeHand didn't need any kind of special screen for handling its pages. You just zoomed out, used the Page tool to select pages and drag them about. They abided by the very same alignment, distribution, spacing, and guide or grid snapping as any other objects. And as of CS6, Illustrator's treatment is still hugely more tedious, cumbersome, and frustrating by comparison. Of course, those were also the days before someone got the bright-eyed idea to make a LAYERS palette into what should be called an OBJECT STACK palette, by insisting on listing every freaking object in it. I still despise that. It makes me scream "STOP HELPING ME" at all of today's inelegant drawing programs.

I'm on Windows nowadays, but I "grew up" on Macs. I don't consider it a platform thing. It's an intuitive organization and drill-down thing. That said, though, I do generally find it annoying whenever the interface for a desktop application is designed as if I'm assumed to be working with my thumbs on a cell phone. While driving. JET

Agree in general. Frankly, the help documentation could be better, too. JET

What in Sam Hill is a "universal layer" in Adobe apps? JET

Sorry, but I don't follow your seeming elevation of design over illustration. Realistic or technical commercial Illustration is a far more exacting discipline, requiring precise detail editing at the level of precisely shaped freeform paths; not just upper level constructs with automatic parameters. Gradients are entirely different constructs from object blends. Gradients are "canned" algorithmic rendering commands. In terms of commercial print reproduction, they are specific PostScript objects understood by the printing engine. They actually vary according to the resolution of the imaging device. Path blends are means by which to automate creation of a series of separate objects expressly defined by the illustrator or designer. You can't do the kinds of blends needed for realistic illustration with a canned grad command. You can do it with gradient meshes, but that is usually far more tedious and less predictable. In serious illustration work, one often creates blends between gradient fills in order to render such things as shading and reflection. Path blends interpolate node-to-corresponding-node in the order of path direction. This gives illustrators the necessary control over shaping the shading results for everything from convincing metallic reflections and transparent plastic to human flesh. Well, when I think of vector-based "programmer art", I think in terms of ECMI-based FlashScript, another important product line which was basically wrecked under Adobe's handling, setting a whole powerful creative medium back by decades. On the other hand, I have yet to see a better or more thoroughly-documented application-specific user scripting implementation in a suite of 2D vector-based illustration and design programs than what Adobe branded as ExtendScript. That's another whole world of potential for using graphics software as something more than a mere interface, the advancement of which has been hamstrung by Adobe's abusive marketing. But all that's getting far off-topic from an at least next-step-more-innovative blend feature. Again, I don't get your "design over illustration" fixation. The "big four" historic competitors since the early days of the PostScript "desktop publishing revolution" were FreeHand, Illustrator, Canvas, and Draw; all intended as the vector graphics (illustration first; design second) leg of the raster/vector/assembly three-legged publishing platform. In that model, the assembly program (be it print or web-centric) has always been regarded by conventional-wisdom as the "design" environment. In fact, it still remains a frequent battle to make many freelance document designers understand that most of the projects they handle in a given year are better suited for completion in the drawing program than in the repetitive-layout-focused feature set of the page-assembly program. In a nutshell, the differences between the still more fleshed-out 2D Bezier drawing programs boils down to the user interface, of which I consider Illustrator's worst-of-class. Fireworks drawing model was sort of "spun off" from that of Flash (which came from Macromedia's acquisition of upstart SmartSketch) in order to serve as (primarily) a web-centric design tool. But the illustration power of Flash is not its drawing interface. It is programmed interactive animation of not just buttons and such for web effects, but of programmed illustrations themselves; things like interactive simulators of mechanical systems. For example, I replicated the actual programming logic of a bus's multiplex diagnostic system as an interactive training solution for mechanics. A technical illustrator could branch into that kind of stuff with commercial-quality results using Flash far more easily than via raw JavaScript and SVG, because it is a full-blown development environment complete with its own graphics layer and scripting model (FlashScript). Again, to a serious illustrator, path blends are not merely for canned effects. They are a means for efficiently creating very deliberate node-by-node control over shading to render realistic surfaces, objects, shadows, reflections, etc. Blends are essential to realistic 2D Bezier-based illustration. I have to disagree there, too. It's "getting there," but there remains work to be done in that regard. FreeHand was not perfect, but its Bezier handling interface has yet to be matched in terms of powerful elegance. While you say you consider Xara "better [than Illustrator] for general design", its Bezier path handling is sub-standard, basically limited to the "click-click-bend" method, which, while useful for certain reasons, is inefficient and tedious otherwise. So yeah, Affinity's Bezier editing is already vastly better than that; but that's not really saying much. I have little to no use for a stylus as a pointing device. I don't even have one connected to my primary workstation. And I have no interest at all for "finger painting" on a tablet. Perhaps that's where we miscommunicate. Maybe when you say "illustration" you're just thinking of the cartoony styles of illustration in which people try to mimic so-called "natural media" by swiping freehand with a stylus, trying to mimic painting in a vector-based drawing program. To my mind, that is actually antithetical to the intent and purpose of vector-based illustration. JET

Path blends have been a basic feature of Bezier drawing programs since the very early days. So I'm sure it will be added to Affinity. Blends are one of the primary ways to achieve accurately controlled shading in vector-based illustrations. But once again; those only familiar with Illustrator need to understand that program is very often not the model to which to aspire. Illustrator's basic blend function has chronic problems which corresponding features in other programs don't; especially when it comes to blends on a spine path. For one example, in Illustrator, the spacing of the interpolated objects is always affected by the curvature of the spine path. In other programs, the spacing is uniform along the length of the spine path, regardless of its shape. Both are useful, but the latter is more commonly needed than the former. In Illustrator, to achieve what looks like uniform spacing requires the cumbersome workaround of adding a ridiculous number of nodes to the spine path. That, of course, negates much of the purpose of blends along a spine: the ability to adjust the shape of the spine while the blend is attached. Both spacing methods should be provided and controlled by a an object-level setting (not application- or document-level preference). And a setting for progressive spacing should provide its own adjustment handles. That would be far more useful than just adjusting the spacing by moving the node curve handles of the spine. Like many other things, though, a blend feature should be as thoroughly integrated with other features as possible. For example, to give credit where credit is due, Illustrator's blend feature works on stored Symbols used as key objects, not just single paths or groups of paths. That is both powerful and versatile. Moreover, it also works with the "higher construct" of instances of its 3D Effect. That is very powerful, enabling construction of things that would be very difficult to achieve otherwise. In other words, a well-integrated blend feature should certainly be expected to blend between instances of higher constructs of the same type. For example, one would never logically expect a blend feature to blend between, say, a vector-based path and a raster image. That's functional nonsense. Likewise, one shouldn't expect it to "blend" a live Star object into a live Cylinder object, because those parametric objects have different setting attributes. But it should be expected to blend between multiple Star objects which have their shape adjustment parameters set differently. And while I'm no "insider," it just makes legitimate sense to me that "well-done integration" may very well be part of the reason why a blend feature has not been added yet. There are many object-based features which are still very much works-in-progress, and I, for one am happy that everything existing is not yet "set in stone." My favorite example of something already existing that I very strongly hope will undergo dramatic change is Arrowheads. It seems to have been rushed out the door in response to very loud and impatient user demand. I hoped for —and still hold out hope for—something much more innovative and powerful. JET

No, they're merely skewed vertically. That's one of the "old standard" pathType variations. FreeHand and some other programs had it long before Illustrator, which as I recall didn't gain it until around version 8 or 10. It's one of the most useful, but just like the normal rotating of the characters' baselines along the path, the horizonal edges of the glyphs remain straight. So they work best when the type size is small relative to the tightness of the curve. Both rotating and skewing characters along the path are useful for things like the ubiquitous text surrounding a circular or oval emblem. Rotating is still the straightforward default for things like curve road names along the roads on a map. Skew was once more commonly used for "Superman" sweep treatments, and was once the only quick way to suggest text wrapping around a cylinder. I agree they are still useful and should be included in Affinity Designer, as they are in most programs. But nowadays, Skew is rather passé since the advent of live envelope distortions, which do cause the horizontals of the glyphs to match the curve of the path, and which can also accomplish progressive lengthwise scaling. That is far more convincing when used to "map" text around a cylinder, etc. And some kind of envelope/warp feature has long been acknowledged as something that will eventually be added to Affinity. I've often wondered, however if it would be possible to devise more "text intelligent" envelope distortions. You see bad examples of enveloped text every day when users try to emulate retro sign painting styles or treatments common in things like team sports graphics, while assuming every such thing is just a matter of figuring out which button to click. Much of the ugliness boils down to the fact that widening text by scaling widens the verticals of the glyphs, but not the horizontals. That wrecks the design of the type, turning what was designed as a "single stroke" typeface into a "thick and thin" typeface. So could text-aware enveloping improve automation of such things, at least for fairly "normal" typefaces? JET

People love to complain about how long it is taking for their favorite "must have" feature to be implemented. Yet the above was requested of those who want this feature over 4 years ago, and I still see no examples posted by those who consider auto-tracing so essential. Please show some real-world examples demonstrating why you consider auto-tracing essential. Please post screenshots of both the "before" (the original raster) and "after" (auto-trace results), not merely at the same size, but zoomed in sufficiently to make the actual functional improvement evident. And show the results before any manual post-trace path editing. The most often claimed "need" for auto-tracing is ostensibly to gain the technical advantages inherent to vector-based artwork: resolution independent scaling. So that improvement needs to be demonstrated in the examples. If the net result merely swaps one kind of ugly jaggedness (raster pixelation) for another (jagged or inaccurate vector paths), there is no functional gain. Remember: Except for uses such as NC cutting fabrication, everything gets rasterized in its final reproduction anyway, whether printed on paper or viewed on a monitor. JET

Selection in general still needs a lot of work. It seems that the Node Transform tool itself was added in reaction to shortcomings of the Node Tool. This application now has three primary selection tools, whereas most programs like it have the Adobe-esque two, which FreeHand's functionality always surpassed with but one. Too much "hard switching" between tools (as opposed to using momentary modifiers). I do appreciate the Node Transform Tool's novel ability to uniformly scale as it rotates (which can be overridden by a momentary modifier keypress) in order to snap to existing artwork. But I don't know why the functionality of the Node Transform tool couldn't or shouldn't be integrated with the Node Tool. As AK21 mentioned, the Node Transform Tool cannot perform its transforms on a sub-selection of nodes. Much of it seems to be in strained effort to doggedly cling to what I consider the kind of over-the-top obtrusive insistence on bounding box handles for transformations. I know this is part and parcel of Affinity Designer's ability to remember each path's original orientation, which is a valuable capability that many programs (including Illustrator) do not have. But this has long been better implemented in Deneba Canvas (one of the still-surviving venerable Big Four competitors from the 80s). Many Affinity users have complained about the inability to permanently reset the bounding box to the current orientation (which can be done in Illustrator). This is a real stumbling block when working in Affinity. But in Canvas, you can switch between a selection's "transformed" and "untransformed" values at will, with the corresponding bounding box appearing. A small step in the right direction which would yield disproportionally large improvement would be simply for all nodes of the selected path to not automatically become unselected when merely switching from the Selection Tool to the Node tool. Another behavior that should be standard fare is that deleting an open path's endnode should result in the adjacent node's being selected. It's a very useful thing to be able to "back up" a path from the last-placed node just by tapping Delete. Also related to all this is the problem with drawing "lines" (single-segment straight paths) with the Pen's Line Mode. It's hard to think of anything more basic to drawing (even before drawing with software) than drawing a measured line. But with Affinity's Pen set to Line Mode, only dragging out a horizontal or vertical "line" will result in its "dimensions" corresponding to its length, because of that infernal insistence upon referencing everything to the obtrusive bounding boxes. Using the Pen in Line Mode, drag out a diagonal line, and all you'll get is its bounding box dimensions. One can put the bounding box dimensions to use, for example for calculations based on sine and cosine. But it is far more commonly useful to intuitively draw the path at its desired angle in the first place, and immediately know its actual length. And angle. So I hope none of this is taken as derailing a specific request. I'm just saying that all these things are closely related to devising a truly elegant path selection and manipulation interface, and I suspect the devs still consider it a work-in-progress. For example, I seem to recall a mention somewhere of enabling the Node Transform tool to manipulate sub-selections something still to be worked on. JET

Something (yeah, there's always something) that is now needed to work better with the new capability: I have a path selected by the black pointer (Selection Tool). This, of course, displays the infernal bounding box, which only gets in the way when I want to drag a path by one of its nodes. I switch to the white pointer (Node Tool), because I want to drag the whole path by one of its nodes, in order to accurately snap that node to and edge or node of another pre-existing path. But upon merely switching to the white pointer, all the nodes of the wholly selected path become unselected. So I now have to marquee select the whole path all over again with the white pointer, in order to take advantage of the newly added (and much needed) snapping capability. I see no justification for this. Merely switching to a different tool should not change the selection state of what is already selected. When a path is already selected with the black pointer, switching to the Node Tool should, of course, get rid of the all too-assertive bounding box, but should otherwise leave what is already selected (the whole path) alone. In other words, merely switching to the Node Tool should leave all the path's nodes selected, not deselect all the nodes. I understand the counter-argument which someone may raise: The assumed purpose of switching to the Node Tool is to manipulate a subset of the path's nodes. But, first, the program has no business making that assumption, especially given the now better snapping behavior. Second, the existing behavior (automatically deselecting all the nodes) causes me to have to make a marquee or individual nodes selection regardless of whether I want to move all the nodes or just a subset of them. If the change I'm asking for were made, I would only have to make a marquee selection when I do want to move only a subset of nodes. And in that situation, I would, of course, have to select the specific nodes I want to address anyway. So having them all always automatically deselected is really no advantage at all. Some may anticipate what my next argument will be: Now that the Node Tool and the Node Transform Tool have the needed ability to snap to pre-existing nodes and edges, it raises the obvious question: Why the need for both tools? In other words, why can't the Node Tool also be able to do the rotations, skews, and scales that the Node Transform Tool can do? In other other words, why can't I just work with the Node Tool when manipulating paths, and only switch to the black pointer when I do want to manipulate handles of a bounding box, as I can do in other programs? JET

Thanks for this! These are the things that "keep me up at night." JET

Adobe is a company. If you're talking about Photoshop (the program with the Constrain option you favor when bending segments), yes, I've used it pretty extensively since version 1 through version CS6 (I don't rent graphics software). And yes, if it were possible to momentarily toggle the behavior by means of a keyboard modifier while in the act of a single bend move, I would use it. Something I've always disliked about bending paths in both Photoshop and Illustrator is that the very same moves with the inelegantly named Direct Selection Tool doesn't bend straight segments; it moves them. That, of course means it also moves the ostensibly unselected Anchor Points. That's just one example of how Illustrator's inconsistent interface violates the very concept of something being selected. For most of its history, FreeHand had but one selection tool. It was both more intuitive and more powerful than Illustrator's is, even today, and the context of bending paths is a good example. You could bend curved segments and straight segments, with a completely consistent interface. Olav Martin Kvern, the quintessential FreeHand guru long before working for Adobe, coined the term "Benodmatic" as a distinct path drawing methodology. A beginner struggling to get their head around drawing with Bezier curves could be taught to first just click, click, click, placing only Anchor Points at intuitively appropriate places, and then go back and smoothly bend the straight segments that needed to be curves. I used that method countless times to get beginners over that initial panic hump of using the Pen tool. But it wasn't just for beginners. I often used it to impart a pleasing stylistic consistency and economy of nodes in artwork that needed to be optimally built (for example, in glyphs of symbol and clipart fonts). You could also power-duplicate path changes in path shapes using FreeHand's single selection tool. For example, you could AltDrag a Point, thereby duplicating the whole path but with that change in shape. Thereafter, invoking the duplicate command re-iterated the whole path and the shape change. You can't do that in Illustrator, because Transform Again duplicates only the bent segment. So no, I don't think Adobe products are the ones to emulate even in things as basic as path manipulation and selection. JET

But not really surprising, given that many of Adobe's graphics apps (including Photoshop) were acquired. One of the advantages of the Affinity platform is that all three of its "legs" (raster, vector, assembly) seem to have been conceived and are being developed together as a cohesive platform, not as a mere marketing bundle of separately-developed (or acquired) programs. The "integration" (something Adobe has always loved to banter about) is deeper than mere interface window dressing. Which is why I tend to "weep and moan" whenever I hear users demand conforming to the "mean ol' levee" of Adobe Illustrator, the interface of which is more twisted than the Mississippi. There are straighter (and more elegantly integrated) paths to the needed functionality, if we can just afford the dev team time to consider them, and offer our input (which the dev team seems refreshingly open to) with some appreciative civility. (Alluding to other threads, not this one.) JET

And it does in SVG, and therefore in Inkscape. But I'm not saying it should in Affinity Designer. Because unfortunately, Descartes's grave was desecrated by the graphics industry long ago. So everything's just a scattered mess anyway. Go try and tell your trig or calc professor (or your HP graphing calculator) that the Y axis origin should be at the top of something called a "page," and therefore vertical values should increase downward. But that's what has happened to vector-based graphics programs; something that is by definition math-coordinate driven. The root problem is, Affinity Designer should be an illustration program first and foremost, and a proper Cartesian coordinate system is what should be used in all such programs. But that's not Serif's fault. That ship sailed with FreeHand. (It was actually merely run aground by if-you-can't-beat-'em-just-buy-and-discontinue-'em Adobe.) And somewhere around that time, Adobe also flipped the Y axis in Illustrator to assuage uninformed demand from users who don't know Descartes from Adam, and it and everything that imitates it drives me freakin' nuts. Related: Even before inverting Y, Illustrator's single Artboard was always inexplicably created at the center of the program's limited pasteboard. And it still is, and that's one reason why its page handling was (and still is) far more cumbersome than it should be. FreeHand's initial default page was properly created at the lower left; in other words, at the origin of its proper Cartesian coordinate system. So added pages proceeded sensibly without, in effect, wanting to waste half or three-quarters of its limited pasteboard. A vector based drawing program (or CAD program) should, by default, have its X ruler at the bottom of the screen, not at the top, and positive Y values should increase upward. But if Serif had done that, there would be a firestorm from users who now think Y values increase downward, just because they do in a web page—and Adobe Illustrator. It's too late for this issue. But please, for everything else going forward, let's just forget Adobe Illustrator so that vector-based drawing can actually move forward. For example: If vector-based drawing ever does get out of its Adobe-esque doily drawing doldrums, one thing we might find of interest is the feature that has long existed in Canvas for directly plotting curves by formulae and function. Guess what kind of coordinate system that feature uses. JET