Jump to content

JET_Affinity

Members
  • Content count

    351
  • Joined

  • Last visited

Everything posted by JET_Affinity

  1. People love to complain about how long it is taking for their favorite "must have" feature to be implemented. Yet the above was requested of those who want this feature over 4 years ago, and I still see no examples posted by those who consider auto-tracing so essential. Please show some real-world examples demonstrating why you consider auto-tracing essential. Please post screenshots of both the "before" (the original raster) and "after" (auto-trace results), not merely at the same size, but zoomed in sufficiently to make the actual functional improvement evident. And show the results before any manual post-trace path editing. The most often claimed "need" for auto-tracing is ostensibly to gain the technical advantages inherent to vector-based artwork: resolution independent scaling. So that improvement needs to be demonstrated in the examples. If the net result merely swaps one kind of ugly jaggedness (raster pixelation) for another (jagged or inaccurate vector paths), there is no functional gain. Remember: Except for uses such as NC cutting fabrication, everything gets rasterized in its final reproduction anyway, whether printed on paper or viewed on a monitor. JET
  2. Selection in general still needs a lot of work. It seems that the Node Transform tool itself was added in reaction to shortcomings of the Node Tool. This application now has three primary selection tools, whereas most programs like it have the Adobe-esque two, which FreeHand's functionality always surpassed with but one. Too much "hard switching" between tools (as opposed to using momentary modifiers). I do appreciate the Node Transform Tool's novel ability to uniformly scale as it rotates (which can be overridden by a momentary modifier keypress) in order to snap to existing artwork. But I don't know why the functionality of the Node Transform tool couldn't or shouldn't be integrated with the Node Tool. As AK21 mentioned, the Node Transform Tool cannot perform its transforms on a sub-selection of nodes. Much of it seems to be in strained effort to doggedly cling to what I consider the kind of over-the-top obtrusive insistence on bounding box handles for transformations. I know this is part and parcel of Affinity Designer's ability to remember each path's original orientation, which is a valuable capability that many programs (including Illustrator) do not have. But this has long been better implemented in Deneba Canvas (one of the still-surviving venerable Big Four competitors from the 80s). Many Affinity users have complained about the inability to permanently reset the bounding box to the current orientation (which can be done in Illustrator). This is a real stumbling block when working in Affinity. But in Canvas, you can switch between a selection's "transformed" and "untransformed" values at will, with the corresponding bounding box appearing. A small step in the right direction which would yield disproportionally large improvement would be simply for all nodes of the selected path to not automatically become unselected when merely switching from the Selection Tool to the Node tool. Another behavior that should be standard fare is that deleting an open path's endnode should result in the adjacent node's being selected. It's a very useful thing to be able to "back up" a path from the last-placed node just by tapping Delete. Also related to all this is the problem with drawing "lines" (single-segment straight paths) with the Pen's Line Mode. It's hard to think of anything more basic to drawing (even before drawing with software) than drawing a measured line. But with Affinity's Pen set to Line Mode, only dragging out a horizontal or vertical "line" will result in its "dimensions" corresponding to its length, because of that infernal insistence upon referencing everything to the obtrusive bounding boxes. Using the Pen in Line Mode, drag out a diagonal line, and all you'll get is its bounding box dimensions. One can put the bounding box dimensions to use, for example for calculations based on sine and cosine. But it is far more commonly useful to intuitively draw the path at its desired angle in the first place, and immediately know its actual length. And angle. So I hope none of this is taken as derailing a specific request. I'm just saying that all these things are closely related to devising a truly elegant path selection and manipulation interface, and I suspect the devs still consider it a work-in-progress. For example, I seem to recall a mention somewhere of enabling the Node Transform tool to manipulate sub-selections something still to be worked on. JET
  3. Thanks for this! These are the things that "keep me up at night." JET
  4. JET_Affinity

    Ability to snap along curves in Node Tool

    Something (yeah, there's always something) that is now needed to work better with the new capability: I have a path selected by the black pointer (Selection Tool). This, of course, displays the infernal bounding box, which only gets in the way when I want to drag a path by one of its nodes. I switch to the white pointer (Node Tool), because I want to drag the whole path by one of its nodes, in order to accurately snap that node to and edge or node of another pre-existing path. But upon merely switching to the white pointer, all the nodes of the wholly selected path become unselected. So I now have to marquee select the whole path all over again with the white pointer, in order to take advantage of the newly added (and much needed) snapping capability. I see no justification for this. Merely switching to a different tool should not change the selection state of what is already selected. When a path is already selected with the black pointer, switching to the Node Tool should, of course, get rid of the all too-assertive bounding box, but should otherwise leave what is already selected (the whole path) alone. In other words, merely switching to the Node Tool should leave all the path's nodes selected, not deselect all the nodes. I understand the counter-argument which someone may raise: The assumed purpose of switching to the Node Tool is to manipulate a subset of the path's nodes. But, first, the program has no business making that assumption, especially given the now better snapping behavior. Second, the existing behavior (automatically deselecting all the nodes) causes me to have to make a marquee or individual nodes selection regardless of whether I want to move all the nodes or just a subset of them. If the change I'm asking for were made, I would only have to make a marquee selection when I do want to move only a subset of nodes. And in that situation, I would, of course, have to select the specific nodes I want to address anyway. So having them all always automatically deselected is really no advantage at all. Some may anticipate what my next argument will be: Now that the Node Tool and the Node Transform Tool have the needed ability to snap to pre-existing nodes and edges, it raises the obvious question: Why the need for both tools? In other words, why can't the Node Tool also be able to do the rotations, skews, and scales that the Node Transform Tool can do? In other other words, why can't I just work with the Node Tool when manipulating paths, and only switch to the black pointer when I do want to manipulate handles of a bounding box, as I can do in other programs? JET
  5. Adobe is a company. If you're talking about Photoshop (the program with the Constrain option you favor when bending segments), yes, I've used it pretty extensively since version 1 through version CS6 (I don't rent graphics software). And yes, if it were possible to momentarily toggle the behavior by means of a keyboard modifier while in the act of a single bend move, I would use it. Something I've always disliked about bending paths in both Photoshop and Illustrator is that the very same moves with the inelegantly named Direct Selection Tool doesn't bend straight segments; it moves them. That, of course means it also moves the ostensibly unselected Anchor Points. That's just one example of how Illustrator's inconsistent interface violates the very concept of something being selected. For most of its history, FreeHand had but one selection tool. It was both more intuitive and more powerful than Illustrator's is, even today, and the context of bending paths is a good example. You could bend curved segments and straight segments, with a completely consistent interface. Olav Martin Kvern, the quintessential FreeHand guru long before working for Adobe, coined the term "Benodmatic" as a distinct path drawing methodology. A beginner struggling to get their head around drawing with Bezier curves could be taught to first just click, click, click, placing only Anchor Points at intuitively appropriate places, and then go back and smoothly bend the straight segments that needed to be curves. I used that method countless times to get beginners over that initial panic hump of using the Pen tool. But it wasn't just for beginners. I often used it to impart a pleasing stylistic consistency and economy of nodes in artwork that needed to be optimally built (for example, in glyphs of symbol and clipart fonts). You could also power-duplicate path changes in path shapes using FreeHand's single selection tool. For example, you could AltDrag a Point, thereby duplicating the whole path but with that change in shape. Thereafter, invoking the duplicate command re-iterated the whole path and the shape change. You can't do that in Illustrator, because Transform Again duplicates only the bent segment. So no, I don't think Adobe products are the ones to emulate even in things as basic as path manipulation and selection. JET
  6. But not really surprising, given that many of Adobe's graphics apps (including Photoshop) were acquired. One of the advantages of the Affinity platform is that all three of its "legs" (raster, vector, assembly) seem to have been conceived and are being developed together as a cohesive platform, not as a mere marketing bundle of separately-developed (or acquired) programs. The "integration" (something Adobe has always loved to banter about) is deeper than mere interface window dressing. Which is why I tend to "weep and moan" whenever I hear users demand conforming to the "mean ol' levee" of Adobe Illustrator, the interface of which is more twisted than the Mississippi. There are straighter (and more elegantly integrated) paths to the needed functionality, if we can just afford the dev team time to consider them, and offer our input (which the dev team seems refreshingly open to) with some appreciative civility. (Alluding to other threads, not this one.) JET
  7. And it does in SVG, and therefore in Inkscape. But I'm not saying it should in Affinity Designer. Because unfortunately, Descartes's grave was desecrated by the graphics industry long ago. So everything's just a scattered mess anyway. Go try and tell your trig or calc professor (or your HP graphing calculator) that the Y axis origin should be at the top of something called a "page," and therefore vertical values should increase downward. But that's what has happened to vector-based graphics programs; something that is by definition math-coordinate driven. The root problem is, Affinity Designer should be an illustration program first and foremost, and a proper Cartesian coordinate system is what should be used in all such programs. But that's not Serif's fault. That ship sailed with FreeHand. (It was actually merely run aground by if-you-can't-beat-'em-just-buy-and-discontinue-'em Adobe.) And somewhere around that time, Adobe also flipped the Y axis in Illustrator to assuage uninformed demand from users who don't know Descartes from Adam, and it and everything that imitates it drives me freakin' nuts. Related: Even before inverting Y, Illustrator's single Artboard was always inexplicably created at the center of the program's limited pasteboard. And it still is, and that's one reason why its page handling was (and still is) far more cumbersome than it should be. FreeHand's initial default page was properly created at the lower left; in other words, at the origin of its proper Cartesian coordinate system. So added pages proceeded sensibly without, in effect, wanting to waste half or three-quarters of its limited pasteboard. A vector based drawing program (or CAD program) should, by default, have its X ruler at the bottom of the screen, not at the top, and positive Y values should increase upward. But if Serif had done that, there would be a firestorm from users who now think Y values increase downward, just because they do in a web page—and Adobe Illustrator. It's too late for this issue. But please, for everything else going forward, let's just forget Adobe Illustrator so that vector-based drawing can actually move forward. For example: If vector-based drawing ever does get out of its Adobe-esque doily drawing doldrums, one thing we might find of interest is the feature that has long existed in Canvas for directly plotting curves by formulae and function. Guess what kind of coordinate system that feature uses. JET
  8. I'd prefer the momentary press of a modifier key over a separate setting that makes you leave the path in progress. When drawing vector paths, one uses modifier keys continuously; to constrain to horizontal or vertical; to break a tangency when dragging out a curve handle, to sense snaps, etc. Bending a segment is the same kind of thing. I certainly would not want it to always constrain its associated curve handles to their current angles. I might want that behavior in one segment of a path, but might want the other behavior at another segment of the same path. In fact, I very well might want to freely alter the skew of the associated handles initially, and then constrain them to their new angles the angles in the act of performing a single bend. JET
  9. It should be optional, invoked by a momentary keyboard shortcut, as described in the original thread. Either behavior is equally advantageous in as many situations. JET
  10. JET_Affinity

    [AD] Isolation Mode

    My point is what I said, Luis: A bit of perspective. I'm not attacking your feature request. I am saying that its "essential" claims are grossly over-stated. Practically everyone with a wished-for feature claims that theirs is "so basic to drawing programs that Affinity Designer is rendered useless without it." Yet I dare say most never even heard of "Isolation Mode" until Adobe called it that in 2007. You've received replies from Serif on this. There's no need to "pile on" about it. If that were all it is, it would just be an email direct to Serif. It's not just where we ask for features; It's where users of varying experience also discuss the merits of those features. JET
  11. JET_Affinity

    [AD] Isolation Mode

    For perspective: Illustrator's "isolation mode" did not appear until CS3 (2007). If it's such a 'deal breaking, bedrock essential basic' feature (just like everyone's pet feature request is), how did anyone use Adobe Illustrator for the two prior decades? I paid $50 for Affinity Designer. You know how much money I spent on Adobe Illustrator prior to 2007? My use of Illustrator's Isolation Mode is only occasional. And I certainly don't judge any program that doesn't have something like it "unusable." JET
  12. Correct. Proper logo designs of all things should be created with the most painstakingly efficient and elegant paths. The more vector-appropriate the artwork, the less excuse for auto-tracing. Else, you lose the resolution independence advantage that vector-based graphics exist for in the first place. Certainly anyone claiming to do commercial quality vector illustration (i.e., charging money for it) should be proficient in drawing optimal paths with the appropriate tools. And that's where anyone learning to create commercial-quality work should expend energy; not in tweaking a bunch of tolerance settings in an auto-trace feature. The more vector-appropriate the artwork, the fewer and cleaner the paths should be, so the less "time consuming" it is anyway, for someone who knows how to do it right. So when it comes down to it, the only few-and-far-between excuse for resorting to auto-tracing is for things that are just too complex for drawing with deliberate and intelligent discernment. And even in those cases, one should always ask oneself if auto-tracing is going to yield any technical advantage anyway. See the self-cancelling cycle? It's not the beginning users' fault. The software vendors grossly over-glorify the "automagic" of auto-tracing features with claims like "Instantly convert raster images into resolution independent vector graphics!" That's the myth perpetrated among hobbyists. There is no "conversion" to it. Raster-to-vector is not some kind of unambiguous code translation, like converting a TIFF file to a PNG file. The only lossless 1:1 "conversion" from a raster image to a vector graphic would be literally tracing a square path around each and every pixel. And that would have absolutely zero resolution-independence advantage over simply using the original raster image. That technically "perfect" auto-trace would also be perfectly useless. No, there's just re-drawing the subject. And auto-tracing doesn't even make any attempt to re-draw the subject, because it has no idea what the subject or its purpose is. It merely tries to draw paths around contiguous clusters of similarly-colored pixels, utterly regardless of shape or meaning. So you either re-draw the subject with meaningful (and hopefully aesthetic) human discernment, or you entrust it to a completely dumb algorithm that has (as of current standards) absolutely none. JET
  13. I don't know what that has to do with this thread (which is just a repeat of existing auto-trace threads). But if you want to see, say, a thoroughly well-done Javascript implementation in Affinity, I'd be right there with you. I've said as much in existing feature wish threads. (I'm not really interested in coding—or buying—plug-ins.) But now may not be the time since the feature set (and therefore, I assume, the object model) of Affinity Designer is still very much under development. JET
  14. No. Just slightly more convenient. For other examples in addition to the scanning utility already mentioned: I use the Windows Calculator utility quite often, every day, while working in most every program I use. Same thing goes for the screen capture utility, TechSmith SnagIt, and the standalone Bitstream Font Manager that comes bundled with CorelDraw. Launching any of them is, at worst, a single click on the TaskBar. (SnagIt is invoked by a keyboard shortcut.) I find that no more arduous than clicking a tool button or making a menu selection in order to invoke yet another auto-trace feature to twiddle with yet another UI, just to get pretty much the same result. I use multiple programs all day. I also use multiple vector drawing programs. I don't need a differently-branded UI corresponding to each different drawing program for every calculation, screenshot, scan, or auto-trace. I actually prefer using the same familiar interface for scans and screenshots and font management, regardless of what graphics program I'm using. It's actually more efficient that way. Auto-tracing is just as appropriate for that kind of "standalone" use. It doesn't need to be re-invented in every drawing program. There are decent auto-trace solutions (at least as defined by the current state of it) available to everyone for free, even. Unless and until Serif (or anyone else) has some kind of game-changing functionality to make it more than what it currently is (generally bad practice anyway), it's not even on my "missing features" wish list. For example: I have yet to see any auto-trace program (targeted to mainstream general graphics users) that knows what a child knows: that when it's scanning the pupil of my puppy's eye, the resulting path should be an ellipse. So yeah, if and when the Affinity team happens to have in its secret closet an auto-trace feature with sufficient artificial intelligence for at least basic shape recognition, that might be something worth introducing. JET
  15. Yes, Illustrator has an auto-trace feature, as do most similar programs. Not that it matters. What many don't know is that Illustrator was very late to the whole auto-tracing thing, as it was in many other features. All three of its main competitors (FreeHand, Draw, Canvas) had full auto-trace features, while Illustrator (up 'till around version 9, as I recall) had only a crude trace command that only traced one color at a time. Nowadays, auto-trace features are very common both as built in features and as online services, and there are even free implementations of both. Tourmaline mentioned Inkscape and you yourself mentioned Vector Magic. And although their user interfaces differ in terms of eye candy, they all do pretty much the same thing, and results are all pretty much alike: "Garbage in, garbage out" very much applies. So as for "why," consider that in context of Tourmaline's first reply in this thread, in which he paraphrased Serif's replies (which you can read if you do a quick search for the already-existing threads on this commonly-requested feature). Unless and until Serif has something game-changing to bring to the auto-trace table, there are more valuable things for its dev team to focus on which constitute real opportunity for long overdue innovation in the vector-based drawing arena. I am among those who see no need for yet another "me, too" auto-tracing feature in Affinity. It's no more onerous to switch to another program for this very single-purpose function than it is to, for example, launch the scanning utility of my scanner. Even Corel long delivered its auto-trace solution as a separate standalone utility that was simply bundled with Draw. Moreover, when it comes down to it, auto-tracing is a bad practice that usually just swaps one kind of resolution-dependent ugliness (bitmap pixelation) for another (poorly-drawn vector paths). JET
  16. Hear hear! It's been demonstrated that a lot of nice things can be done with the brushes in Designer, but calling them "vector" brushes just because the raster images they contain follow a spline path, is entirely misleading. Actual vector brushes (in which the brush's base artwork is vector paths) enable you to do an entire world of more powerful things: For example, A single "Pattern Brush" in AI can be built to enable creation of a mechanically correct hex bolt of any length and diameter. As always, Illustrator's implementation could be easily exceeded in power and versatility, and that's what I want to see in Affinity Designer. Hopefully, that's what the eventual goal is (perhaps after sorting out the problems associated with the present sub-par expanded stroke results). But it is disconcerting that the current brushes are called "vector" brushes. That doesn't suggest that what you (and I) would call "real" vector brushes are on the unpublished road map. This is also why I am so very disappointed in the merely "me, too" treatment of arrowheads. I am convinced that a truly innovative implementation of what I call path stokes and path ends that could be combined into user-defined path styles could yield both a much more powerful "arrowheads" feature and a vector-brush feature more powerful, versatile, intuitive, and elegant than Adobe's treatment. It would be a true game-changer even for long-time AI users who have never really discovered the kind of brush-based applications I'm talking about, just because Adobe's treatment is too "standalone" as opposed to being truly integrated with its own preexisting features of the program. That is what I see as the core of potential advantages over Illustrator: The fact that it is a decades-old stack of newer features merely "bundled with" a bunch of outdated basic features. I see that opportunity diminish whenever I see a feature implemented in a mere "me, too" fashion, as is arrowheads. JET
  17. It's called applying pressure. It's called the silly belief that if you merely scream the loudest and most repetitively ask "When? When? When?" and make ridiculous claims that the program is absolutely useless without your pet feature, then you will somehow win out over every other person who employs the very same tactic about their pet feature. JET
  18. Butting in? This is a public forum. I'm here because I do not find Affinity "useless" just because it doesn't yet have every feature it eventually will. Your questions have been answered. Serif is not going to tell you "when." I wouldn't expect them to. JET
  19. Then "some other people" are lucky enough to be like me. What do you people expect to get from demands like this?: User: "WHEN IS [my pet feature] GOING TO BE PROVIDED?" Serif: "December 25th, 9:15 AM." ? JET
  20. There are plenty of programs I have no use for. So I don't use them. And I don't waste my own time repeatedly asking their makers "WHEN is such-and-such going to occur?!" JET
  21. You obviously have no idea how long it took Illustrator to acquire its meager Select Same... commands—and many other things people here call "must have deal breakers." JET
  22. va2m, I am on topic. As I said: That's not to say that the willy-nilly kind of informal converging perspective is "illegitimate" as an illustrative style. It's not. Grossly exaggerated perspective is commonly used just to add overstated drama in everything from Marvel's super hero comic books to the Marketing Department's rendition of the corporate trade show booth. My point is that "vanishing point perspective" is a broad subject encompassing methods and purposes that range from rigorous to whimsical. So a "good" software implementation of it is an ill-defined target. Again: The familiar kind of 2D "vanishing point" perspective drawing as taught in general art classes and as usually practiced, it is not a consistent, specific geometrically-derived construction discipline. It is done differently by different people for stylistic reasons. And there's nothing "wrong" with that. I'm saying because it is more style-driven than geometry-driven it is rather ambiguous; there is not a single clear-cut, well-defined, consistent construction method for it that embraces all that arbitrary stylistic freedom. 3D modeling software does indeed emulate what a lens sees. But that's an entirely different thing from just setting up one or two or three 2D converging grids in a 2D drawing program based on a few arbitrarily placed "vanishing points." Okay, so now you're more specifically saying you want something like Illustrator's (i.e., FreeHand's) feature. Frankly, I don't. It is stylistically limiting. You can't, for example rotate its horizon. It's always assumed to be horizontal. Again, look at comic books. The common bird's-eye-view perspective of a super hero soaring above NY sky scrapers often has non-horizontal "horizons" just as do views from the perspective of inside an airplane cockpit. And why just three vanishing points? "Vanishing points" are not based on any three universal "locations in space", they are really just based on lines that an illustrator extends from parallel lines in whatever objects he is drawing. That works fine for cliché' rows of boxy objects like tall buildings conveniently oriented parallel to each other on streets that all conveniently intersect at right-angles. Depending on what you're drawing, you could need any number of "vanishing points." Said another way, there is only one "real" vanishing point; the one corresponding to your line-of-sight, located at the center of your field of vision. So how do you emulate that as guides in 2D drawing software? You'd need to provide as many arbitrary focal points as the illustrator wants to place on the page, and somehow make the all their envelope distortions interdependent relative to a center-of-vision. Which requirements? The ability to freely add and remove drawn shapes to and from the "planes"? No, LNP does not do that, because LNP is just providing you guides on your screen, not creating actual envelopes in your drawing program. That's what FreeHand's / Illustrator's Perspective Grid feature is: a set of envelopes. Affinity doesn't yet have an envelopes feature, but mesh and warp envelopes are on the planned feature list. Depending on how innovatively implemented that is, as far as we know, it could serve for "vanishing point" perspective among the other things for which envelopes are employed. JET
  23. Convincing 2D converging perspective is not that simple. If it were, we wouldn't need any special features for it. We can already just draw arbitrary horizon lines and perspective rays like we do on paper. Nor do I assume it's that simple to implement in software. Have you tried the Perspective Grid feature in Adobe Illustrator (which it copied from FreeHand)? Many users no doubt think it must be rigorous just because it's in software. But it's easy to catch it committing the common error in which foreground grid "squares" become less foreshortened vertically than horizontally and therefore look like elongated rectangles instead of squares (not at all how the eye would see it). Here's the thing: The kind of casual "vanishing point" perspective typically taught in basic art classes is actually not very rigorous. Students get exposed to so-called "one-point", "two-point", and "three-point" perspective and are led to assume that three-point perspective is some kind of end-all of ultimate realism just because the subjects we draw reside in 3D space. It's not. A view of 3D objects in 3D space can have an infinite number of "vanishing points." (Think of tossing your toddler's collection of building blocks upward into the air and taking a photo.) Yet just watch a few of the many amateur YouTube videos on the subject and listen to how many times you hear the demonstrators use phrases like "There you have it; a perfect perspective of [this or that]!" Also note that they typically just place their vanishing points at any random locations relative to each other, without any kind of actual geometric basis. Rigorous converging perspective must be based on the geometry of optics; of conic vision. Grid squares don't merely shrink toward the distance, they change in shape. (I wonder how many graphic designers and even illustrators understand that if you take a photo with a "normal lens," crop it down to a distant part of the subject, and then enlarge it, the resulting image looks like it was taken with a more "telephoto" lens.) There are more formalized methods of constructing converging perspective. For example, before computers architects used a more elaborate construction method which did a better job of constraining things to realistic proportions. Technical illustrators had special equipment like Klok Perspective Boards and Tables and their graduated ruler scales. That's not to say that the willy-nilly kind of informal converging perspective is "illegitimate" as an illustrative style. It's not. Grossly exaggerated perspective is commonly used just to add overstated drama in everything from Marvel's super hero comic books to the Marketing Department's rendition of the corporate trade show booth. My point is that "vanishing point perspective" is a broad subject encompassing methods and purposes that range from rigorous to whimsical. So a "good" software implementation of it is an ill-defined target. Axonometric drawing, by comparison, is not like that at all. There's nothing ambiguous or arbitrary about it. It is either geometrically correct or it is not, in fact, axonometric. Again, the Lazy Nezumi Pro approach to interactive drawing aids causes me to re-think the need for program-native features for converging perspective. For example, one of the demo video clips on the LNP site demonstrates its Fisheye perspective variant. How often have you ever seen that kind of 2D perspective convincingly executed by the traditional "vanishing point" methods? That novel implementation alone represents a lot of potential. In my previous post, I mentioned that the applicability of LNP to vector-based drawing is largely dependent upon the number and quality of Bezier path drawing tools that are used by dragging along the onscreen guides. It may be more advantageous for Affinity development to simply focus on optimized Bezier path tools that are of superior quality in terms of functional economy and editing elegance; i.e., the number and placement of nodes and handles automatically generated when the tool is dragged. JET
  24. Meanwhile, as Frozen mentioned, to those who haven't yet, it really is worth looking at Lazy Nezumi Pro. LPN's claim-to-fame is that it is not an "add-on" for any particular graphics program. It sort of gives your computer some drawing smarts, instead of just a particular graphics program. The drawing or painting program you're using doesn't even know it's there. You just launch it and then click the application window that you want to work within. It works by affecting cursor movement at the system level, "smoothing" your pointing device movements to constrain to the on-screen guides that it effectively "overlays" within that window. It's the closest thing I've seen to software actually emulating the use of physical drawing aids like rotatable rulers and ellipse templates. The way it works gives it these huge advantages: Although it has a quite sophisticated collection of setup options, it's worth the learning curve because you learn it once and it works the same way regardless of what drawing or painting program you're using at the moment. Although originally presented as a drawing aid for raster-based drawing, it's not just for raster imaging. It's just as applicable in windows of vector-drawing applications; it just depends on your having selected an appropriate drawing tool. Yeah, it works with path drawing tools you think of as "freehand" (pencil, brush, etc.), but it's just as useful for a line tool (or Affinity's Pen Tool in Line Mode). It's basically appropriate for any tool you drag along the desired direction because that's what it does; it affects the smoothness or straightness of your drag inputs. Its perspective features include configurations for constructing both converging perspective and parallel perspective. Contrary to common misconception, it is not just for using a stylus (which I very seldom use). On desktops or laptops, it doesn't know or care what you are using for a pointing device. (I can't speak to the matter of finger gestures on cell phones because I quit finger painting before kindergarten. So LNP is not something that competes with Affinity, it just serves as a drawing enhancement for it or whatever graphics program(s) you are using. I think you can download it as a demo to try it out in whatever program(s) you have in mind. JET
  25. JET_Affinity

    Halftone Support?

    While I'd wholeheartedly agree with the practical usefulness of a vector-based halftone feature, Illustrator's is not a "true" halftone effect. In a true halftone, the black round dots do not simply become larger as they transition across the 50% threshold and then start to overlap each other. That results in 4-point convex "star" shapes beyond the 50% level, which are not round at all. In a true halftone, dots in both the highlight and shadow areas are round. As the round black dots approach the midtones, they begin to change shape and merge into what is sometimes nowaydays called "meta balls," so that as they continue beyond the 50% value, they transition into white round holes in a black "background." Since its early years, Aldus FreeHand provided halftone fills at the individual object level. These were actually based on true PostScript halftoning. Back in those days, they did not actually render to the screen in FreeHand's interface; to conserve resources, they displayed on screen as a pattern of "PS" letters. But they provided control over frequency, shape, and angle and printed as true resolution-independent halftones on a PostScript printer or imagesetter. They were immensely practical not just for special effects, but for low-res repro methods like screen printing or flexography. Despite its being a full-blown PostScript interpreter, Adobe Illustrator has never provided that kind of halftone control at the object level; only at the whole document level. FreeHand even had a feature in which you could code your own PostScript for other PostScript fills, not just halftones. Olav Martin Kvern demonstrated examples of that in his excellent Real World FreeHand book. Nowadays, faux halftone effects (which merely scale the "dots") can use any piece of artwork as the "dots." I devised some Javascripts for Illustrator that let me use any kind of little shape ("atoms," a logo, even Lens Flare objects) stored as a Symbol as the "dots." As always, we need to set our sights higher than the current implementation of some feature in Adobe Illustrator. JET
×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | 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.