Jump to content


  • Content count

  • Joined

  • Last visited

About JET_Affinity

  • Rank
    Advanced Member

Recent Profile Visitors

512 profile views
  1. Coincident nodes is something to avoid in font glyphs. As I recall, Fontographer, since way back, displayed coincident sequential nodes (adjacent in the path winding order) with a dashed circle around them. Auto-deletion or "merging" of coincident nodes is not necessarily a good idea, because you don't always want the same thing to happen in the results. Should the associated handles be retracted? Should just the two inboard handles be retracted? Should the resulting single node become a corner or a curve node? Or should the segment joining the two nodes simply be removed (i.e.; the path opened or cut between the two nodes)? It can be simpler to just highlight the coincident nodes and let the user decide what to do with them. It's not uncommon for me, upon encountering coincident nodes, to select the frontmost one, use the arrow keys to nudge it, say, six increments in one direction, delete the joining segment, and nudge the moved node back. Frankly, in general drawing practice, it's not that big a deal. One soon learns to sense when coincident nodes exist by the giveaway behaviors. But display of number of paths (open and closed) and count of nodes in the current selection should always be provided. So should path length. These are some of the reasons why I've always preferred programs with an "Inspector" based interface (as in FreeHand since around version 3) which tells you everything you need to know (and set) about the current selection in a tidy, concise palette, instead of having the information scattered all across the interface. JET
  2. There is no bug. This behavior is common to all Bezier-based drawing programs. Since paths can be opened, closed, cut, added to, subtracted from and otherwise reshaped at any time, it would be quite debilitating if closing of "straight" paths were somehow "disallowed" whenever a move resulted in a path's being "straight." Each "segment" of a path is a complete cubic Bezier curve. The interface of the drawing program effectively "strings them together" end-to-end. By definition, a cubic Bezier curve has four ordered XY coordinate pairs, even if it appears to be just a "straight line" with "just two nodes." The whole "nodes" thing is just an interface convention. The first and last of the four coordinate pairs are the "from" and "to", or "start" and "end" of the plotted curve, so are always located on the curve. So those are the coordinate pairs which drawing programs treat as "nodes" or "anchor points" or just "points." But the second and third coordinate pairs still exist, even with what appears to be a "straight line." They may be coincident with the first or last, or they may just happen to lie somewhere along the straight line between the first and last. Closing an open path simply adds another segment which starts where the last segment of the open path ends, and ends where the first segment of the open path starts. So there's no reason a single-segment path (your "straight line" with "just two nodes") cannot be closed by adding a second segment identical to it in shape. For example, forget straight paths and consider a curved path. There's nothing preventing you from doing this: Create a curved single-segment path; for example, a 90 degree arc. Copy it. Paste the copy in the same position, exactly in front of the original. You now have two complete cubic Bezier curves, each still having four defining coordinate pairs. Join the two identical single-segment paths at one end. You still have two complete Bezier curves. But the smoke and mirrors of the software interface treats this construct as a "single path with two segments." It's just treating the end coordinate pair of the first curve and the start coordinate pair of the second curve as a single "node" since they are at the same location. It's effectively "sharing" a coordinate pair between two Bezier curves and through the smoke-and-mirrors of the interface, enabling their associated "handles" (the third coordinate pair of the first curve and the second coordinate pair of the second curve) to be optionally "linked" in one of several behavioral ways when you manipulate them. Close the path. Now you have what the interface presents as a 2-segment closed path. It's still two complete cubic Bezier paths, each defined by four coordinate pairs, but the interface is effectively "sharing" two pairs of start and end coordinates and providing that optional "linking" at both of those "shared" locations (the two on-path "nodes.") This "closed path" still has a start and an end. It also still has a direction. But now, because of that wonderful "magic" of the software interface, you can: Select one of the two nodes. "Convert" it to a smooth node, causing the third coordinate pair of the first segment and the second coordinate pair of the second segment to act like they are interdependently "linked" so as to be constrained to make a straight line with the "shared" coordinate pair... ...and have a teardrop shape, while being confident that the two curves (segments) remain perfectly tangent at the other node. And now, just because the two segments are not identically shaped, it doesn't seem at all strange that a path having "just two nodes" can be closed. JET
  3. That "PDF thing," though, may be a realistic opportunity for competitively exploiting Adobe's own lethargy. So far as I know, (I don't rent software) Illustrator and InDesign no better integrate the data fields capabilities of PDF "forms" than they did in CS6 (the latest non-rental version). I also don't know whether the "forms" functionality of PDF is as "open" as the rest of the PDF standard in general; but I'd bet some particular enterprising software developers know (or know how to find out). JET
  4. They've heard me (and others) suggest it multiple times before at FileMaker DevCon. A great advance in the right direction wouldn't take much more than a few enhancements to its presentation layer: Full display of SVG in regular Container Fields. (I mean c'mon; it's already in buttons.) A Bezier path tool. Paragraph Styles. (It already has the corollary to object styles.) Embed fonts. (Needed for web-centric delivery, too, which after all, is an area of high FileMaker focus.) Oh...and "de-depricate" standalone runtimes. I don't mean to derail the thread. At least a basic data merge feature in Affinity Publisher should of course be expected and would be better than nothing. My general points are: "Better than nothing" is a pretty low ambition, especially for the bent toward innovation evident in Affinity. The rapidly growing need for seriously data-driven graphics is much bigger than just another "mail merge" feature, and I'm not sure its answer really fits the framework of conventional page-layout software, even when used in conjunction with the comparatively cumbersome data-driven capabilities of PDF. For now, the combination of one's favored graphics programs and FileMaker Pro can powerfully broaden the scope of enterprising graphics people, and is more approachable than many may assume. JET
  5. Refreshing. It seems that with very few exceptions, user requests for adding features to this exciting new Affinity platform are couched in "me, too" terms. ("I need this single deal-breaking feature now, just as it is in [my pet program], or I'm outta here!"). There's not really much new under the 2D graphics software sun, and hasn't been in a long time. I blame that on the continued dominance of the market by a few historic monoliths. The good news is, almost every "me, too" feature request is a potential opportunity for breaking beyond the lockstep lethargy of current offerings. My constant hope is that the Affinity team is striving for something more innovative than the conventional wisdom standard-fare. One of the macro consequences of the decades of micro improvements to the mainstream titles is that in today's increasingly data-driven world, publishing and illustration programs seem farther and farther behind the times. Just another "me, too" data merge feature like those typically used for recipient address labels, etc. is already passé. Juha7one mentioned FileMaker and made my heart sing because I've used FileMaker to build fairly ambitious fully data-driven publishing solutions. Two examples: A 1000-page aftermarket parts catalog, the content of which is directly and continuously updated by parts information experts, not graphic designers, using straightforward data-entry screens, designed to precisely fit and streamline their tasks. The dataset is much larger than what will fit in a thousand-page print, and includes relational tables for brand-to-brand cross-referencing, live pricing, and more. The design is built in, up-front, and is flexible. The layout assembly and export to print-ready PDFs is entirely automated, requiring no "desktop publishing" whatsoever. Workers can on-the-fly isolate focused content by section or part type, and automatically generate print-ready "extracts" from the catalog for monthly specials, trade-show handouts, etc. An application that empowers Dealers to automatically generate their own individualized dealership-branded sales promotions (electronic or in print, in various formats) while keeping in full agreement with the factory branding standards. The application is a tidy six-step interface start-to-finish. Its dataset includes everything from the above-described product catalog database (access to tens of thousands of items), lookup functionality for current Dealer pricing (including a handy calculator for pricing on a per-item basis), the Dealer's Direct Mail info and indicia, and customer mail list. Those and other projects like them have convinced me of this: It would be far easier to turn a version of FileMaker Pro into a graphically-powerful data-driven publishing platform than to turn a conventional page-layout program into a powerful data-handling solution. All that would be required is to flesh out FileMaker's Layout Mode with a few more graphics-oriented features. I'm just an enthusiastic FileMaker user, and just mention it from that standpoint. When asked what my favorite "graphics program" of all time is, I only half-jokingly reply, "FileMaker Pro." Its approachability is well within the capabilities of most graphic designers, and for creative minds its use opens a whole world of data-driven publishing capabilities, either standalone or in conjunction with conventional graphics programs. JET
  6. JET_Affinity

    Text export to PSD

    Application-specific formats are proprietary and subject to change at any time. (Ask anyone dealing with AutoCAD formats.) It's unrealistic to expect software vendors to match, object-for-object, construct-for-construct, the proprietary formats of their competitors. That's why open exchange formats exist, and robust compliance with those is what should be the responsibility of the competing vendors. Do you also pressure Adobe to make Photoshop seamlessly export live text objects to Affinity Photo and Affinity Designer? No. Why? Just because Photoshop currently dominates the market. And yet you say you "hate Photoshop." Well, the object of your hatred will never stop dominating the market if everyone keeps insisting that everything else has to perfectly conform to it. JET
  7. But why only the midpoint of a segment? What if I want to snap to thirds of a segment? Or divide a segment into fifths. An Add Nodes Per Segment command would enable one to create snap candidates at any fractional increment along a segment. JET
  8. One can make a list of "deal-breaking missing features" which make it "impossible to switch to" any given drawing program. Guess which program is missing these essential features: Live shape primitives Dimension tools. Connector lines. User-defined drawing scales. User-defined diagonal grids. Ability to key multi-operator math expressions into value fields. Find/Replace a simple carriage return. Text frames that can be set to auto-fit their content. Proper paragraph rules. ...and much more. Yep. Adobe Illustrator (at least as of CS6, the last version available as a traditional perpetual license). Whether they realize it or not, just as users of other programs do, Illustrator users have continually limited their needs to the capabilities of Adobe Illustrator every day by working around its limitations. But they do so all the while proclaiming it the "professional industry standard" which serves "99% of users needs" by which anything else has to be measured and found lacking if it doesn't mirror every feature in every detail. Features versus user's needs; which is the chicken and which is the egg? But wait! There's a third party plug-in, say CAD Tools, that saves the day by providing the functional sophistication that should be standard in the overpriced program in the first place, and that costs as much as or more than the host program. I'm not knocking CAD Tools. But instead, one can pay half as much for a competitive side-grade to, say CorelDRAW Suite, and gain: The needed functionality in a cleanly-integrated standard feature set instead of tagged-on runaway tool glut. A plethora of additional software and assets. Hand's-on knowledge rather than mere hearsay when presuming to "compare" competing programs. "Most popular" does not necessarily equate to "best." It often just means most ordinary. JET
  9. Not when, say, 50% of a given user's needs happens to be illustration destined for screen imprinting on garments by means of multi-channel spot color separations, for just one example. It's silly to make these blunderbuss "program A is better than program B" pronouncements. Affinity Designer is already "better than" Adobe Illustrator if you have an essential need, for example, to specify dimensions by trig functions. Illustrator can't do that. Adobe Illustrator is still "better than" Affinity Designer just because of its Pattern Brushes. All these programs have their own strengths and weaknesses. There is no law prohibiting anyone from using more than one vector drawing program. A watercolorist doesn't choose his medium because it is "better than" oil paint. Nor vice-versa. Both painters simply exploit the characteristics and abilities of their preferred medium. No one really has to "wait" until Affinity Designer has each and every tit-for-tat feature that so-called "industry leader" (gag me) Illustrator has, before buying it and getting profitable and enjoyable use from it (especially at its price). What ultimately wins in the marketplace is value and user experience (including customer relations). No one likes having their own creative files effectively held hostage by software rental schemes. Even if hades froze over and Adobe reversed that, the fact remains that the pricing model of all the old stalwarts dates back to the days of the game-changing desktop publishing "revolution." That old world pricing is now long outdated. When industries undergo radical changes people pay "whatever it costs." But then things stabilize, price efficiency is achieved, business models become more realistic, and the big players either adapt or fail to. In that struggle, they grasp at the customer base's tolerance in desperation to maintain their inflated status. But 2D graphics software is not rocket science anymore. I learned early on to avoid third-party plug-ins like the plague. To my mind, the whole plug-in thing is long ago failed. Maintaining version-parity is a pain. The vendors of them come and go. All the while they're too "vertical market" priced (the plug-ins often costing as much as or more than the host program itself). But moreover, I quickly found I didn't like developing business-critical dependency upon their volatility. I'm not sure I'd be crazy about how Serif's mission-critical dependency upon more third-party tech licensing might trickle down to me in the form of its products' pricing, capabilities, or interface elegance. So yeah, I want to see multi-spot-channel accommodation in Affinity Photo. That doesn't mean I can't use it until I can "switch" to it because I'm somehow "required by law" to only know how to exploit the strengths of one program. djjss, I'm not the forum sheriff, but please post individual suggestions in their own threads, (and look for pre-existing threads on those topics) so that topics are organized and navigable. Specific-user "wish list" posts just become grab-bags of open discussions, as this one already has. JET
  10. While I agree in concept, it's worthy of some further discussion because this can be taken as another example of assuming that Adobe Illustrator is the end-all "leading' functionality worthy of being mimicked when, here at nearly one fifth of the way into the 21st century, we really should be aiming rather higher. Not trying to be a know-it-all, but the following may be instructive to those...well, younger. Like most vector drawing programs, Illustrator also started out with just the four basic Boolean path combination operations (add, subtract, intersect, exclude), and as I recall, it didn't move beyond that until around version 9 or 10, when its so-called "Live Effects" became all the focus. That's when Illustrator's so-called "Pathfinder" functions became (by default) its so-called "Compound Shapes" (which, in typical Adobe fashion, creates untold confusion with the term "compound paths"; an entirely different thing). Affinity Designer also provides the four base Boolean path operations, and they are also already "live" constructs. In Illustrator's case, it was actually user reaction against "Compound Shapes" (the "Live Effect" behavior) being the default that finally reversed the default so that the "Live" behavior requires the modifier key. Regarding the Merge Pathfinder in particular: Illustrator's Merge Pathfinder cycles through the selection in its stacking order and performs Boolean subtract on paths with differently-colored fills (which Mintcar's screenshot depicts). But its differentiating aspect is that it then cycles through the results and performs Boolean add on any adjacent same-color fills (which the screenshot does not depict). This is indeed a very useful time-saving feature, especially when designing for rather involved instances of purposes like cutting sign vinyl and stencils, or screen printing. So yes, when priorities get around to elaborating the Boolean operations already in Affinity Designer, something similar to Illustrator's Merge would be valued. But for decades prior to its appearance, we did what Merge does by simply performing Boolean subtract, followed by Boolean add. As in almost all such comparative requests, there remains much to be desired, and we should aim higher than "like Illustrator." For purposes to which Illustrator's Merge is most beneficial (and thereby worth of a separate command), a degree of overlap is commonly, if not usually, needed (similar to separation traps in offset printing terms; but more like offset path commands in vinyl and screen printing). To make Illustrator's Merge feature something rather more special than just doing color-specific Boolean subtract followed by Boolean add, it should have also been provided a simple field for an offset value. Illustrator's Merge also suffers from the same problem which has always plagued its Pathfinders (and other things like its Knife Tool): It doesn't know what to do with strokes. Whenever Pathfinders have this problem, strokes are just removed. Even before the advent of so-called "Live Effects," competing programs did not have this problem. FreeHand, for example, simply kept strokes as strokes (which, if one thinks about it, is also a "live effect") in the results of its Boolean path combinations (and its Knife Tool correctly cut all paths, open, closed, filled or unfilled). Illustrator provides multiple features which essentially do the same thing, and add to its overall clutter. While sometimes useful, this is not elegant interface design. It's a better user experience when more "power" is provided "just under the hood" of more fully thought-out and better-integrated functionality of relatively fewer tools. In this context, I'm not sure that greater path combination functionality couldn't be accomplished as part of a user-friendly scripting or macro implementation. Given that, as explained, Illustrator's Merge button is, in effect, a "macro" that performs two base Boolean operations (subtract, add) in one move, with the caveat that the operations are color-specific, consider: Wouldn't the "missing" overlap value field also be valuable for the normal subtract function? Wouldn't all the Boolean operations benefit from an option to set a conditional constraint, such as same or different color? So Boolean path operations represent yet another opportunity for Affinity to break beyond and rise above the conventional-wisdom treatment, providing greater power with less "feature glut." JET
  11. Again, a topic conjures up fond memories of FreeHand. FreeHand had just one kind of text object. It could be set to auto-expand horizontally (i.e., becoming functionally equivalent to a so-called "art text" object in other programs) by simply doubleClicking the right middle handle. It could be set to auto-fit its contained text vertically by doubleClicking its bottom middle handle. The text objects could be bound to and released from paths (instead of being treated as a separate "path text" object). They could be threaded, whether bound to a path or not. They could be set to auto-expand when bound to a path, thereby preventing the problem of accidentally truncated text in complex maps, as is so chronically common in maps built in Illustrator. This is conceptually parallel to the fact that FreeHand also never had any need for two separate selection tools. Its single selection tool enabled you to edit paths at the whole object level and at the node editing level. That elegant interface design made path drawing far less tedious, more fluidly efficient, and more powerful than any drawing program that insists on following Adobe's hideous model of two primary selection tools. Macromedia finally gave in to ill-advised "demand" from Illustrator users to add a second pointer tool. When added, it provided absolutely no additional functionality. It was literally nothing but an accommodation to Illustrator-habituated users who just refused to learn that it was absolutely unnecessary. FreeHand users simply ignored it. It was not until FreeHand's very last version that its white pointer did anything that the black pointer didn't, and even that was a minor detail that could have been implemented without adding another tool. Despite Illustrator's two selection tools (three, really, when you include the ill-conceived "Convert AnchorPoint Tool")--actually because of it--Illustrator to this day does not "know the difference" between a path being selected at the object level versus merely having all its AnchorPoints selected. This causes all kinds of silly inconsistencies such as being unable to use the Break Anchor Point command when all of a path's Anchor Points are selected. (You have to unintuitively de-select at least one Anchor Point for it to work.) Because object selection is so bedrock foundational to an object-based program, its tedious effects "cascade upward" throughout the program's interface. In a nutshell, it's what makes working in Illustrator feel as frustrating to beginners as trying to eat spaghetti with a single chopstick. It's because Illustrator's white pointer behavior is conceptually "upside down" from intuition. It's the selection tool you have to use to edit a path. But its first click always selects the most "internal" sub-part element of whatever construct you are trying to manipulate. Rather than intuitively selecting an object of interest and then "digging down" to its subparts with subsequent clicks, Illustrator's scheme first selects some "molecule" of the object of interest and requires use of a modifier key and subsequent clicks to "back out" of it to each next higher level. It's metaphorically like getting up in the morning and needing a pair of socks. So you intuitively try to open your sock drawer. But your hand passed right through the closed drawer, and the only thing you can grab is a single thread of a single sock. So you have to then use both your hands to select a single sock, and grab again with both hands to grasp the folded up pair. All this "Bizzarro World" behavior instead of simply opening the drawer and grabbing the pair of socks. The beginning of the end of FreeHand was not the Adobe acquisition. It was when it started to emulate Illustrator's hideous interface. Unfortunately, because things like selection tools and text objects are foundational to the program built upon them, I'm sure it's too late to back-track the existing conventional-wisdom (i.e. "like Illustrator") in either case. But I say again: If you want to build a better drawing program, Adobe Illustrator is not the program to emulate. JET
  12. Nah. Sights set way too low. Anyone who has experience with Freehand's Graphic Find & Replace palette knows we don't need no cheezy magic wand tool. JET
  13. I'm just not finding that to be the case. I'm an illustrator. My interest in scripting is not just a glorified macro; I use Javascript to programmatically draw things. I'm not a programmer per se, and don't play one on the internet. But I've been able to accomplish profitable things with JavaScript in surprisingly short order and with quite productive results: FlashScript interactive simulations which replicate the behaviors of real-world mechanical systems (multiplex wiring, regenerative exhaust systems, air brake systems) for training. A whole library which effectively adds important missing features to AI, including a set of non-modal palettes for facilitating axonometric drawing in any isometric, dimetric, trimetric orientation. Similar interactive axonometric tools by using Javascript to manipulate SVG in ordinary HTML. Integrating Javascript into FileMaker Pro calculations to build interactive axonometric "visual calculators" that run in FileMaker's WebViewer objects. I quit expending energy developing AI-specific Javascripts the instant Adobe started its Captive Customers scheme. But found it easy to lateral my developing Javascript familiarity from FlashScript to so-called ExtendScript to plain vanilla Javascript in HTML, and even into FileMaker Pro. I did all the above without reading tomes on Javascript. I've done it by just learning the basic syntax logic on W3C, looking at a few examples, and referring to the program-specific Object Model documents. Looking to do similar things in Inkscape meant getting familiar with Python. I've expended way too many hours of precious little spare time reading various Python books, starting with downloading the resources that have to be installed on the machine, dinking with the command line interface, yadda yadda. While there's nothing "difficult to understand" per se, I have yet to accomplish anything actually useful with it, don't find it any more intuitive than JavaScript, don't particularly care for its sensitivity to white space. Can I do it? Sure. But I've already found the afore-mentioned ubiquity of JavaScript across platforms and disciplines advantageous. I have yet to see any compelling reason to "start all over" with Python, other than it's been adopted by Inkscape for developing extensions. But that already seems more cumbersome than what I was doing with Javascripts for AI. (And yeah, I know this is mainly just a matter of my familiarity.) Again, I'm not the expert in this. But every time another language comes along, its devotees start over-evangelizing it as a replacement for everything pre-existing, and frankly I've grown weary of that over the last few decades. It's not that I have anything "against" Python. My own daughter-in-law uses it for various things (mostly related to gaming). But I also don't see JavaScript "going away" by any stretch and even in my modest experience, I have had much opportunity to appreciate its general versatility. So, for what it's worth, and since we rather presumptuously seem to think the Affinity Team's decision is going to be driven by a "scripting election" in this thread, my vote is for Javascript--and a very thorough object model document. Seems a safe bet to me. Oh...and having abandoned MacOS almost two decades ago, and despite being an avid FileMaker Pro devotee, I have no more use for scripting anything with a proprietary language prefixed by "Apple…" than anything strictly proprietary to Adobe.
  14. Your use of "transformed" and "morphed" suggests the feature generically referred to as blends. But your screenshot depicts and your use of "rotate and scale" suggests a reiterative transformation, often called "power duplication." Results can be similar, but they are not the same thing. Object blending is not yet offered in Designer (nor, therefore in Publisher). But because it's been regarded sort of a staple for vector-based drawing programs since the early days, I'm sure it's planned. (As I recall, it's probably already on the road map.) Most mainstream drawing programs at least provide for ordinary path blends (interpolating between constructs consisting of Bezier paths). Illustrator's Blend feature can blend between most anything, including most anything stored as a Symbol, and live effects applied to the key objects. In this sense, "live effects" means most object attributes (Graphic Styles, for example), whether they are actually called a "Live Effect" in Illustrator's interface. For example, in Illustrator, you can blend between instances of paths to which its 3D Effect has been applied (with the potential for memory problems if done too cavalierly). Reiterative transformations, however, are provided for in Affinity Designer, by use of the Transform commands in combination with the Duplicate command. So that may be accessible in Publisher, too. (I just haven't had more than a few minutes' time to explore Publisher yet.) Try searching for "duplicate" in its documentation. Generally, the differences between blends and reiterated transforms are: As usually implemented, Blends start with "key" objects and then automatically interpolate the intermediate steps between them in terms of decoration attributes (strokes, fills, other effects) and some transformations (scale, rotation, skewing) and initial positions. For translations (movement) along curves, though, they rely on following a separate path used as the spine. Because the intermediate steps are automatically interpolated, your control over certain things like precise spacing is somewhat limited by whatever parameters provided in the specific program's Blend interface. So, for example, in the typical spiral-like transform as in your screenshot, the spiral is usually a separate path, and your control over the spacing is somewhat limited, but still adjustable after the blend is made. In reiterated transforms, the spiral is just a consequence of the precise values you've entered for the scale and rotation transforms. After it's done, it's just a stack of separate and individually-sized, scaled, rotated copies of the original. So blends would be more in line with the concept of "morphing one object into another." So-called power duplication would be more in line with just generating repeated transformations of copies of the same object (as in your screenshot). JET
  15. Wosven, In Beta, I don't see any ability to access the center-of-transform anchor when editing Nodes. JET