Jump to content


  • Content count

  • Joined

  • Last visited

About JET_Affinity

  • Rank
    Advanced Member

Recent Profile Visitors

590 profile views
  1. JET_Affinity

    Real vector brushes

    I'm not an insider; just a user like you. But I certainly assume that vector based "brushes" (i.e., ability to stretch, repeat, or blend vector objects along paths) are planned. However, I would just as strongly think it unrealistic to expect a reverse-engineering of Adobe Illustrator's specific treatments of "brushes". So I'd expect any ability to directly import Illustrators' brushes as still-live constructs to be just as unlikely for Affinity as it is for any other competitive drawing program. Corel Draw, Canvas, etc., can't directly import Illustrator brushes, either, just as Illustrator can't directly import working copies of proprietary constructs in those programs and just as Illustrator can't directly import Affinity's raster-based brushes. Nor would I even want that. Illustrator's vector-based brushes are one of its few truly differentiating features, and I even dare say I use them more elaborately than most users do. But that doesn't mean it can't be done better. Illustrator's Art, Scatter, and Pattern Brushes are full of unnecessary limitations and they are too "standalone" in nature; "ignorant" of other Illustrator functionality that should be integrated with them. Think about it: Such a feature ties in with a lot of other more foundational functionality (path strokes, fills, ends, Symbols, envelope distortion…). Affinity is still only approaching version 2, and its functional foundation (like transformations) is still very much under development. To build something better than standard fare, you don't put the cart before the horse, just to be able to claim "me, too." JET
  2. For those not familiar, the behavior result that Rudolphus is depicting here… …is reminiscent of FreeHand. Unlike most drawing programs, FreeHand did not just provide two node types ("smooth" and "cusp" or "corner" and "curve"). It also provided a third node type called a "Connector Point." A Connector Point was a node with just one handle, the length of which affected the curvature of the next (outgoing) segment. But that single handle always maintained tangency with the end of the preceding (incoming) segment. Its purpose was to always ensure perfect tangency between a straight segment and a curved segment, no matter what you subsequently did to those adjacent segments. Particularly important in drawing font glyphs, but just as useful in accurate general illustration. Most vector illustrators are not even aware of it, because it was never a feature of Illustrator. So the behavior which Rudolphus is suggesting could be useful for the same purpose. But since Affinity also only provides the two most common types of nodes, the tangency would not be maintained if the two associated segments are thereafter altered. The node is still just an ordinary smooth node with one handle retracted. But it would be a great thing if the concept of FreeHand's Connector Point were "resurrected" in a modern drawing program. It's just one of many "long lost" superiorities of that program. JET
  3. Version Rectangle Tool: Drag to draw a rectangle. Transform palette: Proportional link off. Key "Sqrt(2)" into W field. Tap Enter key. Nothing happens. JET
  4. JET_Affinity

    Simple Rotation

    Thanks for the interest, Ben. Tactile transformations (with the mouse) really are deal-breakingly important. It makes all the difference between drawing accurately as opposed to having to merely "eyeball" things. Some programs (those without dedicated Transform Tools in the toolbox) do it when the bounding box is visible (as in the Corel screenshot in my previous post), but they don't require you to mousedown on the rotate handles of the bounding; they let you mousedown on any node or edge with full snapping ability for all candidates. When doing serious illustration, the object(s) you are rotating (including groups, symbols, sub-selections of nodes of single or multiple paths) are all kinds of shapes, and the detail you are interested in snapping into rotation alignment with other objects edges (and not necessarily straight edges) or guides have nothing at all to do with the locations of any of the bounding box handles. So in most situations, the bounding box is immaterial and just makes for annoying visual clutter. Other programs (Illustrator, FreeHand) do provide dedicated Transform Tools. This is far cleaner, more consistent, and more intuitive to use, because they work the same regardless of the selection; whole objects, sub-selected partial paths, or combinations of both, and show no unnecessary bounding box that is totally unrelated to what one is trying to do. That's the huge advantage to having actual Transform Tools in the toolbox as opposed to merely having transform handles on a bounding box. There are multiple important subtleties involved. For example, In Illustrator, when you mousedown on the node to be dragged, that node becomes the snapping object of interest, even if while dragging, the cursor moves off that node. That enables you to, for example, snap that node into rotational alignment with object edges which are shorter or longer than the radius of the node's rotation. A simpler, but just as important behavior detail intimately related is the mere matter of what happens when you switch tools. In Affinity, when you move a path with the Move Tool, and then simply switch to the Node tool, or doubleClick the path to invoke the Node Tool, all the nodes are indicated, but none are selected. This is maddeningly annoying when your purpose for switching to the Node Tool in the first place is to drag the whole path by one of its nodes so as to snap it somewhere, even for mere translations, let alone rotations or other transformations. When you select something with the Move Tool, the selection is selected as a whole. Therefore, while it is still selected and you switch to the Node tool, it should still be selected as a whole (all of its nodes selected). There is no justification for changing the selection just because you switched to the other selection tool. And by what rationale should the transform anchor disappear when the Node Tool is selected; even when in it's "transform mode"? One would expect to at least be able to perform the accurate rotation numerically as a tedious workaround. But that's frustrated by the matter of not being able to know or measure the angle of a straight segment that was originally drawn diagonally, as opposed to being first drawn horizontally or vertically and then rotated. There's no measure tool, and that omnipresent bounding box doesn't know didly about the angle at which the line was drawn. (This problem, of course, pertains to angles between any two coordinates; not just straight single-segment paths.) And really, it's not just about rotation. Skewing and reflecting should also be possible to do with the mouse while snapping along other guides, pathGuides, or unselected objects at any arbitrary angle (as could Freehand), but rotation is the real deal breaker here. JET
  5. JET_Affinity

    Simple Rotation

    Hi, Ben. It certainly does need work, and I was sure hoping to see it addressed before the release of 1.7. This is something that mainstream drawing programs do. One obvious and very common use case is the one I depicted: The need to align the minor diameter of any ellipse (i.e., any foreshortened circle) to its thrust line (i.e., its axis; the perpendicular line about which it "orbits"). This is a fundamental principle of any kind of realistic illustration, and not just in axonometric, but in converging perspective as well. And it's not just about aligning ellipses with their thrust lines. The need to rotate with reliable snaps when dragging by a node is very commonly needed in countless general drawing and design situations. Having rotation with reliable and accurate snapping based only on bounding boxes is sub-standard. Couple of quick screenshots from Illustrator and CorelDRAW:
  6. JET_Affinity

    Simple Rotation

    What am I missing? JET
  7. All this discussion buttresses my point, which I clearly stated: We users have no idea how a decision by Serif to make Affinity core functionally dependent upon back-end licensing of code from a third-party plug-in developer would affect us and the future and marketing direction of the product. And end users are effectively being urged to back that licensing — by that third-party developer—in a Serif user forum. (Try doing that on, say, Adobe's forum.) There are sound reasons why it's illegal to campaign within a certain proximity of the voting booth. Yes, I'm familiar with the product. I don't buy it for the reasons I already explained re avoidance of my own dependency upon third-party add-ons. Sure, I'd like to see whatever I consider better functionality or interface approach in whatever drawing program I license, regardless of where I see it. I like, for example, some of the new wrinkle interface stuff I see for path manipulation in FontLab. That doesn't mean I want Serif to license that interface from FontLab and pass the cost on to me. For another example, the very best thing any object-based graphics program could do is re-map the entire interface onto the object inspector concept, as FreeHand did many years ago. That certainly doesn't mean I'm going to become a volunteer campaign worker to urge Serif to license that idea from Adobe just because it now owns FreeHand's code. JET
  8. JET_Affinity


    Sounds to me like you're just talking about a proper implementation of graphic styles, in which an "Update From Selection" command (or drag & drop) is provided so that existing objects to which that style is applied update accordingly. And inclusion of the ability to use stored graphic styles as one of the criteria in a proper find & replace feature. JET
  9. Rather inappropriate for you to be self-servingly pushing your software sale here. But all IMHO, of course. JET
  10. I learned early-on to avoid dependency upon third-party add-ons like the plague. I consider the whole long-promised "plug-in panacea" model largely a failure. Countless such extensions from relatively small companies have come and gone over the decades. The more elaborate ones often cost half again as much as the host program. Being standalone, they lack functional integration with native features, over-clutter the interface, and chronically lag behind the host program's version changes. For users who are "married" to a single drawing program, simply buying a competitive side-grade to another program often costs less, gains a lot more for the money, broadens the user's versatility by acquiring hands-on familiarity with more than just one program, empowers them to have options when their "pet" primary program goes away (or becomes rent only) and gives them at least some validity when claiming to "compare" various programs. I understand the Astute Graphics thing is somewhat different, in that the third-party add-on developer is offering to license its code to the host programs' developers. But right now, none of us on the user side knows how that will actually translate to us or our wallets. So I do not just off-handedly advocate Serif's commitment to that kind of back-end deal without knowing how it would affect me as a customer and a user. I'd rather see Serif continue to develop its own proprietary, royalty-free code for drawing functionality using its own ingenuity. Who knows; they might be able to do it better. A scripting API is a whole other subject. That gives users willing to invest the time the ability to develop his own functional solutions which are integrated with the host program's native features, and over which he has full control. JET
  11. JET_Affinity

    [ADe] Show hidden characters

    I strongly agree that this needs to be in Designer, not just Publisher. It's just as important in a drawing program. (But they're not "special characters"; the command should just be "show invisibles.") (Another laughable Illustrator factoid: Did you know that (at lease as of CS6), you cannot search for and replace carriage returns?) JET
  12. I don't mean to hijack evtonic3's suggestion here (with which I basically agree), but it's a tiny part of a much larger issue, and Aammppaa's animation serves to exemplify it: In the animation clip, the transform anchor displays, and Aammppaa demonstrates dragging it to a snapping candidate. However tedious, that much Affinity can do. But forget that for a moment. The larger issue is that Aammppaa then still has to rotate the ellipse by the rotation handles of its bounding box. Now consider: See that single parameter handle that looks like a node on the edge of the live ellipse? Note that after the first rotation, that "node" is no longer aligned to a bounding box handle. But suppose that is the detail of the selection that Aammppaa needs to rotate into snapping alignment with, say, a pre-existing diagonal line behind the ellipse. How is he going to do that by dragging a bounding box handle? In this hypothetical situation, Aammppaa needs to: Set the transform anchor where desired. Mousedown on a node of the ellipse (or any other arbitrary path) with snapping accuracy. Rotate the selection by dragging that node until it accurately snaps into alignment with the diagonal line (or any other pre-existing snapping candidate in the whole drawing). You can't do that with Affinity's rotation interface. You have to drag the rotation by a bounding box rotation handle and just "eyeball" the actual alignment you need. Yet that kind of rotation is far more commonly needed in accurate illustration work than merely dragging bounding box handles to snap somewhere, because the bounding box handles most often don't even lie on the path(s) being rotated. They are most often not even relevant to the precise rotations needed. This is why other programs (Illustrator is one example) provide transform tools, not just a transform palette, and not just rotation handles on bounding boxes. Now, you don't have to provide a dedicated Rotate Tool to perform the kind of rotation I'm talking about if you just abhor the idea of adding another icon to the toolbox. A program can simply: Put the selection in its "transform mode" (i.e., do whatever results in its rotation handles appearing). Instead of grabbing a bounding box handle, mousedown on a node (or any other snapable detail of the selection). Drag, and while doing so, sense snapping candidates within proximity to the mouse (which may or may not still be over the node being dragged). Mouseup when on the desired snapping candidate. CorelDraw is one example of this treatment. But the same principle is also valid for other transformations; scaling, skewing, and even reflection. FreeHand enabled the user to perform all those transformation by setting the COT and then dragging the appropriate tool along any direction. So, for example, you could reflect a copy of a selection about an arbitrary diagonal line, or scale it diagonally in the direction of that line, etc. It's not that transformations based on bounding boxes are useless. Affinity's ability to basically forever retain the rotation value of paths throughout their manipulations can be an important technical advantage which few competing drawing programs provide. (Illustrator does this so erratically that it's of less use than it should be.) But Canvas, for example, does this by enabling the user to toggle back and forth between a selection's "transformed" versus its "untransformed" bounding box with a click on a button. (Affinity, as of yet, doesn't even allow a hard reset of the bounding box, which raises another whole set of related issues.) It's just that bounding box handles are usually useless for transforming details of one path into alignment with another path, which is something needed countless times every day in serious illustration. Having tactile transformations (those being performed by dragging with the mouse) and their associated snaps based only on bounding box handles is absolutely debilitating. It's the Achilles' heel of this program. It flies in the face of Affinity's otherwise emphasis on accuracy, and constitutes a very serious disadvantage in comparison to other drawing programs. JET
  13. JET_Affinity

    Network graphing tools please!

    Garry, as anyone can easily see by reading this thread, you have completely miss-characterized everything I said. I never presume to know what is "easy" for the Affinity develop team to implement. And everything I posted here is in direct context of the request for live connector paths, a common, appropriate, and very useful feature within mainstream drawing programs, and yet another embarrassingly missing from Adobe Illustrator, despite being long requested by its users. JET
  14. JET_Affinity

    Network graphing tools please!

    So you chimed in with your objection to Randall's suggestion because you don't want to discuss its merits? JET
  15. JET_Affinity

    Network graphing tools please!

    First, I completely disagree with your "single page" constraint. Back in the day, that was the knee-jerk outrage of Adobe Illustrator devotees whenever a FreeHand user dared suggest that many, if not most, illustration projects ( logo designs, business identity documents, projects destined for vinyl cutters and other NC machines, package designs, bottle labels, trade show displays, garment imprints, and countless other things) involved more than one sheet and that those sheets need to be independently sized and oriented. Try taking away that program's typically late-to-the-party multiple Artboards ability from the same naysayers today. So that aside, do you not consider "artwork and illustration" inclusive of, say, commercial product renderings (cutaways, phantom views, parts breakdowns, assembly instructions)? My toddler grandsons' animals books are all about illustrations and chock full of floating callouts. Later, their Tinker Toy assembly instructions will be, too, along with assembly leader lines. That will continue as they mature toward instructions for Erector Sets, installation sheets for their faucets, maintenance manuals for their cars, and sales brochures for the motorcycle of their dreams. It's all the same core functionality. Again, take a look at other mainstream drawing programs. Canvas's Annotation Notes feature. Corel Draw's and Designer's Connector Tools, and Inkscape's Diagram Connectors, (among others) are neither inappropriate nor obtrusive. Raster auto-tracing is an example of the kind of standalone feature (not to mention amateurish bad practice) that can be easily "outsourced" to a separate program in the workflow of an illustration project. But connector lines are by definition functionally attached to individual objects within the native environment of the illustration in which they reside. Saying they should be created by use of a separate program is like saying dimensions of a floorplan should have to be added after-the-fact in a separate program. And again, their use is not limited to network diagrams for the IT department. JET