Jump to content


  • Content count

  • Joined

  • Last visited

About JET_Affinity

  • Rank
    Advanced Member

Recent Profile Visitors

822 profile views
  1. JET_Affinity

    Pencil tool. Invisible lines.

    If it were irrelevant, why would I be drawing it? You need think no further than the simple situation of intending to freehand draw a closed path. You don't think you'd want to be able to see where you started, let alone how you've weaved around and between other pre-existing objects? Sorry, Garry, but this is a no-brainer. Any freehand drawing tool should visibly trace the typical bitmap preview of the resulting path as it's being dragged. JET
  2. JET_Affinity

    Pencil tool. Invisible lines.

    Garry, the issue is clearly depicted in Max N's first post. He is talking about seeing the path he is drawing with the Pencil Tool being previewed even if the current fill, stroke settings are none, and he contrasts it with the {expected) preview behavior of the Bezier Pen. Again; preview of the shape you are dragging with a Pencil too—even if unpainted—is standard fare. In principle, it's the same thing as dragging with a Lasso Tool to make a freeform selection marquee. JET
  3. JET_Affinity

    Pencil tool. Invisible lines.

    Of course the tool should display its path as dragged, as in most every other program with a similar tool. By the same rationale, as soon as you mouseup after creating the path, it would be selected. You would expect it to be displayed so long as it is selected, regardless of whether it is painted. JET
  4. JET_Affinity

    Bounding Box Based Transforms

    Thanks, MEB. I'll give that a try next chance I get. I've just been running the installer with each Beta release, and leaving things as they are. I've assumed that results in a default configuration, since every time I have to turn off the dark interface. JET
  5. JET_Affinity

    Bounding Box Based Transforms

    Yes, I remember your mentioning that, and have been watching for it. But had figured it had slipped in priority, seeing nothing on it. I'll certainly be exploring that, now that I know it's there. JET
  6. JET_Affinity

    Bounding Box Based Transforms

    Well, dang! That is encouraging. Thanks for that. I was able to invoke it with the shortcut you provided, but on neither my primary desktop machine nor my Surface Pro is anything nested with the Node Tool. JET
  7. I am becoming increasingly concerned about what I consider the most debilitating aspect of Affinity Designer's drawing interface: Its dependency upon bounding boxes for all on-page transforms, especially rotations. This is downright amateurish in comparison to tools-based transforms. The functionality depicted below is from Illustrator. The same thing can be done in Corel Draw. It's a procedure I use everyday, all-day. The exact use case could be anything. Be it a loosey-goosey cartoon, a portrait, a product label, a photo-realistic drawing of a motorcycle, or anything in between, the argument is valid for any kind of serious illustration work: In most cases, bounding box handles simply do not correspond to the details of interest when performing snap-sensing on-page transforms directly and intuitively with the mouse. Related concerns: Like Illustrator and all the other programs that copy-cat it, Affinity Designer has modeled its interface upon the despised, but now conventional wisdom, "necessity" for two separate and distinct primary selection tools. (Despised, that is, by me and many others who remember the functionally superior single selection tool of FreeHand.) But even accepting that as a battle lost, these concerns make matters even worse in Affinity: Selection: A path selected by the black pointer is selected as a whole; i.e., it is selected at the object level. Per conventional treatment, doubleClicking is the shortest shortcut to putting the path in "edit mode." So here's the issue: By what logic does doubleClicking the path to put it in "edit mode" effectively deselect all of its nodes? Of what use is that selection state? The program should not assume that I want to manipulate a sub-set of the nodes, especially given that I cannot even use the black pointer to drag a path by one of its nodes, as I can in other programs that let me turn off the infernal, visually cluttering, omnipresent bounding boxes. A selected path is selected as a whole. DoubleClicking it should therefore initially have all of its nodes selected, not none of them. That way, it is at least ready for the user to simply mousedown on a particular node to drag the whole path by that node, and snap it to any snapping candidate within pick distance. Pen Tool: Turn on Line Mode. Draw a diagonal path. Now tell me: What is the length of that path? At what angle was it drawn? With the bounding box failing the job, knowing that, I could at least use the Transform panel to rotate something else to that exact angle? But about that other object: How can I determine the present angle of the portion of it that I need to rotate so that I know how far to rotate it? Again, in Affinity, dimensional information about a selected path is limited to that of the mere bounding box, which is usually of no interest whatsoever when drawing as opposed to merely designing a page layout. Every serious drawing program needs to provide access to the length (along with other geometric information) of a path. Getting the exact angle of a single-segment straight path should not be limited to the orientation of its bounding box, just because it was initially drawn diagonally when a diagonal line is what was needed. Such omissions effectively nullify Affinity's other accuracy-based advantages. What good is it for me to be able to scale a path by the cosine of another path's angle, when I don't know and can't determine what that angle is? How can I determine how foreshortened a straight line is, when I can't measure its on-page length? In Illustrator, one can at least determine both the length and angle of any measure by quickly drawing a single segment path with the Line Tool, deleting it, and then clicking the page to invoke its modal dialog, which then displays the length and angle of the last-drawn "line." (The other LBO tools can be exploited similarly). Elegant? No, such measures should obviously be provided by its functionally lame Measure Tool. But at least the needed functionality is there. Yet another low-hanging fruit obvious example of opportunity to surpass Illustrator, rather than falling short of it. In Illustrator, one can at least open the Document Info palette, put it in Selection and Object mode, and see the length of a selected path, its number of nodes, whether it is open or closed, and more. Again: elegant? No. Low hanging fruit? You betcha. If we must have these omnipresent, cluttering bounding boxes, by what logic am I disallowed from permanently re-setting them? The program should not assume I am always and forever interested in transforming the object relative to the orientation of its bounding box as originally drawn. Imagine any arbitrarily-shaped path. An illustrator creates countless ones in the course of any style illustration. The final orientation of that path usually has nothing at all to do with its orientation to the page as it was originally drawn. What's important is its orientation to the rest of the drawing. I get really tired of having to "cycle" the selection box when I am no longer interested in the original orientation. Let me at least reset the bounding box to the current orientation to which I have purposely moved it, as I can do in competing drawing programs. Don't require me to forever temporarily reset the bounding box each and every time I want to use a bounding box based transform after the path was originally drawn. If you want to do something beyond what competing programs do, consider providing the ability to rotate the bounding box itself to change the orientation of its transforms without rotating its object. Clutter. A selection can already be rotated by no less than four bounding box handles (near its corners), all of which do the exact same thing. What is the need for the visual clutter of a fifth handle (the massive rotation lollypop)? I'm not doing precision illustration with my blunt finger tip. I'm working on the desktop, not on a cell phone. Provide a preference to turn off display of that kindergarten handle. As others have mentioned, by what logic does the rotation center button disappear when in "Transform Mode"? That's when I need it most. "Snap all selected nodes when dragging" seems to be a misnomer. It doesn't work in Transform Mode when rotating by dragging. I'm sorry for the obvious frustration. Despite its other advantages, Affinity is sub-standard until this stuff is addressed. I understand and champion guarding interface elegance. But it seems that additional "mode" buttons (which annoyingly appear, disappear, and shift around when needed) are being added just to avoid adding what's really needed: Well-designed transform TOOLs in the toolbox. JET
  8. JET_Affinity

    Thanks for arrowheads but...

    Not meaning to "pile on," but trusting that the driving goal of Affinity development is to advance beyond standard-fare, rather than merely mimic it in "me, too" fashion: Path ends and Symbols (and vector brushes and any and all other features which source a preexisting vector graphic from any kind of library) should all be accompanied by a user-choice toggle controlling whether scaling the source art element also scales its as-created stroke weights. Just another golden opportunity which I hope will not be overlooked to rise above the inconsistency of Adobe Illustrator and other long-in-the-tooth programs. JET
  9. JET_Affinity

    Thanks for arrowheads but...

    Having only just now downloaded the .256 Beta, I won't have opportunity to play with it until this evening. But just based on what I see in user screenshots: Scale of path ends (arrowheads) should be independent of stroke weight. The importance of this should be obvious if or when support for user defined path ends is provided (hopefully incorporated with Symbols). Position of path ends should be infinitely adjustable (i.e., not just limited to inboard and outboard of the end nodes). Very common example is needing a ball end to be centered on the path ( with snapping) or object it is referencing in a callout. JET
  10. JET_Affinity

    "Add" key joining shapes

    For what it's worth, I actually prefer for Boolean operations to require closed paths, or at least filled paths. It's more intuitive, especially for newcomers. I've seen confusion caused by this among beginner users of Illustrator for decades. JET
  11. That's because when selecting and moving a node of the rectangle, that's all you're doing: You're simply moving a node of a single path. That's normal. In this case, that path is actually a sub-path of a compound path. But by selecting one of its nodes, you are still just editing that one sub-path. You are expecting the move to reshape the whole compound path (all of its subpaths). That requires some kind of "envelope" feature, which Affinity Designer does not yet have. It is on the list of features planned to be added later. JET
  12. ?? Begging your pardon, Mark, but quite often my purposes for resetting a bounding box is to permanently reorient the selection to its current state. I dare say you'll have the same argument with decades of Illustrator users, because that program's Reset Bounding Box command is used all the time and it is only permanent; it can't be "restored" to the orientation in which the object was originally created (unless, of course, you reverse the transformation(s) performed and then Reset Bounding Box again). The "extra space" bounds which Wickster illustrates is also a stumbling block, (and I don't mean in the context of live text). Yes, I appreciate that Affinity is able to "remember" its untransformed orientation. But it's just as common to need the object to forget its original orientation, and thereafter treat its new orientation as normal. JET
  13. Okay. You have one. Continue using Illustrator (or any of several other programs). As for me, I'm looking for something better from a new built-from-the-ground-up program; not just more copycat "me, too" functionality. Again: Warping / enveloping is on the published to-do list. Serif has acknowledged the need and openly stated it is in the plans. So what is all the ranting about? You really think this is just a "who screams the loudest" contest and that improvements to a program automatically jump to the top of the list according to that? No, features often necessarily depend upon a foundation laid by other features, or have to serve as part of the foundation of other planned features; especially when the goal is to dare go beyond conventional wisdom and standard-fare. Moreover, as in any "popularity-driven" scenario, the "majority" quite often gets it wrong when it comes to what's deal-breakingly "most important." Most every pet feature request is couched in those grossly exaggerated terms. Simple mob rule is no way to methodically advance anything. A mere emulation of Illustrator's problematic Free Transform Tool is way down my list. Yes, provision for vector-based warping is pretty standard-fare nowadays. But other things (all routine ordinary on-page transformations presently being bounding box dependent in the first place) are far more fundamentally important in that they form a usability foundation for the whole program. JET
  14. Hotly argued? Where? I've not seen any contention (least of all from Serif) over whether the program needs a good offset path command and better results from expanding strokes (which I suspect are functionally closely-related ). Where has Serif ever said this is not needed or not planned? What I have seen are equally poor implementations of the function in early versions of other drawing programs. That leads me to suspect it may not be as simple as end users assume. And it's no more foundational than other presently missing but equally-common features. Path blends, for one example, is just as standard-fare. On the other hand, check how many decades it took for Adobe Illustrator to provide any kind of live shape primitives, something ubiquitous to even "office" or "works" programs. Or a "page 2." (All the while, that program's devotees continuously proclaiming it the "industry leader," the "de facto standard," the "professional" drawing program, ad nauseam.) Does anyone really think the Affinity development team does not fully intend to improve its offset path functionality? Does anyone really think they are going to convince the Team to immediately drop everything they're doing and get to work on their specific "most important" deal-breaking feature? It's a development process. It's a plan. It has to be. We end users are not privy to the reasons why things have to be implemented in a certain order. It's not a simple matter of who whines (no g) the loudest. It's why it's still version 1.x and why we're not being charged additionally for the many improvements that are being implemented in every dot release. JET