JET_Affinity

It's a reasonable request. (But belongs in the feature request sub-forum.) Both FreeHand (long before Illustrator even had 'Artboards') and Illustrator provide a field for specifying count of pages / artboards in their New Document dialogs. Illustrator's provides options for count of rows and columns. I use it frequently, as when creating illustrated step-by-step procedures. Yeah, one can pre-build a template. But that's also true of many other things one doesn't always want to have to build a separate template for. It's also handy in that uniform spacing between the rows and columns is automated. (In FreeHand, you can select pages with its Pages tool, and align/distribute them with the same commands as used for ordinary objects. In Illustrator, you can't.) JET

There are other very vocal threads about warping, enveloping, etc., etc. I'm sure it will be added. But as with many things, the devil is in the details of how it's actually implemented. Conventional-wisdom envelope warping is still not the same thing as the old 'standard' ways of orienting live text on a curve (especially the all-important vertical skew). It's way past time for some well-thought-out innovation in that area, so it's my hope that Affinity intends to pursue that. I share your pain, though. It's a tedious thing to try to explain many of the elegant things about FreeHand to users who have never used it, let alone having ever been proficient enough with it to truly understand its many understated but powerful advantages. I fear much of the elegance of FreeHand is lost forever. FreeHand's Inspector interface, for example, is far superior to the now ubiquitous "me, too" treatments of tool/option bars that keep shifting around. Those who have never lived with FreeHand's Inspector palette really don't know what they're missing. JET

Quite the contrary: Defining a bunch of willy-nilly non-'global' color swatches in the same mixed bag with a bunch of 'global' swatches is bad practice that leads to cluttered confusion (and potential production errors). In Altsys FreeHand, there was no 'global' versus 'non-global' distinction in swatches. All user-defined colors automatically became 'global' as soon as they were dragged from the Color Mixer palette to Swatches palette. That's how it should be in every such program. That's the intuitive meaning of defining a color. Editing the definition of a color should of course update wherever that color is already used. That's the intuitive meaning of redefining a color. If you want to add another color to the document's palette, that's what you do: add another swatch to the palette. I never heard a FreeHand user complain about any of that. It's straightforward, intuitive, consistent, and reliable. You could redefine an existing swatch at any time and be confident you wouldn't miss any elements throughout an elaborate illustration that needed to be updated because the swatch was applied to it 'before setting the swatch to global.' Any time you wanted to use a different color; that's what you did: defined a different swatch. The interface was clear: The Color Mixer was where you mixed colors. The Colors Palette is where you stored the colors you mixed. This is just one example of how FreeHand's interface regarding colors was superior to Illustrator's. FreeHand could properly handle spot colors in both gradient fills and in object blends, without their being converted to process. JET

The concept of so-called 'artboards' is not impractical. Far from it. (How best to implement it, of course, is a matter of discussion.) Think of it like this: The general interface metaphor of pages in a page-layout program is that of a bound book: flipping a stack of same-size pages in a fixed sequence, viewing them as 2-page spreads. The general interface metaphor of artboards in a vector-based illustration and design program is that of freely spreading and freely arranging related but individual sheets of a project—which may be of different sizes and orientations—on the conference table. I don't know about your work, but mine (for the past 3.5 decades) has overwhelmingly more often corresponded to the latter than the former. I dare say that is also true of the vast majority of whole-document designers; vastly more single-sheet brochures, fliers, placement ads, trade show displays, identity documents, signage, etc., etc. than high-page-count bookish documents with repetitive layouts. Truth is, for the majority of graphics-intensive documents, it is more efficient to build it entirely in a drawing program than in a conventional-wisdom page-layout application. JET

It's generically referred to as "inline graphics" (having a graphic flow in line with live text). It's nothing new. Vector based drawing programs, page layout programs, and even word processors have provided for inline graphics since way back. Since vector-based drawing programs also commonly provide for "path text" (flowing text along a path), those which provide for inline graphics let you combine the two, as demonstrated. This is also nothing new. Other vector drawing programs have had this ability for decades, the notable exception being Adobe Illustrator. (As of CS6. I don't rent software. But I suspect it's still a long-requested and never yet provided feature.) However, inline graphics is still not the same thing as distributing graphics along a path. Most vector drawing programs can distribute graphics along a path by means of object blends. But implementations differ. For example, in Illustrator, the spacing of the instances along the path is affected by the curve handles. So along curvy freeform paths, the spacing is not what one would call uniform. The workaround is to add an inordinate number of nodes to the spine path, which of course effectively wrecks the ability to smoothly edit the spine path's shape. Illustrator users have also long suffered from its object blends' inability to properly position the first and last instances on closed spine paths. Illustrator's historic nemesis, FreeHand, uniformly spaced its blend object instances along the path, and had no problem with correctly handling closed spine paths. That is usually preferred. But both spacing methods—being either affected or unaffected by curve handles— are useful, depending on the specific situation. Also since way back in the day, Deneba Canvas could not only create object path blends but could also automatically simply position and uniformly space elements of a group along a path. So you could easily have an array of completely different and independent objects follow along any path shape, uniformly spaced. It was much later that so-called vector 'brush' features came along, and some of the problems with Illustrator's sub-par blend handling can now be worked around with Scatter Brushes. But those come with their own frustrating caveats. Affinity's provision for Inline graphics is much to be applauded. All vector drawing programs should provide that. But again, that's not really the same thing as objects along a path. When Affinity does address the need for true vector brushes and path blends, I hope it takes all of the above and more into consideration toward creating an innovative approach that covers all the above. I still see no reason why that couldn't be done with a new approach toward pathEnds and pathStrokes that would be more powerful, more intuitive, more concise; in other words, elegant in both capability and interface. I'm convinced such a treatment could surpass the conventional wisdom of separate arrowheads and separate kinds of brushes, and should integrate closely with symbols. JET

Xara Designer Pro is a nice program in a lot of ways, but it is crippled for serious illustration by its sub-standard primary Bezier path drawing tool. It's the main reason I seldom use it, and haven't updated it since just before the '365' version that began its also flirting with rental-based licensing. Xara documentation pushes its Node Tool as its primary path drawing tool, and treats its Pen Tool as a 'me, too' afterthought; a necessary evil. Both are sub-standard. I was complaining about this since first using it; even demonstrating the difference in a "comparison race" with a proficient Xara user on its Talk Graphics forum. The Node Tool only works in what I call the "click, click, bend" method. By that, I mean you click repeatedly to place a series of nodes, creating straight segments; then you go back, mousedown and drag somewhere in the middle of segments (thereby extracting the retracted curve handles) to bend them. Xara seems to consider this some kind of special, preferred, and advantageous 'breakthrough' in Bezier interface design. It's not. It's the same thing that was referred to as "bendomatic" by author Olav Martin Kvern in reference to one way you could use the Pen Tool back in the days of Aldus FreeHand. Even back then, most FreeHand users thought of that technique as a simplified method for beginners intimidated by the Pen tool. And it was, in fact, useful for introducing newcomers to vector drawing. I employed it for that purpose often. But I also used it to impart a certain kind of stylistic uniformity, especially for small vector graphics, such as glyphs for dingbat or clip-art Type-1 fonts. So I'm not foo-fooing it. But continuously click-click-bending, doubleClicking, and visiting a set of node-type buttons is just too cumbersome and tedious for routine productive path drawing. It is simply not a suitable substitute for a fully implemented Pen Tool as is and has long been common fare in mainstream drawing programs (Affinity, Canvas, Draw, Freehand, Illustrator, Inkscape…) in which you use the primary Bezier drawing tool (usually called a Pen) in conjunction with mometary modifier keys, fluidly controling curve handles and node type as you proceed, node-by-node, in anticipation of the next segment shape, without breaking stride. The operative phrase in that is "fully implemented." As mentioned above, Xara does have a Pen Tool. But it also lacks the practically universal momentary shortcuts. JET

This was also asked by someone at Affinity 5 years ago: But I don't see any. Quite suitable alternatives have been mentioned repeatedly in these threads requesting yet another autotrace feature. JET

Um…that's what user forums are. Nonsense. The former in no way implies the latter. And the contrary is more often demonstrated in this forum than in any other software user forum in which I participate. But there's no need for the company's developers to answer each and every repetitive rant. And you said "either…", which implies an "or…", which you did not provide. So I will: ...or the Affinity team (i.e., the privately owned company) is following the development path (priorities and sequence) which makes most senses for its (not your; not my) product development, and has neither time for, nor interest in, listening to a bunch of repetitive, rude, insulting immature rants from self-proclaimed 'professionals' convinced that their personal pet peeve is always the one upon which the future of the graphics world pivots, and that everyone else is an amateurish dolt. JET

A professional can do professional work with a crayon. JET

Something I hope all would consider: The intents (and therefore requirements) of distorting type, as opposed to general artwork. I grew up working in sign shops, long before the advent of digital type. (I'm proud to say I can still twirl a lettering quill.) The trouble with automated pre-set envelope distortions as usually implemented is that they treat type the same way they treat any other vector paths, when usually it shouldn't be. I'm not talking about deliberate effects like the water-drop examples. I'm talking about the ubiquitous things like curving what is supposed to read like normal text around circular emblems, the ess-curved "flag" baselines, the 'hero' headlines, and especially the whole plethora of attempts to emulate retro signage styles. The result, more often than not, is really amateurish adulterations of good type. All those classic treatments of type are why software since the earliest days, long before vector envelope effects in every drawing program, have been separate features implemented as options for live type-on-path objects, especially the one called various names like "Vertical" or "Skew." The good thing about that very important treatment is that these things are maintained, as they should be: The proper "uprightness" of the glyphs The straightness of their vertical strokes The proportion of horizontal strokes to verticals The only bad thing is that the straight horizontals of the glyphs skew, but remain straight. Typical general-purpose envelope distortion features know nothing of this. That's why I'd like to see an envelope distortion that knows when it's dealing with type, not just random vector paths. Implementing it as a separate type-specific envelope feature wouldn't hurt my feelings a bit. JET

Adobe (and too many of its neophyte users) love to go on about the 'integration' of its applications. Assigning the same trendy graphics designer to rework the styling of windows and toolboxes is not functional integration. Nor is marketing word games. (Remember the 'PDF is now Illustrator's native format' hype?) How many know that InDesign can't really import an Illustrator file (as of CS6; I don't rent software)? It just imports the dumbed-down PDF version of the content (if there is any). Bear in mind that many 'Adobe' apps were acquired from other companies. To refocus on the topic; Illustrator's redundant warping (vector enveloping) features too much target instant gratification for pre-set shapes. This is largely due to one thing: They are initially created with their curve handles already extended. Much less flamboyant but far more elegant FreeHand envelopes provided for user's choice in that. As with everything else yet to appear in Affinity, I hope Illustrator is not the 'us, too' model. We need to get over Illustrator, so we can get beyond Illustrator. JET

Yes, I know it has one. Go back and read what I said. It's very lame compared to the status quo, lacking the near universal interface of mousing down and dragging to extract handles from nodes as you place them, and using momentary keyboard options to fluidly control node type and handle behaviors as you go, which is far more efficient and productive than the tedious process of click, click, clicking to place nodes and then going back to bend, bend, bend segments. James

I'm not frustrated with the pace. I'm frustrated with some of Affinity's truly fundamental directions; things like the dependency upon lame bounding box handles for routine transformations, and the 'a page is a layer is a clipping path' thing. Like you, I still use CS6. But not because of what Affinity lacks; simply because I paid for it as a perpetual license. That's what perpetual licenses are all about; not being held captive to every machination of the vendor. The moment Adobe announced its Captive Creative licensing crap, I did two things: Stopped buying Adobe software. Started deliberately letting my use of Adobe apps gradually wither on the vine. I can get my work done in any of several non-Adobe programs. A full set of features? You mean the program that still (as of the last version I bought, just prior to its "365" licensing) doesn't even have a decent Pen tool? Xara's click-click-bend path drawing method is its only method. Other programs can do that, too. In FreeHand, it was called "bendomatic". It's nice for some things. But most of the time, it's inefficient, cumbersome, and sub-par. In a Bezier-based vector drawing program, there's nothing more fundamental than a good pen tool. JET

This: Not this: It's not 'running away' to use multiple programs of the same genre. It's smart to be familiar with multiple programs. That's how you avoid becoming a Captive Creative to one particular vendor. Ever since the beginning of the 'desktop revolution' of the mid 80s, I've considered it a matter of simple professionalism (and professional self-preservation) to maintain at least working familiarity with as many of the mainstream softwares applicable to my work as I practically can. How can one claim to 'compare', let alone 'prefer' one software over another, if only really having experience with one? Before software, my primary graphics tools were airbrushes. I had (actually, still have) Pasches and Iwatas and a handful of other brands. I certainly had my favorites. The Pasche AB was my fine detail go-to; the Iwatas were my workhorses; the Badgers and other brands of various sizes for knock-it-out automotive, signage, etc. In the early wars between users of the 'big four' vector drawing programs, people got all emotional over this stuff largely because they were deathly afraid of a little learning curve in a different software. So it was defend Illustrator or FreeHand or Canvas or Draw as if you were fighting for Mother Russia or something. It persists to this day in (frankly mundane) 2D graphics. But in 3D modeling, video, CAD, etc., people routinely use a variety of programs, and consider it advantageous. JET

In the current context of roughening paths, other FreeHand users may recall that a few versions before its acquistion by Adobe, Macromedia added a simple "fractal" option that basically: divided straight segments into thirds reshaped the middle third (for example, making it into a peak) repeated that same alteration on the segments of that peak …and repeated that for a user-specified number of iterations. Something else to consider is, what are we really doing when using a "roughen" command? Usually, we're trying add an element of apparent "randomness" within the otherwise generally deliberate and pristine world of vector-based illustration. I recall a thread years ago in the Illustrator forum in which one of its developers who occasionally participated back then mentioned that the only true random function in Illustrator was that little checkbox in the Transform Each dialog. I use that quite often, and have always wondered why, in math-driven vector drawing programs of all things, the random() math function isn't leveraged throughout the feature set. I'd love for the developers to always have that as a "checklist" question in the back of their mind whenever designing a new drawing function: "How could this construct benefit by providing a random function?" Combine the two: Imagine being able to generate various shapes of repetitive "branching" with an appearance of natural randomness, but under control of a few sliders for parameters like frequency and decay. JET

Of course there's nothing wrong with comparing to other programs, and nothing wrong with mentioning Adobe Illustrator (by name; no need to 'encode' it). That's not the issue. The issue is that too many users effectively demand that something 'absolutely essential' (everyone's pet feature is the most 'absolutely essential deal-breaking omission that must be addressed right now, or else!') be implemented just like it is in Illustrator, under the assumption that just because Adobe dominates the market, Illustrator's treatment must be 'best'. It's often rather transparent that many of the most vehement demands come from people who seem to have little to no experience with anything else. Generally speaking, Illustrator's interface is hideous; cumbersome, scattered, confused, inconsistent, redundant. In a word, very inelegant. It's not the program to emulate. We need to get over Illustrator so we can, at long last, get beyond Illustrator. No. When one software company merely mimics another, that does not give us choice; we just get the same ol' same ol' conventional-wisdom approach and the 2D vector drawing segment continues to languish in its current functional mediocrity. When customers (I don't like being referred to as a consumer; I'm a producer) win, is when they demand better and an attentive provider listens. So sure; whenever we find ourselves missing something we depend upon, we should feel free to describe how it works in whatever program we're accustomed to for explanatory purposes. But we should put more effort into it than just that. Try thinking through what the feature really does, why it's important, and imagine how the desired functionality could be advanced rather than merely mimicked in "me, too" fashion. JET

And, I dare say, it still cannot even understand multiple math operators in an expression, e.g., "2*3+1" or "(2*3)+1". For even that kind of grade-school arithmetic, you still have to dink around in the modal dialog, making individual single-operator expressions, one at a time, committing each by clicking outside the field, then entering the next single-operator expression. JET

So you're saying you can enter "(1.5*3.25)+3" into a dimension field in Illustrator's Rectangle Tool's modal dialog box, or enter "3.5*sin(35.26)" into the vertical field of the Scale Tool's modal dialog, and have it evaluate correctly? JET

From a user's conceptual perspective, Layers and Pages are fundamentally and purposefully distinct. Proper layers provide a document level organizational mechanism based on the users' working purposes that is independent of pages. That's why they exist. Moving objects onto, off of, or between pages has no business changing their position in the object stacking order of the whole document. It's called a "Layers Palette" for a reason: From the beginning in the 80s, the Layers Palettes in object-based graphics programs did not even list objects. That unnecessary (and frankly, ill-conceived) notion came much later. The Layers Palette only listed Layers, because it was not just another method to merely "bracket" a range of objects on a particular page that are contiguous in the Z-stacking order. There are already other means by which to do that. That's what groups and nested groups do. (Any kind of group, including special construct groups like clipping paths, blends, symbols, etc.) Proper layers are not about that. Example A. Suppose I'm working on a document which consists of a set of nine drawings on pages (Sheets) of varying sizes. I have a group consisting of a few lines and text objects called a Title Block. Each Sheet (page) has its own inset border (different size/shape for each page). Each sheet has its own reference grid with its own X and Y legend. I put all that stuff on the same single document-spanning Layer called "Sheet Frames." I have another Layer named "Temp_Trace." Anytime I need to temporarily import a raster image (say a scan of a sketch) for tracing, I import it to the Temp-Trace layer. I create that Layer once. I toggle its visibility on or off with one click, regardless of what page I'm on. I can drag a sketch image on that Layer from page to page, without it jumping to somewhere else within the overall document's object stack. Example B. Another project consists of press-sheets for a product identity project. A 19" x 22" layout (page) contains a ganged-up set of labels of various sizes for several different sizes of jars. A letter-size layout contains a gang of business cards for six different employees. Another layout contains both sides of a 9" x 12" (trim) trifold product brochure arranged for work-and-turn printing (i.e., one set of press plates, minimized pre-press setup and finishing chores). I put trim marks, fold marks, color bars and other production references on all of those sheets and I want them all to reside on a single document-wide layer called "Printer Marks." Two of the sheets involve die cuts. I want all of those paths on a single document-wide layer called "Die Cuts." I put foil stamps, embosses, varnishes, and sometimes spot ink objects on document-level Layers. When printing or exporting, I can toggle on or off those auxiliary layers, as needed, document-wide. When finished with a temporary-purpose layer, I can delete it, document-wide. I can turn off "technical" layers across all pages in the document and then export all pages as approval comps. Example C. Another project consists of a set of 50 wiring schematics of various page-sizes for a vehicle. The set is to be delivered to plants in the US and Mexico. All the myriad circuit labels reside on two whole-document-spanning layers: English and Spanish. When the document is exported as a PDF, the Retain Document Layers option is on. A Javascript button is added to the PDF to allow the user to toggle the entire document between languages with a single click. All of those hypothetical but very real and common situations are entirely artwork-intensive projects. None are bookish, text-heavy documents involving high page count, repetitive page-to-page designs requiring master pages, tables of contents, indexes, etc. In other words, none require (nor is even appropriate for) a page-layout application. Document-level layers is just as important for illustration/design applications as it is for page-layout applications. "Container" (clipping path) treatment of pages is neither advantageous nor a suitable substitute for conventional document-wide page independent layers. Calling a page an "artboard" doesn't change that. Given that this ship has probably sailed, I know I and others are probably fighting a loosing battle here. But failure to provide proper document level layers is a serious competitive disadvantage. JET

As of CS6 it doesn't. (I can't speak to later version, because I don't rent software.) Simply try using more than one math operator (i.e., not just addition / subtraction or multiplication / division, but both) and parenthesis in an expression. That was always one of FreeHand's advantages over Illustrator. But Affinity goes even beyond that by supporting trig functions. Yes, useless. What good is a measuring tool that doesn't reliably abide by snaps? I don't use it either, because it's useless. Illustrator's Line Tool makes a better "measure tool," and that's what I use whenever I need a "measure tool". If one has the non-modal Transform Panel visible, as I always do, it's already open, always there in the same place, providing more info and transform options without switching tools, and always providing numeric feedback. JET

Matt, Unless I missed it, that video doesn't show an instance of an object being dragged entirely onto the pasteboard (not intersecting any Artboard). Does it disappear if you do that? Corrections welcome, but as best I've been able to discern, the confusing "universal layer" thing repeatedly mentioned in these threads is just a term coined by a user trying to communicate that in most graphics programs involving artboards (e.g., Illustrator) or pages (e.g., FreeHand) or even page spreads (e.g., InDesign), the artboard or page is effectively just treated as a rectangular region within its surrounding "pasteboard." (The near ubiquitous metaphor of page-layout being that of a physical paste-up table). So simply moving objects X or Y, whether intersecting pages or not, does not affect their position in the overall Z-order object stack of the document. Affinity Designer's interface makes it feel like an Artboard is just a glorified clipping path. One expects moving an object out of one clipping path into another to change its Z position, since clipping path contents are always a range of objects contiguous in the stacking order. But one does not expect that to occur merely by moving an object onto, off of, or between pages. If I'm on target, I agree with that complaint. Affinity's behavior is very different from expected in this regard, and I see no advantage to it (but am willing to listen if there is one). JET

That's also why I flatly refuse to rent business-critical graphics software, despite the "oh, well, it's the modern way" rationale of those who begrudgingly succumb to such marketing machinations. The InD problem is a case-in-point. As soon as Adobe announced its take-it-or-leave-it Captive Customers licensing, I stopped updating my theretofore faithfully-renewed Master Collection license and started deliberately letting my use of Adobe applications wither on the vine. In other words, I started doing with Adobe apps exactly what Adobe effectively forced longtime FreeHand users to do with their current and legacy files by acquiring FreeHand and then simply discontinuing it. So while the IDML option is no doubt a godsend to some hoping to escape Adobe's stranglehold, it's a non-issue to me because I've never painted myself into the corner of having my own working files held hostage by a subscription license scheme, and never will. To me, the "current version" of InDesign is still CS6. Like the rest of the Master Collection apps, it's dying a slow death and I'm not using it to create any new projects with a projected long life. JET

While I understand and mostly agree with the gist of your post, some caution is called for in perpetuating misconceptions—especially confusing to newcomers—by over-simplification and over-generalization. A PDF exported from some other program is not the same thing as a native Illustrator file. Illustrator can "open" a PDF because when it comes down to it, PDF started as a subset of PostScript and Illustrator is a full-blown PostScript interpreter. Illustrator can "open" a PDF in the same sense that Illustrator can "open" a PostScript file. Think of a PDF as a print stream "captured" on its way toward the printer. Native constructs of whatever program created it have been deconstructed to simpler, more basic objects that the PostScript interpreter in an output device needs to understand in order to render it. PDF is not really meant for full "native" editing. (Some features, like form fields, are obvious exceptions.) A few years back, the much ballyhooed proclamation from Adobe was "Illustrator's native format is now PDF!" That is mostly marketing smoke-and-mirrors. What it really means is that the PDF format allows for inclusion of a "cordoned off" section (kind of like a commented-out line in a program) into which the program exporting the PDF can write a complete copy of its own fully native data, so that that content is recognized by the program that exported it, but is ignored by other programs. And that's what Illustrator does with PDF. When you Save a PDF from Illustrator, you have an option to also include in the PDF a fully native copy of the document with all its actually native Illustrator constructs. Predictably, that makes the PDF file size much larger. But if you don't turn on that option, Illustrator saves just the functionally "dumbed down" (deconstructed) PDF content. Inversely, when you Save a .AI file from Illustrator, you have an option to also include in it a PDF version of the content. So some programs that can't import actual Illustrator native constructs can import the PDF content. That's not the same thing as actually having an Illustrator import filter, like say Corel DRAW, that actually tries to interpret and convert native Illustrator constructs (blends and grads, for example) into its corresponding editable constructs. (Many Adobe users are blissfully unaware that even its own Adobe InDesign page-layout application (at least as of version CS6) cannot really import an Adobe Illustrator file; at least not in the assumed common-sense sense. InDesign can only import the PDF version of the content in an .ai file if it's there. If you don't believe that, try it: Save an Illustrator file from Illustrator, but turn off the default (what should be called) "Include PDF version" option in the Save dialog. Then launch InDesign and try to import it.) As I understand it, since PDF is now an "open" format, any software company that wants to can take advantage of that functionality. For example, there is nothing preventing Corel from burying its native DRAW document in a PDF that it exports, and any application other than DRAW would just ignore that content. It's much the same as when Macromedia Fireworks treated PNG as its "native" format. PNG format similarly supports a "commented out" area in which Fireworks copies its actually native content. A Fireworks document may contain vector-based artwork, live text, etc. If some other application opens a PNG file created by Fireworks, that application only sees a raster image. If Fireworks re-opens the same PNG, it sees and opens its native and fully editable content (if it's still there). So yeah, you may get away with just changing the ".pdf" extension of a PDF exported by some program other than Illustrator to ".ai" and the recipient will be able to open it with Illustrator. But that is not the same thing as exporting an .ai file from a program that has an Illustrator export filter. Illustrator can open it simply because it recognizes PDF content. Unless the file content is quite simple, it will very likely not be nearly as natively editable as the recipient expects. One should not rely on that practice to fool someone (especially a customer) into thinking they are actually receiving a native Illustrator file containing fully editable Illustrator-native constructs, just as if it had been created in Illustrator. I'm not saying any of this to insist that Affinity needs a dedicated Illustrator export filter. Illustrator's too-long stranglehold exists not because it's "best" but just because that's what most people have used for too long. That's the way the world works. But strangleholds never become broken until they are resisted, and that's the way the world works, too. I will use Affinity for its own merits, just as I do Draw or Canvas or anything else; not as "poor man's Illustrator." Unrealistic? Nope. That was exactly my stance throughout the whole history of FreeHand. If a printing house wanted to be awarded my client's projects, they had to support the application formats in which they were provided. It was always stipulated that any necessary edits would be performed by me. PDF is the "great liberator" of Captive Creatives, that finally provided us more freedom to use programs we prefer. No longer does one have to use Adobe products. And we should use PDF as such, not continue to cower in the face of the monolith, just because it's still conventional-wisdom to many. JET

In such comparisons, count the clicks. In Illustrator: Select the Rectangle tool. Click (don't drag) the artboard. Key dimensions into the resulting modal dialog. Tap Enter to close the dialog. In Affinity: Select a Shape tool. Mousedown and drag the artboard. Key the dimensions into the non-modal Transform Panel. Tap Enter to commit the values. One is actually as efficient as the other. It's just a matter of being too habituated to Illustrators archaic plethora of modal dialogs. Affinity's treatment is arguably a more elegant process with which to become habituated, because the Transform Panel provides more settings (including ability to specify dimensions by trig functions) while you're there. The only advantage I really miss inherent to Illustrator's ubiquitous modal dialogs is that they "remember" the last-used settings. So you can, for example, doubleClick the Move Tool to invoke its dialog, which will still have the same last-used settings, and then just tap Enter. This behavior is also advantageous in axonometric drawing, in which, for example, it's common to need to perform the same vertical scale, like 57.74%, on multiple objects. But again, that advantage is far outweighed by Affinity's Transform Panel's ability to understand math expressions beyond single operator simple arithmetic. In comparison to Affinity, Illustrator's tool box modal dialog behavior is most advantageous with the Line Tool, but that's just because of two associated problems, one in Illustrator and one in Affinity: Illustrator's useless Measure Tool and Affinity's infernal bounding-box centricity. So I'm usually using that "memory" behavior of the Line Tool's modal dialog as a workaround for otherwise poor interface design. The interface of Affinity is never going to replicate the exact same click-for-click sequence for every function in Illustrator or any other competing program. One has to adapt one's "muscle memory" to any different program. JET

"Better than nothing" is a poor standard to which to aspire. JET