Jump to content

JET_Affinity

Members
  • Posts

    532
  • Joined

  • Last visited

Recent Profile Visitors

4,160 profile views
  1. The pity is that the vast majority of even longtime highly skilled and successful vector illustrators have never touched a font design program, and frankly—no offense intended—therefore don't know what they are missing. I get that. I understand being busy. But anyone serious in this business would do well to download a demo trial copy of FontLab, if available, and spend some time exploring the Bezier drawing interface. I am so thankful that my first exposure to Bezier-based drawing was in Altsys Fontographer {the progenitor of Aldus FreeHand). JET
  2. Like baoyu said, I would certainly expect the new scripting API feature to be major enough to justify the next pay-for major release. I'd be quite willing to pay for upgrading to the new version of all three apps. Regarding fde101's concerns: I completely disagree with the assumption that 'casual users' would "write off" the scripting feature, whether they are ready to write scripts themselves or not. Just look at Inkscape's Extensions menu. That effectively is Inkscape's built-in scripting implementation. But it doesn't just empower scripting users. A long list of Extensions are included with the standard download of Inkscape, and any user can pick and choose from hundreds of additional free Extensions that are created by other users. Inkscape would be far less capable to all of its users without its Extensions. Prior to Adobe's Captive Customers rip-off licensing, I built a considerable number of Illustrator scripts in its Javascript-based scripting environment. But I've only just very recently started dinking around with Inkscape's Python-based extensions. That certainly didn't keep me from having Inkscape on-hand and using its Extensions for many years. Again, Inkscape would be far less capable to all of its users without its Extensions. I would certainly be surprised if the first release of Affinity's scripting didn't come with a broadly-useful set of pre-built ready-to-use scripts that demonstrate its power and potential. Many users in this forum have pined for Serif to implement support for commercial 'plug-ins'. I consider that approach to adding bespoke features archaic, passe', inflexible, and needlessly costly. Providing a well-done scripting API has far more potential. Scripting users will no doubt be sharing the scripts they create with other users, either for free or for a small price. Another misconception (I think; corrections welcome) evidenced in this thread is the notion that a program that has a scripting API has to have some kind of explicit built-in 'support for AI' in order to use an AI Chat to help writing scripts for it. I'm no programmer and don't play one on the internet. But as I understand it, AI Chats fetch from whatever is 'out there' on the subject. While Inkscape 1.4 came out late last year, you can still get help from an AI Chat about writing Extensions for Inkscape, and it can even return fully-functional Extension scripts that work in earlier versions. Sure, new versions of software (for example, FileMaker Pro) are scrambling to add AI-centric access to AI from within the program's standard interface. That doesn't mean I can't use AI Chat to assist in building a complicated relational database structure in an earlier version of FileMaker. JET
  3. Affinity Designer does not have a raster image auto-tracing feature. If you search for the topic in the forums, you'll find discussions about it. JET
  4. 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
  5. 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
  6. 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
  7. 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
  8. Smart Mode, not 'smart nodes'. Also turn on Rubber Band Mode to preview the next segment. JET
  9. 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
  10. "…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.
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
×
×
  • 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.