Jump to content
You must now use your email address to sign in [click for more info] ×

JET_Affinity

Members
  • Posts

    529
  • Joined

  • Last visited

Everything posted by JET_Affinity

  1. Having just downloaded the 2.4.0.2301 update, the first thing I've done is rush to check again the behavior of this feature, which—to me—is the most important of all in the new beta. I'm still somewhat disappointed: Unless I'm missing something, if I… Select multiple objects, one of which is a diagonally-oriented (relative to the page) simple, straight path drawn with the Pen. Set that straight path as the Key Object. Select_Set Selection Box. …then the bounding boxes of the objects other than the straight path do not re-orient to that of the straight path. Instead, they seem to either re-orient to one of the selected but non-key objects, or sometimes even become skewed bounding boxes. First off, there is nothing intuitive about this behavior. Moreover, it wrecks what is, for my purposes, the greatest potential of a feature that (at long last) enables us to re-orient the scale handles independently of the current orientation of the content of the bounding box. Set Selection Box should work the same way when the Key Object is an open straight path created with the Pen, as when any other object is the Key Object. One of the first things mentioned in the initial announcement of this feature is isometric drawing. Well, a very basic principle of axonometric drawing (not just isometric) is that the minor diameter of any ellipse (that is a projection of a tilted circle) is always parallel to its 'thrust line' (the 'axis' that the ellipse 'orbits'). Failure to do that is the 'dead giveaway' of one of the most common errors in technical illustration. It instantly 'jumps off the page' and 'hurts the eyes' of an experienced technical illustrator. But here's the thing: That principle of circles always being foreshortened in the direction parallel to their 'thrust lines' does not just apply to circles. It applies to literally any planar shape(s). Whole labels. Whole floorplans. Everything. We need to be able to do this: Draw something 'in-the-flat', no matter how simple or elaborate. Draw a simple, single-segment, straight path in any diagonal direction (the 'thrust line' that is perpendicular to the plane of the object(s) about to be scaled). (We should not have to use a box or anything other than a straight path, just to serve as a scale direction). Rotate the bounding box(es) of the objects to be scaled without rotating their contents, thereby snapping the scale handles into parallel with the 'thrust line'. Deselect the 'thrust line'. Scale the other selected objects in the direction parallel to the 'thrust line'. It should be obvious that the need to simply draw a simple straight path in any required direction and have it serve as the 'thrust line' is essential (and intuitive). That feature, if implemented as described, would be something that to my knowledge does not exist in competing mainstream 2D general-purpose vector drawing programs. But here's the other thing: I don't see why the interface for this can't be more intuitive and more elegant: Simply provide a momentary keyboard shortcut that, when dragging the 'lollypop' bounding box rotation handle, causes the bounding box to rotate without rotating its content. And make that rotation aware of active Snap settings. Seems to me, that would be more direct and intuitively discoverable than the menu selections, and on-page tactile instead of just tucked away in a menu. Lest anyone think this is only about mechanically-correct tech drawing…it's not. Example: Suppose I'm not just a tech illustrator, but also a caricaturist. Everyone knows that every time Pinocchijoe opens his mouth, his nose grows. So suppose I've drawn a series of cartoon frames in which Pinocchijoe is looking up at the sky, down at his feet, for the nearest stage exit, etc. I need to increasingly stretch his nose in the corresponding direction in which he's looking in each subsequent frame. So I simply: Select the object(s) that comprise his nose Set the transform anchor at the base of his nose mousedown on the lollypop, press the keyboard modifier, and rotate the bounding box around its content mousedown on the now correctly-oriented scale handle and drag it to scale the selection in the needed direction What am I missing here? JET
  2. Exactly. In plain language for graphics people who have yet to get their feet wet in scripting: JavaScript is the language used to script in, for example, Adobe Illustrator. JavaScript is not difficult for non-programmers to learn, and is ubiquitous. But much of what you can accomplish with JavaScript in Illustrator relies on Adobe's so-called ExtendScript (Adobe's 'extension' to JavaScript) and ScriptUI. These effectively provide the scripting user a set of 'pre-built' JavaScript constructs and objects that are specific to Adobe applications. Things like: Modal dialogs that you can include in your scripts to appear within the program to, for example, prompt the user of your script to do something, like input desired values or select specific result options. Non-modal interactive 'control panels' that you can include in your scripts to remain visible within Illustrator while the user works with the script to, for example, try, preview, and change the result while the script is running, before committing it. A thorough (and thoroughly documented) Object Model that is a 'library' of Illustrator-specific constructs and their properties and methods. Those are the things that make application-specific scripting far more than just a glorified 'macro' for automating repetitive tasks like exporting files or executing a series of standard commands. They effectively inform the scripting language (JavaScript) of the 'under-the-hood' (i.e., under-the-interface) details of the program. They effectively empower you, the user, to create custom functions and features way beyond the standard feature set of the program. Just one example, for clarity: One of my earliest Illustrator JavaScripts (well over a decade ago; maybe two?) is for drawing geometrically correct vector spheres at any desired orientation in a matter of seconds. When launched, the script presents a series of user prompts asking for the desired number of latitude and longitude lines and the angle at which the pole of the sphere is tilted. I still use that script to this day (along with a considerable collection of others). Those are the kinds of things I am interested in scripting in Affinity Designer—adding full-blown drawing features to the program for things that it can't do in its standard feature set—as opposed to just 'recording' and 'playing back' a series of existing commands. (Realize, Adobe applications have had that, too—long before they had their JavaScript implementation—in the form of their so-called 'Actions' feature.) I seriously hope the currently underway development of scripting support for Affinity includes full focus on a comprehensive application-specific object model and clear, thorough reference documentation of it upon its initial release. JET
  3. I whole-heartedly agree with your comment re FreeHand. But even in that context, this is still true: One of the huge advantages of FreeHand was its direct and convenient provision for drawing in 'hairline' mode; wherein paths are displayed at the smallest stroke width, regardless of zoom. Greatly enhanced accuracy confidence, and was my default mode whenever drawing Bezier paths. Illustrator's 'Outline Mode' (or whatever it's called; don't remember for sure, and don't have Illustrator installed on this laptop)—is a poor substitute. As a tedious workaround, I always draw paths in Illustrator using the .25 pt. stroke width, and apply Styles thereafter. Pain in the neck, which can be said of many many things in Illustrator compared to FreeHand. So, yeah, something needs to be re-worked in the doubleClick to switch tools. Its being dependent upon clicking a path's stroke width versus its path is not good interface design. Even given that, we FreeHand users recall that It never needed two selection tools, and only added a mimic of Illustrator's so-called 'Direct Selection Tool' as a conciliatory move for Illustrator-habituated users too impatient to come to understand that FreeHand's single Selection Tool was far more efficient than Illustrator's three separate path manipulation tools (the third being the stupid 'Convert Anchor Point Tool'). It was not until the very last version of FreeHand that the 'white pointer'—as we called it—was even given a single (and still insignificant) function that couldn't be done with the single 'black pointer.' Well-versed FreeHand users have yet to see any Bezier drawing program that matches FreeHand's interface elegance. JET
  4. Yes, but the screenshot you showed while repeatedly referring to "smart nodes" was of the Pen Modes, none of which are labeled "Smart Nodes." JET
  5. Smart Mode, not 'smart nodes'. Also turn on Rubber Band Mode to preview the next segment. JET
  6. Well, I, for one, am not. No one applauds what Serif is doing more than I. But I will never pay extorsive subscription fees for mission-critical software, effectively surrendering my own work as hostage to the vendor. It's not a matter of 'being able to afford it'. It's a matter of principle. I maintained my (not cheap) perpetual license to Adobe's Master Collection from its initial release until the day Adobe foisted its Captive Creator licensing scheme upon its decades-long users. That very day was full-stop. I immediately initiated my own methodical plan for eliminating dependence upon Adobe, which has not received one red cent from me since. Indeed, the very marketing myth 'promise' of subscription-based software fees is that it's 'more affordable' to 'starving artists' than the lump sum payment of a perpetual license. It's the same age-old scam of saying renting a roof over your head is 'cheaper' than owning it. I'm sure Serif is profitable and knows quite well what it's doing. A large part of what Serif is doing is the long-overdue embodiment of competition: providing dramatically higher price/function value in a market segment that has been artificially overpriced for ages. 2D bezier based drawing is not rocket science anymore. Adobe and its ilk still cling desperately to the antiquated price structure of long-gone days when a 3-color letter-size inkjet printer cost ten times what far more capable machines go for now, even despite decades of inflation. Serif is developing its products at its methodical rate, with a much-appreciated eye toward innovation; not just implementing tit-for-tat, copycat, me, too, same-old features. Learn to exploit what it provides. Workaround what is not yet implemented. Provide at least marginal originality in feedback. JET
  7. "…but not if you press shift" So?? It doesn't scale if you press Ctrl {Windows} either. But without pressing a modifier key it both scales and rotates in one move. So how would "scale" be a more appropriate name than "transform"? Look; I'm all for intuitive and consistent terminology. And I've been at this for a while, too. I cut my vector-drawing teeth in Altsys Fontographer—the progenitor of FreeHand, before Illustrator even existed—on a Mac Plus. But egads, man, there's no real issue in this instance. Dear departed Aunt Mollie would call this "straining at a gnat to swallow an elephant". For a real interface terminology issue, look no further than the current abuse of the "Pages" (or Artboards) and "Layers" terms. What is intuitive about starting a new document which displays a working area that certainly looks like a page, drawing an ellipse on that 'non-page', and having the ellipse immediately listed in a Panel named "Layers" in which there are no Layers (or Pages)? Since when is a single ellipse a 'Layer'? This is supposed to be intuitive terminology convention? But we should take issue with "Point Transform Tool"? Illustrator is historically one of the worst about needlessly renaming its so often late-to-the-game constructs and features that existed long before in competing programs. Calling pages 'artboards' and nodes 'anchor points'. Its utterly needless and wordy 'Convert Anchor Point Tool'. Starting the whole now pandemic 'necessity' for two primary selection tools—the second of which is awkwardly named the 'Direct Selection Tool'—when FreeHand's elegant single selection tool performed all the functionality of both, more efficiently, intuitively, and capably. Adobe should hardly be considered the authoritative preferred 'dictionary' for best feature naming. So yes, I quite agree that words mean things. But functionality still trumps. The functionality of the Point Transform Tool addresses crucial omissions that stem from having only bounding box handles for common transformations: being able to rotate paths by their nodes, so as to intuitively snap them to paths and nodes already drawn. Before the Point Transform Tool, that was a serious failing relative to Illustrator. It's actually a bit of a new wrinkle and more elegant and accurate than the corresponding functionality in Illustrator. Pen Tool: Draw three arbitrarily-shaped open paths; one near the upper left corner of the page; one near the lower right; and one in the middle. Your goal is to scale and orient the middle path—without distorting its shape—to perfectly fit between two arbitrary nodes; one on the upper left path and one on the lower right path. Point Transform Tool: Select the middle path. Mousedown on one endNode of the middle path. Drag and snap it to the target node on the upper left path. Drag the Transform Center and snap it to that same node. Mousedown on the other endNode of the middle path. Drag and snap it to the target node on the lower right path. Done. Tell me how you would do that as quickly and intuitively in Illustrator with one tool. "…do we need a [term like] 'Point Transform Tool' that…makes little semantic sense to most people?" Yes! We need different terms for interface elements that are significantly different treatments of similar functionality in other programs, so that we know they're not just another re-packaged 'me, too' identical copycat treatment of same-old market-dominating (and progress stifling) programs like Illustrator. I cringe every time I see users in forums like this demand "We must have a [insert Illustrator's term] tool in Affinity!", as if Illustrator's cluttered, confused, scattered, and often mediocre treatment is the ultimate de facto thing to emulate. Affinity is opportunity to finally advance 2D bezier drawing beyond the mediocrity of Illustrator. But it won't get there by just thoughtlessly demanding identical treatment from such long-in-the-tooth programs without putting at least a little thought toward how it might be done better.
  8. Loukash, You are misreading me. What you describe is not at all the same as scaling the selection only in the direction desired, like the scale handles on the sides of a bounding box do. 1. Draw a square. Convert it to paths. 2. Draw an arbitrary diagonal line across the square. 3. Scale the square in the direction of the diagonal line only; in other words, without also changing its dimension in the direction perpendicular to the diagonal (disproportional scaling, like dragging a bounding box side handle does). JET
  9. Bit Arts, The Point Transform Tool is not "just a Scale Tool". It also rotates. The definitive difference between it and the bounding box handles is that it effectively lets you use any node of the selection as the 'transform handle' instead of a bounding box handle, which is often irrelevant to the drawing. The dragged node can be snapped to nodes or edges of other existing paths as it is transformed. So the "point" word, I suppose, is collective generic reference to Nodes and the Transform Center as 'points' meaningful to the drawing itself. It does not, however, obviate the function of bounding box handles, because it does not (so far as I can tell) provide for scaling disproportionally, which is also very important. That's why just having transform tools in the toolbox that act like Illustrator's (at least as of CS6; Adobe has not received a penny from me since its Captive Creative subscription) does not satisfy, either. That's why Illustrator also has bounding box transform handles. But even with Illustrator's transform tool and bounding box transform handles (again, as of CS6), one still cannot scale a selection disproportionally in an arbitrary direction other than perpendicular to a bounding box side or to the ever-tyrannical horizontal or vertical. That's why, as I suggest, if Affinity's utterly superfluous 'lollypop' bounding box handle were given the ability to rotate the bounding box independently from its content (by means of a momentary keyboard shortcut), the functionality would not just match Illustrator's functionality, but surpass it. JET
  10. Right. Bounding box based transformations—as opposed to transform tools—is one of the main interface elements that make Affinity apps seem more 'amateurish' than they really are. I've said it before and will continue to do so at every opportunity: Bounding box handles being the only tactile (mousedown and drag) interface for basic transformations is sub-standard. Bounding box corners and side midpoints very often have nothing whatsoever to do with the portion of the artwork being transformed. We need to be able, for example, to scale a selection in any direction needed; not just in the often irrelevant directions of the selection's bounding box sides relative to the infernal page edges. This is why—so long as Affinity is going to cling to only bounding-box based transforms—it should at least make one of the absurdly redundant five bounding box rotation handles able to rotate the bounding box around its content, so as to 'aim' the scale handles in whatever direction needed. JET
  11. For anyone not really catching the subject of this thread: The typical 'rotate view' feature in mainstream vector drawing programs tries to emulate the pre-computer habit of rotating a pad of paper to comfortably accommodate the angled movements of one's forearm when sketching with a pencil. It's a poorly-conceived analogy because: The analogous 'rotated page' is still being viewed through the unmoved horizontal-vertical 'window' of the monitor. The 'drawing sheet's' corners are effectively lopped off. If the rulers are displayed, they remain horizontal and vertical; useless for measuring in the drawing. Thus, for those drawing on a computer with a stylus and feeling the need to rotate the 'drawing sheet' a proper emulation would be to simply tilt the monitor itself on a rotatable monitor mount. Meanwhile, absolutely crucial for any kind of measure/proportional drawing is to be able to make measures and perform scaling transformations in diagonal directions in the drawing, not just merely in the vertical and horizontal edges of the page. The pre-computer analogy to this would be the freely-movable and freely-rotatable scale of the parallelogram-style or track-style drafting machines in any serious engineering department. Yet for the full four decades history of general-purpose mainstream vector-based drawing programs, I know of none that has done a decent job of emulating that direct, straightforward, intuitive functionality. This is why many experienced pre-computer tech illustrators can still often do axonometric drawings faster 'on the board' than on a computer using mainstream vector drawing programs. These programs sometimes attempt to address the very basic need by: Page-spanning grids. The fallacy of this is that such grids, by definition, have uniformly-spaced increments. But it is absurd to assume that all real-world objects that we need to draw in accurate proportion are both shaped and spaced relative to each other according to some invisible universal set of equal-measure increments. Yes, in pre-computer days, technical illustrators sometimes resorted to using underlay grids under their translucent drawing sheets as a workaround for when away from their drafting tables. But page-spanning grids are usually just useless clutter when focused on the current area of interest. Rotating bounding boxes when a selection is rotated. Most drawing programs in this class always display vertical/horizontal (page normalized) bounding boxes (e.g.; Inkscape}, regardless of the rotation of the selection. A few programs provide bounding boxes that rotate when the selection is rotated. But even this fails miserably when—as with Affinity—there are no transformation tools, but instead just transform handles attached to bounding boxes. The needed functionality is only available when the transformation or measure needs to be made in the directions of the bounding box sides, which just as often has nothing to do with the measurement/transform direction needed in the drawing. As already explained, existing 'rotate page' features fail to address this. When the display of the page content is rotated, so are the 'horizontal' and 'vertical' directions rotated with them, even as the now useless page rulers remain parallel to the monitor. Thus, for those needing to draw objects with measured accuracy, two at least significantly better provisions of the needed freedom to measure and transform in directions meaningful to the drawing would be either: Ability to temporarily rotate the page's content relative to the page rulers without also changing the orientation of 'vertical' and 'horizontal' movement, transformation, and measure, or… Give one of Affinity's absurdly redundant five bounding box rotation handles some added functionality: Give the lollypop handle the ability to rotate the bounding box about the selection, thereby enabling the illustrator to the transform handles to whatever direction is actually needed relative to the content being transformed. JET
  12. That's also actually the problem of the feature. I've been saying this since the earliest implementations of 'page rotate' features in other programs, and always argued that fans of such features (as implemented) should just buy a dang rotatable monitor mount. Many of us have no interest whatsoever in the typical 'rotate' feature because we don't use styluses and we do need a way to overcome the near universal horizontal/vertical fixation of these kinds of programs, as if illustrators never need to measure or scale objects in other directions. JET
  13. I've said this before in other threads, but it is pertinent to this thread, too. so... Every serious vector-based illustration program should provide for transforming selections disproportionally in any direction needed, not just horizontally and vertically. So first, it is a very good thing that Affinity bounding boxes 'remember' their contents' rotation. Since Affinity does not provide transform tools, but only provides transform handles on bounding boxes, that is the only way to perform on-page scaling in directions other than vertical and horizontal. Yes, I agree that one should be able to permanently re-set an object's to page-normal when desired, but a rotated bounding box is a very useful thing. Inkscape, for one example, insists on all bounding boxes always being page-normal. So when you need to scale a rotated selection in the direction of its rotated orientation, you have to 'un-rotate' it so that the desired direction of scaling is either horizontal or vertical, perform the scaling, and then re-rotate it to its intended orientation. That's needlessly tedious. But Affinity's treatment is still senselessly limited. Consider an object that is rotated 35 degrees. Its rotated bounding box is 'remembered'. So you can disproportionately scale it in either the 35 degree or 125 degree directions. But by what logic is it assumed that the illustrator does not need to scale the rotated object in some other direction that is pertinent and meaningful to the illustration. Affinity bounding boxes provide an absurdly redundant FIVE rotation handles! One of them already has a different visual treatment: the 'lollypop' handle. Give that handle a practical and useful difference: Enable it to rotate the bounding box around the selection when a modifier key is pressed, thereby enabling the illustrator to 'aim' the transform handles in whatever direction needed, relative to the selection. JET
  14. Vector drawing programs have done fine without the silly lollypop since the 80s. 'Difficulty hitting' a handle is usually controlled by a proximity setting in user prefs. But it's a moot point anyway. I didn't say get rid of the silly lollypop; I said "...give it the ability...." That could be accomplished by means of a momentary keyboard modifier when dragging it. I said to give that ability to the lollypop because that 'fifth wheel' rotation handle is the one that looks 'special' in the interface. Giving it the ability I desire would actually make it special. I assume the silly lollypop is for those using their fingers on touch screens. I gave up finger painting when I was 3. JET
  15. Bounding boxes have thie As a FreeHand user for the entire life of the program, I certainly relate. Two things FreeHand users despised about Illustrator's interface was the visual clutter of bounding boxes and its insistence upon two separate selection tools. Unfortunately, almost all drawing programs have mimicked both, just because the market 'majority' is too accustomed to the inferior interface of Illustrator. But bounding boxes do have their uses, and "always' working with them off sacrifices that utility. In that sense, it's parallel to the way many Illustrator users claim to 'never' use the Selection Tool (black pointer) and 'always' use the stupidly named Direct Selection Tool (white pointer). The uses of bounding boxes pertinent to technical drawing are far more than just serving as snap points for guides. Affinity's bounding boxes are better than, for example, Inkscape's in that they rotate with their content. Inkscape's always reset to normalized to the page, no matter how you transform the selection, which is downright debilitating. By what logic does any illustration program assume that a user only ever wants to scale a selection either vertically or horizontally? Affinity's bounding boxes are better than Illustrator's. Like Illustrator's, they rotate with their contents. This is invaluable in technical Illustration because the side scale handles remain oriented to their content; for example, they remain oriented to the major and minor diameters of a rotated ellipse, and the measures in the Transform panel reflect those of the major and minor diameters. Like Illustrator's they can be re-normalized to the page. Unlike Illustrator, rotated objects still 'remember' their rotated orientation, and their bounding boxes comply. If you 'reset' a rotated bounding box in Illustrator, its rotated orientation is lost. Unfortunately, Affinity's bounding boxes cannot be permanently reset to page-normal, despite this having been requested for years. But the main ramification you have to keep in mind about any wish of 'getting rid of' bounding boxes in Affinity is that you loose any tactile on-page transformation tools, because Affinity doesn't provide transform tools in the Toolbox, like both Illustrator and FreeHand always have. You have to transform objects using the ridiculously redundant bounding box handles, which of course most often don't even reside on the objects being transformed. Yes, you can perform transformations numerically in the Transform Panel, but that's not "tactile on-page". So I'm afraid you're stuck with bounding boxes in Affinity. Being stuck with bounding boxes, they should at least deserve far more thoughtful and powerful implementation than they have. What justifies a ridiculous five rotation handles? Almost as frustrated as my comment about Inkscape, by what logic does any Illustration program assume that a user only ever wants to scale or measure a selection in the directions of its bounding box? Do something new and tremendously useful: Take just one of those absurdly redundant five rotation handles (the lollypop one) and give it the ability to rotate the bounding box about the selection so that its scale handles can then be used to scale the selection in whatever direction needed. And provide an option to permanently reset the selection's 'remembered' orientation to the current orientation of that rotated bounding box. This one simple feature would, so far as I know, be unique in this program segment, and immensely useful for technical drawing (and other drawing types, too). JET
  16. Thanks, Garry. I just became aware of V2 yesterday, rushed to order it, and that was the first thing I checked for. Of course, searching the Help files for "Cycle Selection Box" returns no results. (Affinity still sorely needs a far better implementation of its documentation.) Having the keyboard shortcut for it is certainly nice, but keyboard shortcuts are not limited to menu selections. The main toolbox icons have them. No reason the Context Bar icons can't have them. I still insist that one of the best features that could be done for Affinity Designer's interface is to make the 'lollypop' rotation handle able to rotate the bounding box independent of the selected content. This would be a godsend for illustration. Where do developers get the notion that the only direction in which something needs to be scaled is parallel to the bounding box? For the simplest and most common example, consider any ellipse that represents a tilted circle: The minor diameter of such an ellipse must always be aligned parallel to the direction of the 'thrust line' that the circle 'orbits'. But this principle applies to countless other things, too, including shapes and artwork that are not bilaterally symmetrical like an ellipse. One needs to be able to: Rotate any shape drawn 'in the flat' so that it is oriented correctly about its thrust line. Then scale it in the direction of its thrust line to make it appear tilted. This is essential in axonometric drawing, but just as valid in general commercial illustration. JET
  17. Can't help, other than to sympathize and agree. Affinity's very weak documentation is one of the first things I noticed about it. It's not just the search; the writing is far from thorough, too. Have assumed it will eventually be improved. Best-written user documentation of the many programs I've used over the decades is that of FileMaker Pro. Even it, though, was better before it became web-based. JET
  18. Alternatively alternatively: a macro recording feature. Alternatively alternatively alternatively: a Javascript-based scripting implementation. JET
  19. I've hung out on the 'big four' user forums for decades, practically never seeing a response from a developer. When this product and its forums started, it enjoyed the most refreshingly direct customer-to-developer access I have ever seen in this market segment. Affinity developers certainly don't need me to speak for them, but I strongly suspect that the current absence of that interaction is not entirely unrelated to the ceaseless repetitive and unproductive 'threats' of too many whiny users effectively looking a gift horse in the mouth. In an engineering department where I used to work as a technical illustrator there was a sign on the wall that read "In the course of every design project a point is reached at which it becomes necessary to shoot the engineers and begin production." The same principle no doubt also applies to rude users (and yeah, I've been one of those in other user forums, too). I expect version 2 is also not going to be perfect, but is still going to be great. JET
  20. "To speed up with new releses I was thinking that we need to pay more..." Warning: Old guy rant. No, no, no. 2D Bezier-based drawing is not rocket science anymore. The old-guard companies like Adobe and Corel that were established in the mid-80s hey-day of GUI computing are clinging to an outdated pricing model. Far too many users are too willing to succumb to the most customer-abusive scheme ever devised (software 'rental'). Serif and others have already proved that neither outrageous prices nor subscription schemes are necessary for solid profit and growth. That's empowering game-changing competition. That's free enterprise. That's progress. That's the very revolution this software segment has needed for far too long. Support them. Don't invite them to adopt the same pricing and licensing strategies of monoliths that think it's their birthright to forever dominate an industry. And sheesh! I wish everyone would stop whining about every new program not being the tit-for-tat mirror image of the single old-school application to which he or she happens to be most habituated. I've been doing this stuff for a living for well over four decades, and can still make a list of never-addressed complaints about any of the old programs. And guess what: I was making that living long before any of them had mesh grads or cheesy instant-gratification distortion envelopes that make a mess out of a typeface's painstakingly developed design principles. Most of those old programs still can't 'understand' a basic trig function keyed into a value field. Affinity can. I'm not saying just be satisfied with the status quo. By all means, continue to request well-thought-out improvements. That's also progress. But try to be more innovative about it than just forever cursing a $50 program for not being a clone of (gag me) Adobe Illustrator. And meanwhile, learn to use the capabilities of the tools you have to their fullest. Don't try to tell me that professional and profitable work 'can't be done' in Affinity. That's utter nonsense. My Kawasaki W800 can't do everything the (good riddance) KTM 790 it replaced. But I find it far more enjoyable while it gets me wherever I need to go. JET
  21. Neo, Your post is a little difficult to understand because you are not consistently using the terminology of the program (or terms generic to programs of this genre). But after reading it a few times, it sounds to me that what you're desiring is the ability to select a straight path segment, and have just that segment's height and width displayed in the H and W fields so that you can numerically specify the height and width of just that segment. While I agree whole-heartedly with the basic need, I see two problems with it: First, you would still have the same problem you mention with diagonals ("...doesn't work well...at an angle"). Far better is to be able to specify the length of the selected segment, which Affinity does provide for: Pen Tool: Click 3 times to draw a path consisting of two diagonal straight segments. Node Tool: Select the two nodes at the ends of the segment of interest. The L field of Transform Panel shows the length between those two nodes. The R field shows the angle of that segment. You can key in the desired length without changing the R value. Of course, that brings up your second problem: "...adjusting the size or length of line should offset other contents attached to it...". Changing the length of one segment without changing its angle necessarily changes the length and angle of any adjacent segment of the same path. But are you aware that you can, for example: Move Tool: Select the path. Point Transform Tool: Click one end of one of the segment of interest to set the Transform Origin at that node. Point Transform Tool: Mousedown on one of the other nodes, press shift and drag. As you drag, Shift constrains the direction relative to the Transform Origin. The other segment also moves and scales. A cursor tooltip displays the scaling change as a percentage. In other words, if I'm understanding you correctly, what you want is the ability to specify the length of a straight segment without changing its angle (which we can already do), but have a choice as to whether doing so changes angles and lengths of adjacent segments of the same path to accommodate (as it does) or scales the whole path to accommodate (which it doesn't). All that would be needed to provide that is another proportional chain link icon in the Transform panel (next to the L field) or (perhaps more intuitive) a single checkbox labeled "Scale Path". Bottom line is: Affinity already provides more in this regard than most programs of this genre; the ability to numerically specify the length of a diagonal straight segment without changing its angle. A simple, modest addition of another proportional link icon or checkbox associated with the L field could greatly enhance that ability. But meanwhile, at least a workaround is possible using the Point Transform Tool, as described above. In programs of this genre, (Bezier-based drawing programs) the underlying geometry required for many tasks is there, but the interface just doesn't include explicit tools for them. So it's often necessary to employ a little on-page temporary 'construction' to do them. Such a workaround for this would be to: PenTool: Draw a separate temporary path to serve as a 'ruler', snapping to the nodes at the ends of the segment of interest. Node Tool: Select both nodes of the temporary path. Set the desired length in the L field. Point Transform Tool: Click the original path to select it. Click the node that corresponds to one end of the 'ruler'. Mousedown on the other end of the segment of interest. Press Shift and drag to the other end of the 'ruler'. Move Tool: Select and delete the temporary 'ruler' path. JET
  22. Those of us familiar with FreeHand's as-yet still unmatched Graphics Find And Replace palette are writhing in our seats. o This is one of countless similar things that, in my opinion, are better accomplished with a Javascript implementation than with a 'same for everyone' command. You would want to control multiple variables for such a feature. For example, should all instances of the object-replacing Symbol be the same size, or should each be scaled to the size of the corresponding object it's replacing? Should each instance be rotated to the same orientation as the replaced object? Should each instance take on the color of the replaced object? What about nested objects? Would the replace-with-symbol command 'dig into' groups, or replace the whole group? There are use-cases in which I would answer 'yes' or 'no' to each of those--and other--questions. I say this from experience, having written my own 'features' in Illustrator for years, the details of which can be customized (or optioned) to work exactly the way I want it to. For example, with my own Illustrator Replace With Symbol Javascript, I can simply replace selected objects as you describe for things like icons in maps. But I can also: Create entirely vector-based faux halftones in which each halftone dot becomes a Symbol sized according to the greyscale value of the dot. or... Draw lines of random lengths radiating from a single point at random angles. Then position a Symbol at the endpoint of each line, each scaled and rotated according to the direction and length of the individual lines, thereby creating 'explosions' or 'swarms' radiating from a center. One-size-fits-all behaviors tend to leave as many users dissatisfied as satisfied, resulting in the "close, but if only..." frustration. JET
  23. Not to butt-in on Lagarto's generous attempts to help, but it seems that a very common general misconception about the basics of working with Spot inks may be at play in this thread. So please forgive my attempt to re-phrase part of what has already been explained: I emphasize inks instead of saying Spot colors because software users confuse 'swatches', 'colors', and such with inks, and thereby think working with Spot inks is more complicated than it is. Even when talking about CMYK process, color-separations for prepress production are not imaged in colors; they are imaged to film or directly onto the press plates as grayscale or bitmap images. The 'color' is all about what inks are loaded into the press. When you define a 'Spot color' in software, all you're really doing is telling the software to specify that an additional grayscale separation be generated and labeled by that name. Any objects in the file to which that same label is applied (by selecting the defined Spot color swatch named by that label), get sent to that extra grayscale separation. It really has nothing whatsoever to do with selecting a Spot ink from a 'library'. The Spot 'libraries' are nothing but a convenience for selecting the ink manufacturer's recommendations for how to approximate their inks' colors on an RGB monitor. Functionally, it's literally "all in the name." What color gets printed is entirely just a matter of what physical ink the pressman loads into the inkwell of the press. As Largato explained in other terms, you can specify how a 'Spot color' or a 'Spot swatch' appears on-screen any way you want: by selecting it from a pre-defined 'Spot color library' or by just coloring it with literally any mix of RGB or CMYK values you want. Either way, so long as it's defined as a Spot swatch, it's not going to affect its printed color. Objects assigned that color are simply going to be associated with the additional grayscale color-separation by that name. Consider the context of a Spot metallic ink: No combination of RGB values are going to enable your monitor to look anything even close to a translucent physical ink that has reflective metallic powder in it. That, in fact, is one of the main reasons Spot Inks even exist. But that doesn't matter one whit. You can select 'Pantone Metallic 8007' from a 'library' list in the software, or you can just set a new swatch that you've set as Spot and then 'mix' your own on-screen display of it. No matter how you try, you're not going to make it look like the actual copper-ish metallic ink that the pressman loads. All that matters is that the 'swatch' is defined as Spot, and is named 'Pantone Metallic 8007', so that's how the associated grayscale film or plate will be labeled when printed as color-separations. This is why I (and no doubt countless others) routinely simply define a commonly-used Pantone spot ink (e.g.; PMS 185) using my own display values (100y 100m), instead of Pantone's library recommendations. It doesn't make one bit of difference in the printed results. The pressman is simply going to load Pantone 185 ink into the inkwell because that's the name of the color-separation plate. When working for print--and especially when working with Spot colors--much confusion is avoided by always thinking in terms of inks, instead of 'colors.' JET
  24. This is competitive low-hanging fruit if there ever was such. Obviously, transformations (scale, rotate, skew, translate) should of course be relative to the artwork in-progress. But we've been so conditioned to the tyrannical vertical-horizontal fixation of nearly every feature of this genre of drawing programs that the obvious is overlooked, even by the users. Think about it: It's almost as if drawing software UI developers think 2D doesn't stand for "two dimensions", but merely 'two directions.' A precious few 'escapes' --features such as snap-to angled guides and rotated grids--have appeared over the decades. Some attempts are better than others. But they all fall short. I've been at this vector-based illustration thing since FreeHand 1. Believe me, I know what the cumbersome workarounds are. Thus the feature request. Exactly. That's the problem. And the low-hanging fruit. As I pointed out, Affinity does at least provide what Canvas has for decades: it can 'remember' the rotation of a selection. But unlike FreeHand and Illustrator, Affinity does not provide transform tools. It only provides its tactile (i.e., dragged-on-the-drawing) transform features as bounding-box handles. Well, any illustrator who doesn't just draw boxes needs to be able to perform translations in any direction relative to the artwork, not just to a rectangular bounding box. Illustrator provides both transform tools and bounding box transform handles. And it, too, rotates an object's bounding box when the object is rotated. Inkscape doesn't even do that. Inkscape's bounding box stays parallel to the page edges even when an object is rotated. FreeHand avoided continually cluttering the interface with bounding boxes. What most Illustrator users don't know is that FreeHand's transform tools were better than Illustrators in that they worked better (more powerfully and more controllable) when dragging at arbitrary angles. Again: Affinity provides a ridiculous five rotation handles on its bounding boxes, all of which do exactly the same thing. Honestly, who needs that? Meanwhile, try this: Select something. Show the Transform Anchor. Drag it to somewhere other than the selection's center. Now drag one of the scale handles. The Transform Anchor is ignored when scaling. To make drag-scaling act at least similar to what Illustrator's Scale Tool can do, you need to temporarily draw something else to serve as the 'transform anchor' and add it to the selection. Don't try to tell me Affinity's selection/transform interface doesn't still need work. But as always, Illustrator is hardly anything to which to aspire. like Affinity, its rotated bounding boxes also cannot be rotated about its selection in order to orient the transform handles to the direction in which the selection needs to be scaled. In fact, I don't know of any program in this competitive genre that empowers the user to re-orient the bounding box relative to the selection. It's time one did! It would 'transform' Affinity's scale handles from sub-par to superior in one elegant, unobtrusive functional enhancement. I don't want Affinity to be a cheap 'me, too' clone of Illustrator. I want it to become something better. Low hanging fruit. JET
  25. Fde, Please go back and re-read my post carefully. I'm well-aware of the Cycle Selection Box. I even pointed out that feature when I said: "Like Canvas, it does let you switch a rotated bounding box back to its as-created pagewise (vertical / horizontal) orientation" What I'm talking about is the ability to rotate the bounding box relative to the selection so as to thereby orient the bounding box's scale handles in a direction pertinent to the actual artwork. The point is to be able to scale a selection that is already rotated as needed in the direction that it needs to be scaled. JET
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.