JET_Affinity

Yeah, I saw it after posting above. But I wasn't attacking gyalogosdesign, and no offense was intended. My comment was as much for the general readers. As you know, posting multiple different requests as a personal wish list in a single thread is bad practice, but unfortunately a very common one in forums like this. JET

Yes, but this thread is about snaps and selection. Each feature request should have its own thread. That's the only way others can peruse the feature requests in a navigable list in order to comment on them. That's also why no one should ever create those annoying 'My Top 10 List of Feature Requests' threads. That just wastes the purpose of the thread title and effectively buries all of the feature requests in a meaningless grab-bag. No one is going to open and read through everyone's 'My Wish List" to see what thing(s) are actually being discussed. That's why Dominik suggested your putting it in its own thread. It certainly is a request with high merit, so it should be discoverable in the list of threads. JET

It's also another "low hanging fruit" opportunity to surpass Illustrator. Throughout the FreeHand vs Illustrator competitive years, FreeHand users knew what a huge advantage it was to work with hairline strokes in the normal full-color interface. The only way to get hairline editing behavior in Illustrator is to put it in its lame Outline Mode. JET

I said: even the 5 basic ones (clearly referring to the 5 basic shape tools) were not even live shapes. The subject is the dialogs that open for each shape tool. Effect Menu>Convert To Shape is an entirely different subject. It has nothing to do with the shape primitive tools. Yeah, it could be used as a poor man's workaround for Illustrator's total lack of any editable LBO objects before even the lame "during mouseDown only" adjustment was added. The Effect 'converts' any object to display as either a rectangle or an ellipse (i.e., three shapes: rectangle, rounded rectangle, ellipse). It's main use is for applying as an Effect to an object's Appearances in the Appearance Panel. JET

CS6: You mouseDown and drag with one of the shape tools: During mouseDown, you can use arrow keys (and on some, other momentary modifier keys) to modify the parameters: But upon mouseUp, you just have ordinary paths: These are not live shape objects. They do not have adjustable parameters after creation, like most programs do (including Affinity). That came later in Illustrator, after the rental-only licensing. Illustrator was very late to the live shape primitives game, even with the limited functionality shown above in CS6. JET

Agree. Every vector drawing program should provide path length (and area, for that matter) for a selected path. Illustrator's was for much of its history hidden away in an undocumented 'Easter egg' programmer's window, the shortcut for which became known to users who in turn demanded its being added to the normal interface. So it ended up rather awkwardly in the catch-all Document Info panel. JET

Expand Stroke is, of course, a workaround as you said. But I'm sure the Affinity team knows that, and am confident a proper offset path command will be added. Hopefully it will be better than AI's; in that it will have options for intersection intelligence like Draw's Contour. I also hope it will have an option to require an offset path to have the same number of nodes as the original, even at the sacrifice of strict geometric 'accuracy' when rendered impossible by that option. The reason is, one of the most common uses for offset paths is to serve as base paths for object blends (which also has yet to be implemented in Affinity). Taking care to have the same number of nodes is key to controllable and predictable path blends used for shading. JET

This is one I don't really find hugely significant. In Illustrator, you can: Select the tool (or key its shortcut) Click (don't drag) in the document window to invoke its modal dialog Key in the desired value(s) Dismiss the dialog In Affinity, you can: Select the tool (or key its shortcut). Drag in the document window. Key the desired value(s) in the already visible non-modal Transform Panel (assuming you always have it open, as I do, in any drawing program). That also gives you access to position, rotation and skew transforms in the very same place, without having to invoke separate transform modal dialogs. Don't get me wrong; I'm not at all a fan of Affinity's dependency upon bounding-boxes for on-page transformations, but improvement in this is still possible if Affinity just continues to resist providing individual transform tools. I'm just saying that even though I was as habituated to invoking the dialogs as anyone, I'm not finding their absence an issue regarding shape dimensions. Affinity provides far more live shape primitives than AI. And through version CS6, even the 5 basic ones were not even live shapes. So the dialogs were needed for a few shape-specific inputs (e.g., rounded rectangle corners). JET

Kuttyjoe, Nothing I've posted is "a lie.' It is my response to the desirability of yet-another "me, too" auto-tracing feature, and is based on decades of experience. My take on the subject is every bit as valid as yours. Discuss features, not people. JET

Actually, the Move dialog opens when you tap Enter because you have the Move Tool selected. If you had one of the other transform tools selected, its corresponding dialog would open. When you re-invoke one of Illustrator's transform tool dialogs, it opens with the previously used values still there. it's something I and countless other longtime AI users leverage constantly. It's arguable whether this is really a deliberately intended feature, or more a "happy accident" inherent to the modal dialogs. After all, as soon as you use the same dialog with a different value, the previous one is lost. And if you enter a transform value, perform it, and then Undo, the value you just entered is lost. Would a seriously intended 'value storage' feature for often-needed values be implemented in such a way as to only work for the last-used value and not survive an Undo? Regardless, being able to store and recall a repeatedly needed transform value is quite useful and Affinity, as yet, doesn't provide for it. And more's the pity because Affinity does provide something closely related that Illustrator doesn't: The value fields of its (non modal) Transform Panel can interpret math expressions far beyond the simple addition or (not even and) multiplication that Illustrator's can. Affinity's help document lists 80-plus sizing, relational, document, typographic, and math variables and sample expressions supported by the program's value fields. This seriously begs for a feature by which we could store and recall our own project-specific values and calculations. What I'd love to see added to Affinity's Transform Panel value fields is something FileMaker Pro users know as User Defined Value Lists. I've actually built a working mockup of the idea built in FileMaker, from which the screehshots are taken: Imagine Affinity's Transform Panel value fields being given unobtrusive popup icons: The popups list expressions which, when selected, are applied to the current value: In each of the popups, the bottom selection is always Edit…: Selecting Edit… invokes the dialog in which the user adds, removes, or edits the expressions listed in the popup. Ideally, the dialog would provide two columns: one to contain the actual expression as to be applied to the value field; the other would be a name by which the user could refer to the expression: Document-specific Stored Expressions would be applicable to all kinds of illustration and design tasks. They would also: Serve to showcase Affinity's already existing, but as-yet under-appreciated competitive advantage of supporting a wide variety of expressions in its value fields. Be a gentle segway toward the potential of data-driven graphics for illustrators and designers without their having to dive into full-blown scripting. JET

Kuttyjoe, again; stop with your personal insults. You don't know me from Adam, and I don't care one whit whether you 'like' me. We are here to discuss software. Either keep it to that, or shut up. JET

You're the one who challenged everyone who disagrees with you on the basis if their 'lack of experience.' Or, you could simply post some "before and after" examples demonstrating how, when, and why auto-tracing is so essential and why you can't use a separate utility program for it. Stop with your ad hominem insults. The discussion here is about a feature. JET

Only about 35 years of it. JET

One guy's opinion. But you still haven't defined what constitutes an objectively "very good" auto-trace feature. You've just said "very good" equates to "excellent" or "much improved." All of these impassioned 'must have' demand threads for an auto-trace feature are tellingly devoid of real world examples of when and why an auto trace feature is so dang 'essential' and how its absence renders Affinity (or any other program) 'useless' and prevents 'switching to it' (another silly cliché) from any other program. I'm quite familiar with Illustrator and Corel Draw (and most other mainstream vector drawing programs). Illustrator's auto-trace feature is a time-wasteful and tedious interface, being implemented as a so-called 'live' effect. That was its differentiator. Draw's is more straightforward in terms of interface. But the results from either are generally pretty much the same as all the others. Yeah, users get acquainted with and accustomed to particular 'favorite' tweak and setting routines of the parameters provided in their pet drawing program and then declare it 'better'. Here's what's objectively very bad about it: The vast majority of auto-tracing usage is just amateurish bad practice.There hasn't been any significant advancement in auto-trace feature results in decades. They still have no shape-recognition intelligence. They don't know an eyeball from a car tire. They don't even know either one of them is supposed to be round. All they do is try to draw a path around a meaningless contiguous group of similarly-colored pixels, with no discernment whatsoever about what that set of pixels even represents. So the results are just a bunch of ill-formed paths, which look ugly and jagged when enlarged. That's completely antithetical to the whole intent and purpose of vector-based graphics in the first place: vector-based resolution independence. They all effectively swap one kind of poor-quality ugliness for another; meaningless jagged path shapes instead of bitmap stair-stepping. And because auto-tracing is a distinct, standalone operation, there is no reason why it shouldn't be done with a standalone utility, even if that utility is a whole other program. And multiple offerings exist for it that are even cost-free. Everyone nowadays routinely has multiple programs running concurrently and switching back and forth between them with a click hasn't been a problem since the mid 80s. You don't need everything you do to be built into a single program. If you think you do, then just think of your operating system as that "one program." Until auto-tracing algorithms actually undergo some significant advancement in the way of shape-recognition in combination with true path optimization, there is no need for every single drawing program that comes along to replicate the same old bad-practice with yet another "me, too" built-in auto-trace feature. It's not even on my wish-list for Affinity. JET

What do you expect the company developers to 'answer'? They know it's a necessary feature. It will be added when appropriate from a development standpoint. It's not there yet. Yes, you've "seen this kind of request for years." That's why yet another thread on it is unnecessary. JET

Please describe "very good." Or show an example. JET

Kotaru, Relax. I didn't say anything to suggest that the feature is not important. I just made a passing comment about the various names for it. JET

For what it's worth, I like the "bake" term better than "expand". In a 2D drawing program, "expand" is ambiguous in that it suggests enlarging something, like offsetting a path. FreeHand used "Ungroup" generically for de-constructing any kind of higher-level virtual construct to its next lower level basic constituent objects. "Expand" seems like one of those things copied just because it's how Illustrator does something, but otherwise has no merit of its own. JET

Please name threads by a specific topic. Everyone knows it's a "Feature Request" because it's in the Feature Requests & Suggestions sub-forum. JET

Affinity is not the only program that will display that message when you try to 'open' or 'place' a native .ai file that contains no .pdf version of itself. You will get the same thing in, for example, Inkscape, and even in Adobe's own InDesign. This is part and parcel of the fallout of Adobe's pretense that 'Illustrator's native format is PDF'. When you save an Illustrator document, by default, a complete and separate version of the document is "dumbed down" to more basic PDF objects and stored within the file. If that default option is switched off when you save the file, then no PDF version of the file is embedded in the file. Thus that bitmap image message. Assuming you are referring to the 'library' files in which Illustrator stores its default Brushes (which are just ordinary .ai files), the Brush artwork consists of vector-based paths. If, for some reason you must use these, you would be better off: Open the .ai file in Illustrator. (If you don't have Illustrator, have someone do this for you.) Save as PDF or SVG. Open the PDF or SVG in Affinity. That way, you'll have the actual scalable vector paths, which you can rasterize to whatever resolution you want for use as Affinity brushes. But frankly, I don't know why you would want to do this anyway. Illustrator's Brushes are vector paths. That's their whole advantage: vector scalability. But the ones you show as examples are the kinds of Illustrator vector-based Brushes which are trying to emulate raster-based effects (so-called 'natural media'). They are just jagged vector paths trying to look like raster-based texture. Their vector scalability is not really even advantageous. Scale them up (i.e., use them at large stroke width settings), and the fakeness of the effect they are trying to emulate becomes immediately apparent. They don't look like 'natural media' at all; they just look like jagged vector paths. [This is the very same basic fallacy of the oft-claimed 'necessity' for auto-tracing.] So why even start with jagged vector paths in order to end up with raster-based brushes? Being raster based to begin with, Affinity's brushes don't have to fake raster effects. You can make far more convincing raster effects with raster images. Why do you want to create a raster-based Brush from a bunch of vector-based jagged paths that are trying to fake the appearance of a raster-based Brush? The advantage that Illustrator's Brushes have over Affinity Brushes is that Illustrator Brushes are vector-based. Their advantage is HUGE when used for vector-appropriate purposes. But the inverse is also true. The advantage that Affinity Brushes have over Illustrator Brushes is that Affinity Brushes are raster-based. Their inherent advantage is just as huge when used for raster-appropriate textures. Using a bunch of jagged vector paths is a workaround for trying to make something look somewhat like a raster texture. JET

It's a good thing those occasions are rare. I would not do that with any drawing program other than Illustrator, regardless of whether the other program can Save As… .ai format. Moreover, if I were the customer, I would utterly disallow it. For example: CorelDraw can Save As… .ai. But that doesn't make it appropriate for use as a round-trip editor in a workflow that requires starting and ending with a native Illustrator file. The very same goes for the inverse situation: Illustrator can 'open' a CorelDraw file. (It cannot export a .cdr file). But were I a customer creating original .cdr files and then sending them to a service provider for round-trip editing, I certainly would not allow that provider to use Illustrator for that workflow. Each application has its own proprietary native constructs which differ from corresponding constructs in competing programs. Merely having Save As… or Export filters for competing native file formats doesn't change that. What if the CorelDraw file contains a native Contour object? Or a native Cone grad? Illustrator doesn't know what to do with those. What if the Illustrator file contains live Pattern Brush elements? CorelDraw doesn't know what to do with those. Native file formats are not the same thing as mere import and export filters. Cross-program filters have to try to re-interpret foreign constructs into their own nearest-corresponding native constructs or (quite commonly) de-construct them into more basic constructs. Depending on workflows like you describe is begging for problems. Not being able to export to .ai format is a non-issue. After all, even Adobe likes to claim that PDF is 'Illustrator's native format.' Save your Affinity file as PDF or SVG. Illustrator can open those. And good luck with that, too, in a round-trip editing workflow. JET

Importing DXF format exported from CAD programs in order to create visually appealing commercial artwork suitable for product marketing is squarely within the purview of general-purpose vector-based mainstream 2D illustration and design programs. And that's why most competing programs provide for it. And that's why I fully expect that Affinity will also provide for it—when the time is right from a development standpoint—which is entirely and appropriately at the discretion of the company which owns and develops the program. Like many other desired things, DXF is simply not, at present, at the top of the development priority list, nor should it be. It's not even at the top of the wish lists of most users. And yes, I say this as a technical illustrator. Affinity is still very much a work-in-progress, and there is still much work of a more foundational nature that needs to be done or tuned. Meanwhile, there are multiple online and open-source DXF converters. Claiming that Affinity is 'un-usable' is just as silly in this context as it is in any of the threads demanding far more broadly-desired features. JET

It would not make sense to be able to marquee select (quote 1) the parameter handles of live shape objects (quote 3), because those handles do different things for different kinds of live shapes. It's standard-fare in any drawing program that provides live shape objects with adjustable parameters to have to "break apart," "ungroup", "expand", "convert to path", etc., those objects before being able to directly manipulate their individual Bezier nodes and handles. Again, I'm not enamored with Affinity's selection scheme either. I think it needs serious re-work, especially in regards to the overdone dependency upon bounding boxes. My complaint with the basic selection interface actually starts at the ground level question of why a drawing program needs two separate selection tools in the first place. (As a long-time FreeHand user, I know experientially that its single selection tool was both more efficient and more powerful than the now 'de facto standard' of having two separate selection tools, and all the caveats stemming from that. But that ship has, unfortunately, sailed.) But the quotes above are what I'm reading your meaning from. Suppose, for example, the box object in your video were a live star object. It wouldn't make sense for a marquee selection to select enclosed nodes of a text frame, enclosed nodes of a basic path, and one of the parameter handles of the star object. Nor would it make sense for enclosed nodes of actual star-shaped path to be selected, because the positions of those nodes are programmatically determined by the parameter adjustments; you'd be "breaking" the behavior of the live object. That's why all programs with such constructs require you to deliberately de-construct them to more basic objects. JET

Correct. First, I'm not particularly enamored with Affinity's selection interface, either. But... Illustrator has been embarrassingly devoid of geometrically functional "shape primitives" for most of its history. Its shape tools created nothing but basic Bezier paths. With all its marketing ballyhoo about 'live effects' it couldn't, for example, even adjust the corner radii of a rounded rectangle because there was no actual rounded rectangle object; as soon as it was drawn and deselected, it was just an ordinary eight segment path. Same thing for its polygon, star, and ellipse tools. And I'm talking all the way through version CS6, the last version before Adobe's customer-abusive subscription-only licensing scheme. It is powerfully useful, for example, to be able to set (and change) the start and end angles of an ellipse in technical illustration. For the vast majority of its history, Illustrator couldn't do that, despite the fact that even the hobbyist level drawing modules in some 'works' or 'office' applications could. JET

Have you been keeping up with the current beta? If not, you should. It's still not "there" yet, but work is at least being done in this area. You can download and install the current beta and run it next to the release version. The most debilitating Achilles heel of this program, in the context of serious illustration, is its insistence on transformations being based upon infernal bounding box handles instead of providing a set of transform tools that work by dragging and snapping sub-selections of nodes and segments. I don't know if the rationale is too much focus on 'finger painting' with mobile devices, an overboard fear of tool glut, an ill-conceived reluctance to ever permanently "reset" the original bounding box orientation of any path, or some combination of those. But bounding boxes are usually just needless and redundant clutter that gets in the way when needing to directly and accurately manipulate deliberately drawn freeform paths; which is the predominate norm in serious illustration, not the occasional exception. JET