Jump to content

JET_Affinity

Members
  • Content count

    310
  • Joined

  • Last visited

About JET_Affinity

  • Rank
    Advanced Member

Recent Profile Visitors

890 profile views
  1. I'm not saying modal dialogs are desirable if they are better avoided. I'm saying that Illustrator is replete with archaic modal dialogs, but even in spite of that, its transform tools still provide the greater functionality described and presents it more concisely. JET
  2. For decades, there was a common comeback whenever FreeHand users complained about Illustrator's cumbersome two separate selection tools (and their associated problems): Many, if not most, longtime AI users (including at least one of its developers) would claim to "never use the black pointer", but to always use the so-called "Direct Select Tool," as if doing that were some kind of indication of "greater expertise" with the program. I would always counter by pointing out that, in Illustrator, that would mean they never used the bounding boxes, which I would further demonstrate are useful for such things as scaling an ellipse by its major or minor diameters (assuming the BB remembers its original orientation). So again: Yes, there are many who eschew bounding boxes, and no, I am of course not opposed to a program having bounding boxes. I am opposed to on-page transformations being dependent upon them. The transform anchor can be set anywhere. With a transform tool, it can be set by merely clicking where you want it, without having to find an icon to click in a control bar to display it, and then dragging it to where you want it. And a typical rotate tool effectively provides you with a "rotation handle" located anywhere. How is that less convenient (let alone less powerful) than having to used one of five hot spots that aren't even located on what you usually want to snap to something else anyway? I mean any detail of any selection. Suppose that on the page you have a raster image of Orion, the cat, and a path with an arrowhead, which is already where it needs to be. You want to rotate the raster image by mousing down on the center of the jewel hanging from Orion's belt (the detail of interest) and dragging it such that the arrowhead would be pointing at the jewel. You can do that with a typical rotate tool in one move, and the bounding box of the raster image (and its various rotation hot spots) is completely immaterial to the desired move. So by "detail of the selection", I'm not just talking about the snap-sensitive subparts of vector paths, like nodes, although that is certainly one of the most obvious applications. I acknowledge and applaud that. But there's more. As I've said many time, I'll never consider Illustrator the default program to emulate. But with its fairly customary transform tools you can: Click to set a transformation center. Then mousedown and drag anywhere to perform the transformation. The tool is snap-sensitive. So if you mousedown on a node, you can drag the selection by that node and snap it to any snapping candidate, including candidates beyond the reach of the selection (thereby "aiming" the node you are dragging at that remote snapping candidate). The same transformation tool can be used exactly the same way on any current selection, be it whole paths, partial paths, raster images, symbols, clipping masks, text, or any other kind of construct. This is pretty much what the Affinity beta Point Transformation Tool does, except that in Illustrator, All of the various transformation tools (Scale, Rotate, Skew, Reflect) work the same way. So although there are several transform tools, that in itself is intuitive, and there is consistency in the interface. DoubleClick any of the transform tools opens a dialog for numeric entry of values appropriate to that tool, including the option to transform one or more duplicates of the selection instead of the original. (FreeHand was even better at this, because it did not disjoint a path at its unselected nodes during so-called "power duplication" of sub-selections. This empowered certain reiteritive transforms which Illustrator cannot do.) So yes, there are four icons in the toolbar, and I'm as opposed to "tool glut" as anyone. But this is more concise and tidier than having to select a tool, then traverse to an options bar to put it in some other "mode", click a series of other icons to set its other behavior details, and then finally mousedown and drag on the page. All that comprises more "tool glut" than four grouped transform icons in the primary toolbox. And there's more: I'm also not entirely crazy about modal dialogs. But in this case, they have the advantage of storing their respective last-used settings. This is powerfully useful for many things, and not just in conjunction with the Transform Again command; the last-used transformation performed by each tool can be recalled no matter how many other things you've done since, including changing the current selection. Just doubleClick the pertinent tool and tap Enter. If you can accommodate all that for all of the usual common types of transformations into a single transform tool, my hat's off to you (as it always is anyway). But in terms of intuitive, powerful, and easily discoverable interface design, there may be good reason why mainstream drawing programs have gravitated toward toolbox tools for performing tactile transformations. JET
  3. Oh, c'mon, guys. "Having" bounding boxes is not the problem. I fully understand their utility. The problem is having on-page transformations dependent upon them, in lieu of proper (and cleanly implemented) transform tools. That is substandard. The core problem is very simple: You can put any number of superfluous "handles" or "hot spots" along or near the edges of a bounding box and they all still have the same problem: They are not located on the details you are manipulating. To use them for transformations, you mouse down somewhere else. That fails to clarify what you actually want to drag and snap to something else. Users struggled with this and couched their complaints in terms of needing to transform sub-selections. So the awkward Transform Mode of the Node Tool (already an unintuitive interface approach) was added. But alarmingly, that committed the very same core fallacy. It also is dependent upon silly bounding box handles for transformations of sub-path elements. To ostensibly provide "direct" and "accurate" manipulation of details of paths, you again require dragging something other than what you are actually manipulating?! What other program does that? So next, the awkwardly named Point Transform Tool is added. It has a few subtle innovative behaviors which I like. But it has the same problem that gave rise to the demand for the Transform Mode of the Node tool; inability to manipulate sub-selections. I'm as opposed to unnecessary "tool glut" as anyone. But now, evidently in order to avoid adding conventional transform tools, we have two awkward and rather unintuitive feature sets which, combined, still fall short of the functionality more directly and economically provided by (much as it pains me to say it) the conventional transform tools in Adobe Illustrator. As it stand right now, we have less functionality with more interface clutter, requiring more clicks. And I'm still waiting for someone to explain why one needs five rotation handles on every bounding box. JET
  4. And, unless I'm missing something, doesn't work on a subselection of nodes. Typical transform tools work the same way on current selections of any kind. Why do we need both a special "Point Selection Tool" and the separate and cumbersome Transform Mode of the Node Tool? I'm sorry, but this is not interface elegance. It feels like afterthought scattered functionality just to stay married to the infernal bounding box fixation. JET
  5. Bah, it is merely visual clutter. If I'm going to rotate a tiny object by dragging it, I'm going to zoom in, so I can see what I'm doing with at least some measure of accuracy. Dragging a handle that isn't even located anywhere on the object nor even on its bounding box is superfluous junk. I've got along fine without it for about 35 years. I think it's a mere accommodation to finger painting on a mobile touchscreen with one's blunt thumbs and digits; an inappropriate interface and something I do not want when doing serious illustration on a proper desktop. A well-implemented rotation tool, on the other hand, lets you mousedown literally anywhere to rotate a selection about its transformation center–which it can also set anywhere–without switching tools, while abiding by all snaps both upon mousedown and during drag, and regardless of zoom. I know how the BB handles work, RC-R. There are four other rotation handles on the BB. JET
  6. I have big problems with any program that requires dragging stupid bounding box handles for all its on-page transformations. Like you, I have no use for the countless situations in which the default bounding box doesn't even reflect the actual bounds or dimensions of the paths. (And while I'm at it, I despise the current fad for those stupid rotation lollypops. Why does one need four, let alone five handles for rotating a bounding box?) Example: Draw a square. Draw a circle inscribed in the square. Rotate the circle 45 degrees. Group the two paths. Rotate the Group 45 degrees. The resulting bounding box and its dimensions are utterly useless, reflecting the bounds of the corners of the rotated circle's bounding box, and enclosing a bunch of white space. Cycling the bounding box, the unwanted bounding box is still displayed and looks like an object that isn't even there. That's a hideous interface treatment. But let's not throw out the baby with the bath water. The ability to retain and recall a bounding box that has undergone some rotations can be quite useful, as in the common case of needing to scale a rotated ellipse by its major or minor diameter. It's not that object's being able to remember and recall their rotations "makes no sense." That ability is one of the historic advantages of, for example, Deneba Canvas. And it is also potentially advantageous over Adobe Illustrator, which often "loses" that information when you need it. It's just that the current treatment in Affinity's interface needs some serious work. Yes, making a reset of the bounding box permanent should be possible (and not require a goofy workaround), but optional. JET
  7. Just by way of explanation… Have you ever wondered why isometric drawing can be done with a single grid, but any other orientation (dimetric or trimetric) requires three grids? That's because, by definition, all three axes in isometric are equally foreshortened. The same measuring scale works for all three. So in effect, "all three grids" and their increments are superimposed precisely on top of each other in an isometric orientation…but not in any other. That's one of the problems inherent to grids-based approaches to axonometric drawing. In your example, you've drawn a square on one grid. The other two perpendicular grids don't know which corner of that square you currently consider "the origin." Continually moving the artwork as in your screen clip is, of course, unacceptable. So using grids, you have to be able to continually "reset" the origin to whatever point of the drawing you at the moment consider the "origin" of your next measure. Doing that needs to be as fluid and instant and natural as possible. Since emulating pre-computer physical media is usually the goal of user interface design, It needs to be at least as fluid and instant and natural as it was before computers. But it's not. In the pre-computer days of productive isometric drawing "on the board," there were no "grids" on our drafting tables. There were (appropriately) just axes. (It's not called axonometric drawing for nothing.) The "axes" were the ruler scale(s) attached to the head of the track drafter, which you held in the palm of your left hand (if you were right-handed), and thereby fluidly glided to any point of interest in the drawing while maintaining the same angle. The illustrator effectively and intuitively "zeroed" the origin of the appropriate axis each time he started a new measure, pretty much without even thinking about it. Grids just don't emulate that very well. For flat graphic page design, a designer cares about the orientation of a spacing grid relative to some corner of the page. But for illustration, an illustrator doesn't care one whit about the "origin" of a grid relative to some corner of the page; his measures are made along the angles represented by the grids, but must be zeroed at any current point of interest in the drawing. (I don't have Affinity installed on this machine, so I'll leave it to someone else to tell you how to do that.) JET
  8. Agree. EVERY vector based drawing program should provide for user-defined ruler scales. There is no need for any CAD related "apologies." User-defined drawing scale is just as basic to general-purpose illustration for print, signage design, whatever. I've been saying this for decades. And it's yet another no-brainer, low-hanging-fruit opportunity to exceed the archaic functionality of Adobe Illustrator. JET
  9. Believe me, I understand the need and the concept. But let's not set our sights too low. As far as programmatic selection features, I will never be satisfied until I see something at least match the elegance and power of Macromedia FreeHand's Graphic Find & Replace palette, which did far more than Illustrator's anemic Select Same commands and far more than you describe. It could find user-specified combinations of attributes and, when appropriate, within user-defined ranges. And not just styling attributes. The list of combined possibilities would be very long to list, so by just one example: Beyond finding mere stroke weight, it could select path lengths within a user-specified range. Much of the time and tedium I spent writing Javascripts for Illustrator was to make poor-man's substitutes for some of the functions for which I most often employed FreeHand's GF&R. But frankly, I think "global swatches" is the more appropriate way to do this. Again, I'll refer to FreeHand. To users first accustomed to FreeHand, Illustrator's whole "Global Swatch" thing was just one of many needless stumbling blocks. In FreeHand, every Color Swatch which the user took the time to store in the Swatch Palette was functionally "global." And why wouldn't it be? Why would I ever want to define and name a Swatch that I could not use to programmatically update objects to which it is already applied? FreeHand's treatment of this gently but effectively enforced a much needed measure of organizational discipline as the user worked. Knowing that Swatch edits updated objects to which it was applied, intuitively trains the users to define a differently named Swatch (even if it was of the same color values as other Swatches) for objects which should, for any reason, be treated separately in terms of color. That's a simple matter of duplicating a Swatch and changing its name. This largely prevented the common beginners' bad practice of just applying colors willy-nilly, and then wishing they hadn't later. JET
  10. You would just create the offsets by sequentially specifying strokes of those weights, aligning the strokes to the appropriate sides of the path (or just leave them centered and use twice the width). Cut and delete the portions not needed. Clean up the necessary joins at the corners. You'd similarly have to do multiple offset commands, even in other drawing programs like Illustrator. Typical offset path commands don't let you specify distances from a single path on a per-side basis, because the original path could be of any shape, so a "side" is a matter of interpretation. Illustrator has a feature that lets you set different "stroke widths" wherever you want along a path, but that's more intended for a variable "brushstroke" effect than for something that would maintain, for example, a continuous width along a portion of a curve. Affinity provides similar "brushstroke" functionality in the Pressure dialog, not directly on-the-path. JET
  11. I won't. And I doubt that Serif is offended by my saying that, because... Serif is changing the 2D graphics game in many ways, a large part of which is cost and value. That in itself is a long overdue aspect of innovation in this software segment. I've long held that the historic "big four" of the 2D vector graphics world (Illustrator, CorelDRAW, Canvas, FreeHand) are grossly overpriced for what they are. Their vendors desperately cling to an outdated pricing model that stems from the heady days when it was all a major paradigm shift. But that was almost four decades ago. I see Adobe's take-it-or-leave-it subscription licensing scheme as a manifestation of that desperation. Many product categories enjoy "they'll pay anything" pricing when new technology disrupts whole industries. But fervor settles as the new way become the new standard. I remember paying $650 for the first HP color inkjet DeskWriter. That's CMY. No K. Competition is what gets prices back in line, and 2D graphics, much as we love it, is not rocket science anymore. Goliaths do fall when they can't conform to the times. Serif seems to know what it's doing in more than just coding very promising software. JET
  12. Not sure I'm understanding the seam allowances, but I suspect that's addressable by keeping in mind: You can set the stroke's alignment to centered, inside, or outside before expanding it. So that should be useful for specifying an offset distance on either side of the base path. After expanding the stroke and releasing the compound as mentioned above, you now have two separate paths. So you can repeat the process for either of those paths: Give either of them a thick stroke Set it to centered, inside, or outside Expand the Stroke Divide Using Expand Stroke for this is, of course, what I'm confident will be just a temporary workaround until Affinity acquires a proper Offset Path or Contour feature or a more fully-featured implementation of vector Brushes. It's just an educated guess, but I rather suspect that one reason such features have not yet been added is because the developers are aware of the problem that an inelegant number of nodes are created whenever paths are expanded and Brush paths are converted to outlines. (A problem I've seen in early releases of other programs, too.) I assume they are closely related functions. That's what I sometimes refer to as multiple similar features probably sharing the same functional "foundation" when impatient users complain about what seems an obvious feature "omission." I'm confident the Affinity devs intend to get the underlying foundations optimized before building a bunch of features onto them, and applaud them for that. By the same token, for example, I'm confident the devs are aware that the result of Expand Stroke on a closed path results in a compound path, and therefore the Release Compound command should work on them instead of using the Divide Boolean button. But presently, Release Compound is grayed out after using Expand Stroke on a closed path. Affinity Designer is still very much a work-in-progress. But it's a game-changing bargain for what it already delivers and so far, we're not being charged for significant improvements between integer updates, such as those presently being developed toward the 1.7 release. For the price of the Affinity apps, we're getting a lot of value. So I have no problem cutting the development program some slack as the applications continue toward a more full-featured state. JET
  13. AffinityBrah, After Expand Stroke and flipping the Fill and Stroke: Select the black pointer. Click the Divide button in the control panel. This releases the compounding of the two paths. Now you have two individual parallel paths that you can style as desired. JET
  14. Especially when trying to develop something innovative as opposed to just more "me, too; same ol' same ol'", solid foundations have to be laid for what users consider "basic things." I have plenty of "me, too" programs. I don't need another one. If all I were seeing in Affinity were just another "me, too" approach, I'd just yawn. Who's not "letting" you? Fact is, B13eL's post that started this thread was just a useless, unproductive rant. It doesn't even mention any capabilities he's (she's?) so upset about. And your "fanboy" nonsense is just a childish insult to fellow users who don't agree with you. No one "prevented" either. And no one is prevented from disagreeing with them. Resorting to ad hominem insult is a dead giveaway of weak argument; and a sure way to lose respect. JET
  15. Paul, It sounds like you are looking for what is usually called an "offset path" command or a "contour" command or tool for vector paths, to create paths that are offset from existing paths, but parallel to them. Does that sound right? JET
×