Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by JET_Affinity

  1. On 2/17/2021 at 4:57 PM, Roqoco said:

    Could these composites of boolean operations be handled by implementing a macro language? That could be useful for many other things... and would prevent the UI becoming cluttered with commands that are aimed at particular niche areas. Would also be a major feature for AD 2.

    Macro, unlikely. Too many variables. Although Windows applications tend to refer to Visual Basic scripts as 'macros', generally speaking, a macro is just a recording of a sequence of individual performed operations or commands provided in the standard interface, like so-called Actions in Adobe apps. The sequence would likely be different for every piece of artwork, thereby negating the advantage.

    Scripting, on the other hand, maybe. But that's far more ambitious. A good scripting implementation provides for variables and conditional logic. But the operative phrase here is "good implementation". I've resorted to writing Javascript to create a substantial collection of 'missing features' in Illustrator, and yes, I am one of those who dearly wants to see Affinity provide a complete and well-documented Javascript object model as soon as its feature set is more fully fleshed-out and stabilized. But even so, it was the continual frustration of scripting AI that I had to resort to it for no-brainer missing functionality like, for just one example, a simple reverse path command. (And no, no one need trot out clicking an endNode with the Pen Tool.)

    But  it comes immediately to mind in this context that Illustrator's Javascript (as of CS6, after which I abandoned it because I will not enslave myself nor have my business-critical files held hostage to a software vendor) provides no method for collision detection between paths (something I asked for throughout the years of writing AI scripting). So one might be able to devise into the script a repetitive loop of 'tests' to determine which paths actually overlap. But I'd be gritting my teeth doing that just because the functionality should be in the standard interface.

    The use case I described (vinyl cutting) is one in which something akin to Illustrator's Merge command quickly becomes indispensable. But its utility is certainly not limited to that. It's one of the kind of features that a user may not immediately recognize the 'need' for, but will quite likely find many uses for once it is provided. Adding a button and a slider to a Boolean palette would not constitute excessive gratuitous tool-glut.

    If one thinks it through, it becomes evident that the so-called Merge Pathfinder is doing essentially much the same thing that the much later so-called Live Paint and Shape Builder features are doing. They're just doing it as a 'live effect' with an elaborate tool interface, instead of by a simple command. Much of Illustrator's tool glut boils down to 're-packaging' of existing functionality with more elaborate interfaces.

    On 2/18/2021 at 5:15 AM, loukash said:

    I vaguely recall that Freehand 9 had a dedicated trapping function.

    Of course it did. And I dare say, like many other things, it probably appeared before Illustrator's trapping functions. But FreeHand did not have a command akin to the one specified in this thread. The Merge command was one of the precious few positives in having to segue to AI after Adobe bought and killed FreeHand.

    I'd have to fire up the old bulbous pinstripe Mac G4 relic to verify, but something in my own vague recollection suggests that FreeHand's Boolean path operations could be made to incorporate manually-built traps.

    All this is why I continually argue that we need to think beyond Illustrator. Illustrator is just one of the old 'Big Four" (FreeHand, Illustrator, CorelDRAW, Canvas). A lot of redundant clutter lingers from the ad-hoc development since those days and elegance is lost when new offerings just 'copy what [historically] sells.' Elegance is achieved by providing fully thought-through and integrated functional power just beneath a clean, minimalist, but intuitive interface. The clutter of the older apps is nowadays nothing to emulate.

    My favorite example of the 'everybody now does it, so it must be right' fallacy is the now omnipresent confused, always-shifting, schizophrenic  'Bar' that can't decided whether it's a Tools Option Bar or a Commands Bar. Every graphics software developer should be required to understand and experience the advantage of FreeHand's incomparable Inspector Palette. (Closest thing to it in any program I use is in the Layout Mode of FileMaker Pro; a database program, of all things.)


  2. For those not familiar:

    Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:

    • It Unions touching (abutting or overlapping) fills of the same color.
    • It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others).

    So it results in the minimal individual paths around visually contiguous regions of the same color.

    One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.

    However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.

    The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.

    So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).

    Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.

    Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.


  3. For clarity, I certainly hope no one is asking for this to be a default behavior.

    I do not want an endNode of a path to auto-join to another path just because I drag it to within pick distance of another path's end. There are countless situations in illustration in which one draws coincident paths that should not be joined. Look no further than paths of different weights, color, or other style attributes that nonetheless need to have coincident ends. What about when more than two endNodes are coincident? How is the program supposed to know which path I would want it to auto-join to?

    The auto-joining behavior of Adobe Illustrator's Pen, for example, is one of its most infuriatingly intrusive stumbling blocks. To avoid its infernal insistence on auto-joining to other deselected paths when drawing, you actually have to invoke this ridiculous override:

    1. Mousedown somewhere that you don't want the next node to be
    2. Press and hold the spacebar
    3. Drag to where you do want it the node to be
    4. Mouseup
    5. Release the spacebar

    A path drawing tool is not a selection tool, and should not act like one. It has no business affecting unselected paths just because you need to place a node within pick distance of another path's endnode. Nor should it occur when just dragging an endNode.

    At most, any such behavior should have to be invoked by a keyboard shortcut. It should not be default behavior.

    The  task of cleaning up DXF files is an oft-cited use case, and one with which I am quite familiar, having been doing technical illustration since well before personal computers. But it's still a specifically vertical use case; nothing that should be cited to justify a default behavior. Other programs accommodate it with separate, explicitly-invoked menu commands. You select the paths you want to be affected and then invoke the joining command (with whatever parameters offered in a dialog). If that's what you're recommending, I'm fine with it. But auto-joining as default behavior is bad.


  4. 6 hours ago, Joachim_L said:

    There are a few more things inside such a plugin. And wouldn't it be nice leaving out the steps 2 and 3? Not only talking about saving some time, but also avoiding errors during export and import.

    There is a lot of functionality in a dedicated standalone cutting application, too. As for steps 2 and 3; no. That's what enables me to use the single familiar cutting / driving application with all the vector-based drawing program I have, and to use files provided by others outside my shop.

    But again, the primary advantage is avoiding mission-critical dependency upon a single drawing software 'host' for the plug-in.


  5. On 1/9/2021 at 12:56 AM, jimoz said:

    Has anyone found a way of solving this problem?

    I would really love to support Affinity and move away from Adobe.

    Cheers, Jimoz.

    This is why you're really better off using a separate standalone cutting software to drive your cutter, rather than using a plug-in that traps you into dependency upon a single general-purpose drawing program. My cutters are Rowland. But if your hardware is Graphtec, have you not looked into one of the  Graphtec Studio applications?

    With a separate cutting-prep application, you can use whatever drawing software you want, so long as it can export to a common vector file format that the cutting application can import. In the case of Affinity, that would be SVG, which is indicated on Graphtec's site as one of the formats supported by Graphtec Studio. You would:

    1. Do the drawing in Affinity
    2. Export as SVG
    3. Import the SVG into Graphtec Studio
    4. Set whatever device-specific options or features the software provides
    5. Send from Graphtec Studio to the cutter

    Typically, what actually drives cutters is just ordinary simple pen-up, move-to, pen-down HPGL instructions. So even when you use your Graphtec plug-in for Illustrator, what's really going on is, the plug-in is converting the Bezier curves to plotter language and then sending it to the cutter's driver.



  6. 11 hours ago, twopointoh said:

    I use illustrator to create tool paths for several different type of CNC machines including cnc plasma, cnc laser and cnc routers. Been doing this for quite a while and am over the Adobe subscription model. I was thrilled to stumble upon AD and immediately purchased it. Oh man, this is wonderful!!! The only thing I miss, and therefore can not totally eliminate Adobe from my world is the offset path function. I see that this has been discussed to death, but I still want to throw my hat in for wanting this feature. I am so hoping this will happen someday as this a a must in my field for machining parts and inlays. Pretty Please!!!!!


    The development of Affinity applications is being openly shared with the user community in the Beta section of this forum. If you download the current beta, you will find that an offset offset path function is among the things under current development.


  7. Live Text On A Path cannot actually be saved in a PDF.

    When you save a file as a PDF from Illustrator, you have the option to Preserve Illustrator Editing Capabilities. If you have that option turned on, Illustrator stores a full native copy of the content, stashed away in a 'cordoned off' area of the PDF file. That's why 'PDFs' saved that way from Illustrator are so much larger than if they are saved without that option on. If you then re-open that 'PDF' in Illustrator, Illustrator doesn't open the PDF content; it opens the stashed-away native copy. That's why the Text On Path object is still editable.

    When you save a file as a PDF from Illustrator with that option turned off, and then 're-open' that PDF in Illustrator, you will find that there is no live editable Text On Path.

    Affinity Designer does not 'open' native Illustrator files, just as Illustrator does not 'open' native Affinity Designer files. Both can export and open PDFs.

    Illustrator does the inverse with its 'native' .AI format: When you save a .AI file from Illustrator, you have the option to Make PDF Compatible. If you have that option turned on, Illustrator stores a PDF copy of the content, stashed away in a 'cordoned off' area of the .AI file. If you then open that '.AI' file with Affinity, Affinity doesn't open the native AI content; it opens the stashed-away PDF copy. That's why the Text On Path object is not editable.


  8. On 12/9/2020 at 3:27 PM, MichaelRojas said:


    It would be nice and useful if you add a function for extrude an object to make a 3D view. The isometric panel is complicated and time-consuming. And this features would be great if works with any object.


    Thanks a lot.



    This thread is about an envelope warping feature. If you search for "Extrude", you'll find other threads pertaining to what you describe.


    On 12/10/2020 at 3:32 AM, Oval said:

    Welcome here!

    You can find some answers here and there. Sorry, but they are not really encouraging

    Those threads are about 3D features. An extrude feature to "make a 3D view", for which Michael is relating to the Isometric Grids feature (2D construction), is not about a 3D modeling feature. Extrude features like in CorelDRAW and other programs are 2D constructs and therefore not ruled out by the Affinity team's responses that Affinity will not have 3D features.


  9. Feature requests need pro and con discussion and clear behavior description.

    Someone says "Please add a Live Paint Bucket Tool!" because the only other drawing program they're familiar with is Adobe Illustrator and they seem to think "Live Paint Bucket" is some kind of universally understood generic industry standard 'feature in a box' that a development team can just pick off a shelf somewhere and plug it in, when it's just Adobe's proprietary name for its own particular implementation of what is generically known as a flood-fill feature. So would the voting 'ballot' list four (or more) 'party' candidates?:

    • Live Paint Bucket Tool, identical to Illustrator's
    • Fill Bounded Areas Tool, identical to Inkscape's
    • Smart Fill Tool, identical to CorelDRAW's
    • Smart Vector Fill Tool, identical to Canvas's

    'Voting' features in an open public discussion forum are as silly as the user-created 'Poll' feature in a motorcycling forum I frequent. There's nothing scientific about them. Are we going to register to vote? What stops me from having a dozen login accounts so I can vote 12 times? What if 60% of the most experienced users are introverts who are simply disinclined to participate in such 'elections'? What if the majority actually making a living using the software are just too busy, or are not allowed to participate by their employers? What if the vast majority of users have never touched a 'Blob Brush Tool' because they can't afford Captive Customer fees and therefore they all vote "No"?

    What if the majority of the users have only ever used Adobe Illustrator and don't understand that things can be better than that?

    You really want the priorities of an application's development to be driven by mob rule? Building an innovative product that wins in the marketplace is not driven by simple democracy. Systematic development requires discernment about which functions comprise the most fruitful foundations upon which later higher-level features will depend. The best features are those which are cleanly integrated with each other so that the combined functionality is more elegantly powerful than just a collection of standalone functions. The feature that ends up truly 'putting an application on the map' and empowering its users the most may be something no one has ever dreamed of before.

    The 'voting' mechanism is already there: You can click the reaction buttons. Yeah, they could be re-named with terms less ambiguous. But the 'mob' can't even follow the most common-sense procedures:

    • Search for an existing feature discussion topic before starting yet another one. You're very unlikely to be the first person to ask for a 'Shape Builder Tool.'
    • Don't post 'personalized' lists of your pet features. If the topics don't already exist, start individual topics, so they can be sensibly discussed. No one is doing a search for a topic called "Joe Blow's wishlist" just because Joe Blow thinks he's someone special. No one is going to tediously dissect individual features from Joe Blow's wishlist post and move them to their appropriate subject threads. Joe Blow may have the most valuable contribution that no one else has ever thought of on a topic, but it will be forever lost because it's merits are stirred and shaken somewhere inside an unnavigable grab bag.


  10. Quote

    - Modal dialog boxes are ones that force a user to respond to them before the user can go back to using other aspects of the application.

    Illustrator, for example, has always been awash in old fashioned modal dialogs.

    22 hours ago, Alfred said:

    Although the linked article warns of the potential dangers of modal interfaces, it doesn’t actually argue that modes are a bad idea! It does say they are “usually good to avoid” but it goes on to point out that “modes can sometimes be helpful to control and guide input” and that they “may be appropriate when they are short and actively maintained by a user”.

    Correct. Interpreting the referenced article as 'putting an interface in modes is bad practice' is too broad a generalization.

    Working with Affinity's axonometric grids feature effectively puts all the tools in a different 'mode.' That's certainly not a bad thing.

    FileMaker Pro's interface has four modes: Browse, Find, Layout, and Preview. In Browse Mode, data is worked with in either Form, List, or Table views. One of its claims to fame is that its UI is arguably the most approachable in the database world.

    I'm not saying that Affinity's interface doesn't have some problems. I can say that any of its competitors' interfaces do, too, if I have an axe to grind.

    The biggest problem I have with Affinity in this regard is that its faux 'pages' are really just contiguous groupings within the object stack, like layers. Affinity is not the only program to do this, CorelDRAW being the obvious example. The problem is one of function; page-specific layers are really little more than another hierarchical level of groups, and nowhere near as versatile as they should be. But the frustration and confusion it causes is mostly due to Affinity's mixing of two metaphors; those of 'page stacking' versus 'page spreading'. Functionally, it's similar to CorelDRAW. But CorelDRAW's treatment inspires less frustration because it—wait for it—opens a modal window in order to view pages in a 'page-spreading' mode.


    Pixel Persona is unnecessary

    I don't really have any problem with Affinity's Persona views. I've seen more users applaud it here than dislike it. At this stage, I certainly don't think it's going away, and I expect it will be further exploited to help minimize UI clutter as more features are added or fleshed-out. Perhaps then it will feel more 'necessary' (justified).


  11. Two results encountered when moving a node close to another:


    Using its demo Pen Tool, I drew this by dragging out three 'nodes':


    Of course, you can't get that shape from three conventional nodes (2 segments). Look closely and notice that the solid and dotted handles of the green node are not parallel. The solid handle is not tangent to the segment that one assumes it controls; the dotted handle is. I understand; this is intended to be a new and innovative interface. But is it intuitive?

    Tracing over it, try to draw it in Affinity (or most any other mainstream drawing program) by placing three nodes and their curve handles as indicated above, and you get this (blue path):


    The stated use-case is ensuring curve smoothness when drawing font glyphs. That's all good and noble, but the auto-constraints advantageous in that context are not necessarily also desirable in general illustration. It seems to me that a more general implementation of this would need the auto behaviors to be momentarily switchable while in the process of drawing a path; not always active. How cleanly that could be implemented without increasing overall UI complexity and confusion is yet to be seen.

    Consider, for example, Inkscape's Spiro Mode feature. It, too, was designed to 'ensure smooth [circular] curves' as you draw with it. You put the Pen Tool into a distinct 'mode' to use it:


    As you use it, the interface makes it look like this path has two nodes. But clearly, that shape cannot be drawn with a single cubic Bezier curve (one segment). DoubleClick it while still in Spiro Mode and you see this:


    Now we see what looks like 5 nodes. But look at their direction handles. This isn't very intuitive either, is it? The user has no idea where those nodes are actually being created while drawing the original two nodes. Convert it to a regular path, and you get this:


    Now we see that it's 17 conventional Bezier curves (segments). Not anything particularly elegant and supple to work with if I need to modify it.

    Again, I'm not dismissing it, and yes, I understand it's a work-in-progress. But just based on what I can discern from the demo as-is, I don't see anything particularly ground-breaking here. Dinking around with its Pen tool, though, hindrances are imposed on moves that I commonly make for purpose. In general, I don't like features that try to 'read my mind' in anticipation of my intention; they tend to get it wrong more often than right. It's kind of like auto-tracing in that regard. It's an algorithm placing the actual nodes, not me.

    But wait! Isn't it an algorithm that's plotting the curves that I specify by placing nodes in the conventional Bezier interface? Yes, but consider:

    Someone uses this interface in designing font glyphs (it's stated target). Using the resulting font, I set some type in any mainstream Bezier-based drawing program, and then convert it to paths, intending to modify the outlines for a logotype. Whatever is going on 'behind the curtain' of this interface, the curves have to be interpreted to curves possible in my drawing program. If you've ever done that with TrueType fonts (which use quadratic Beziers) instead of Type 1 fonts (which use cubic Beziers just like your drawing program), then you know what kind of a mess I'm talking about; far more segments than one should have to deal with for elegant and tidy curve modifications. My guess is, this would be worse.

    FontLab expended serious effort toward Bezier interface innovation prior to release of its current version. It probably has the highest stake in the stated context. But the type designer using it is still looking at the nodes, handles, and curves that I'm going to get when I set some type and convert it to paths. I consider that a necessity.


  12. I hope someone noticed the motorcycle chain and tire tread in my two-decades-old Trials font. You know our shared disappointment of Affinity Designer's 'Vector Brushes' not really being what everyone expects vector-based brushes to be? Do you see the at least partial functional correlation between Illustrator's Pattern Brushes and what can be done with a custom dingbat font (which is entirely vector-based) when applied to text bound to a path? ;-)


  13. 2 hours ago, wonderings said:

    Not sure I get the correlation that you create logos and thinks in Designer that it is logical that you could create your own fonts with it as well. You would still have to create fonts separately outside of the logo design.

    I'm a life-long motorcycle guy. One of the things I've always admired about Honda is the way it has historically created its own demand for the things it builds. Another little company known for that is Apple. ;-)

    Suppose I create an identity package for Acme Coyote Co. It includes a logotype and several stylistically matching related dingbat graphics such as explosion bursts, dust devils, a road-runner's footprint, etc. In CorelDRAW I do not "still have to create fonts separately outside of the logo design." I can export those individual graphics directly from CorelDRAW into specific character slots in a font file that I name "AcmeFont". I can include that font file on the CD that contains all the other images, documents, graphics that comprise the project. The client can load that font on his or his secretary's computer and they can 'type' a logo with one keystroke anywhere they want in any office application they are using. I don't have to buy or use a separate font creation application for doing that.

    Here's an example. The glyphs were drawn in FreeHand and pasted into key slots in Fontographer. But the whole thing could have been drawn in CorelDRAW and directly exported as a ready-to-use font file because there's no need for kerning pairs or other esoteric settings that would be needed for, say, body text fonts:



    I just don't think there is a high demand to be able to create fonts in Affinity software.

    There's a lot of things worth implementing in mainstream drawing programs that conventional wisdom does not presently consider 'high demand'. Not to hijack this thread from its topic, but just by way of example:

    Currently, my foremost desire for Affinity Designer is the ability to rotate a bounding box relative to its content. Why? Because Affinity designer is one of those programs determined to make on-page transformations dependent upon infernal bounding boxes instead of providing transform tools. Why the assumption that if I need to disproportionately scale a selection, I only need to do that in the two perpendicular directions of its bounding box? I very often need to scale a selection while in its current rotational orientation in a diagonal direction that does not correspond to the bounding box handles. So why can't at least one of the ridiculously redundant five rotation handles on its bounding box (the silly lollypop handle being the obvious candidate) allow me, with the press a modifier key, to freely rotate the bounding box about its content in order to thereby orient the scale handles to the direction in which I need to scale the selection?

    I've never heard anyone else ask for that, either. That doesn't mean countless others wouldn't find it invaluable, too, once delivered.


  14. 9 hours ago, Alfred said:

    It was possible to export to TTF way back in the days of CorelDRAW! 3.0…

    It's still there. Type 1 format, too. Screenshot of CorelDRAW 2020's export dialog:


    Even though Fontographer 1.0 was actually my very first exposure to Bezier-based drawing, I've always applauded Corel's inclusion of this. It can be a wonderful thing to have in a drawing program; not necessarily for full-blown typographic fonts, but for monospaced 'clipart' fonts. It's always been quite common for the actual glyphs of fonts to be drawn in mainstream Bezier-based drawing programs, even when the font file itself is built in a full-blown font program. So, like Corel, why not provide bare-bones basic exports for a couple of formats?

    Like Alfred, I wouldn't make it a priority for Affinity, with so many other far more immediately important things still under development. But having said that, the fact that actual typographic font design is quite involved does not render it inappropriate for a mainstream general-purpose Bezier drawing program to provide a couple of basic font file format exports. (One thing that comes to mind is that it could be a boon to embroidery hobbyists.)

    It can still be a very handy way to provide a company with cross-platform, accurate, scalable vector graphics requiring no real learning curve to empower office workers to insert identity marks into internal and external documents or databases. Many of the identity packages I've built for clients have included custom standalone fonts or modified copies of their style guide font with their logos (when appropriate)—and often additional secondary elements designed to go along with them (custom bullets, etc.)—for just that purpose.

    One of my very first vector-drawing projects was the creation of a PostScript font that served to automate the creation of data-driven diagrams in a Hypercard stack for configuring the body sections and seating plans for school buses. The live profile drawing of the bus was actually alpha-numeric characters of a calculation performed on entered variables, merely displayed in the special font. The drawing auto-updated as the myriad of order parameters were entered.

    On the one hand, one can argue that open SVG makes vector spot graphics more available to office applications, database programs, etc. On the other hand, that's still more tedious for an office worker than simply typing a particular character in the font that the Marketing department has specified as the company's standard. We're still waiting for SVG fonts to become mainstream and for a font format to support open paths (so-called 'single stroke' fonts). So exporting font formats is still arguably as appropriate for Bezier-based drawing programs as even before.

    So, no, I'm not saying drawing programs should be full-blown font creation applications. Quality font creation, and the applications built to facilitate it, continue due to a relatively tiny community of dedicated and highly skilled typographers who are worthy of support from professional illustrators and designers. One of the nice things about having a copy of Fontographer or FontLab is that you don't find it time to upgrade every few months. Another is that FontLab now has some of the most innovative ideas in vector path interface design. Any serious vector-based illustrator can derive a lot of delightfully 'new wrinkle' thinking from just dinking around in it. Any illustrator or designer particularly interested in typography should consider it a matter of professionalism to at least have a working knowledge of such things as kerning and why font glyphs are sized by measures relative to their em squares, not by the numbers you key into the illustration or design program. Font design programs enable you to 'see and touch' such principles, even if you have only infrequent need to build or modify fonts.

    Altsys Fontographer was part of the deal when Macromedia acquired Aldus. Fontographer became one of the applications bundled with FreeHand Graphics Studio. When Adobe acquired Macromedia, Fontographer was saved by its being acquired by FontLab. Fontographer 5 is still sold by FontLab today for $259.



  15. On 12/21/2020 at 6:40 PM, MJSfoto1956 said:

    I too am frustrated that the length of a simple line segment cannot be measured in Affinity, even though the math behind is pretty basic stuff. i.e. Diagonal = sqrt(Height^2 + Width^2) is all you need to know. Draw your line segment. Select the line object. In the info box note the height and width of the object's bounding box. Plug the height and width dimensions into the above formula and you will have the diagonal.

    Please add this feature!

    Simply providing the measure of straight segments would be already sub-standard. No, it's not as simple as the Pythagorean Theorem, but we're one-fifth into the 21st century. Length (and area, frankly) should be shown for any path, as it is in competing software.


  16. My interest in true vector-based brushes is not to emulate 'painterly' strokes, but to more powerfully leverage the base purpose and advantage of vector-based drawing in the first place.

    As always, this is definitely not exactly what I have in mind, because I want something better.

    Shown are just two of my own Pattern Brushes collections; hex head bolts and springs. Each Brush can turn a single-segment straight path into a bolt or spring of any diameter and any length with a single click.

    However, building such constructs is much more tedious than it should be for several simple reasons:

    • Note that I have a separate Brush for each orientation (5° increments of rotation about an isometric axis). What makes all that setup work necessary boils down to a couple of simple geometric transforms that could and should be built into the Brush feature's options. (Think of the parameter adjustment handles in Affinity's various live Shapes for a general idea of what I'm talking about.) A better implementation would make this whole array possible with just 2 brushes instead of with 36.
    • Note that the size of Illustrator's vector brushes (therefore, the diameter of the bolts) is controlled by adjusting the stroke weight setting of the spine path. But there is no option for leaving the stroke weight of its Brushes' base artwork alone. So in order to have consistent stroke weight in an overall drawing that has multiple differently-sized bolts or springs, one has to 'Expand' the 'Appearance' and then apply previously-defined Styles. This is a typical example of Illustrator's failure to integrate separate features with each other. Illustrator's Symbols do provide the much needed option to toggle off "Scale Stroke Weight When Scaling". So why isn't that option provided in its vector brushes?
    • And why can't Symbols be uses as the base artwork in Brushes?

    Again, these are just two such collections. I have similar vector-based Pattern Brushes for "lasso arrows",  insulated wires with color banding, wire rope, wire loom, square tubing, piping, and more. To someone who does a good bit of technical drawing, the tedious bother is 'worth it' in the long run. But it could be done so much easier for users with a better thought-out implementation. Just more 'low hanging fruit' opportunity to beat Illustrator, rather than just mimic it.





  17. On 12/6/2020 at 10:24 AM, Jowday said:

    Also notice the very obvious lack of professionals here. And the abundance of fanboys and apologists.

    Again, climb down off your friggin' pedestal, mister 'professional.' You don't know diddly about the careers of other people here. Since the Affinity programs are just for poor rank 'beggars' so beneath you , why are you wasting your time here, incessantly spouting your ridicule? How does someone of your obvious (because you say so) time-is-money 'professional' status have a productive moment to lose dinking around with a $50 program that's obviously going nowhere (because you say so)?


  18. 2 hours ago, Bryan Rieger said:

    So, I wouldn't exactly equate 'enterprise' with 'professional', but hey—if that's your experience then that's your experience.

    Right again. So-called 'enterprise' applications (ERP, PLM, etc., some costing a company literal millions of dollars) are commonly just very vertical-market targeted solutions built by relatively tiny companies. Yes, they are typically built upon a robust database development platform but nonetheless commonly have cumbersome 1980s-era interfaces that constrain users to inflexible, clunky, even non-standard tedium that doesn't come close to the modernity of products built by developers of mainstream, blister-packed, over-the-counter software. That's why so-called 'middleware' is a growing segment. 'Enterprise' applications have high cost largely because they are vertical-market, not necessarily because they are of 'professional' quality.

    No, Affinity does not yet have every tit-for-tat feature for every other application in its competitive segment. The inverse is also already true, and the competitive differences exist and will continue to narrow, just as they always have, even before Affinity came on the scene. But Serif seems to be doing well and has had a significant impact with a modern pricing model, while competitors still cling desperately to outdated over-pricing based mostly on mere brand recognition.


  19. 4 hours ago, Bryan Rieger said:

    A software suite that used to costs thousands of dollars roughly every 18 months, can now be had for…

    Correct. I paid $650 for the first three-color (CMY; no K) HP Color Deskwriter and thought it was a 'steal' at the time. Nowadays, of course, far better printers using the very same underlying technology are sold at or below cost just to sell customers the ink cartridges.  I paid around twice that for my first 35mm transparency scanner.

    As I've said elsewhere, the pricing schemes of Adobe Illustrator, CorelDraw, and Canvas are long outdated. 2D Bezier-based drawing isn't rocket science anymore. But the old vendors are still clinging to the pricing models of the 80s, when it was all new.

    Again, I'll cite the axonometric feature set in Affinity as example. Closest thing to it from the 'royal family' of software vendors is Corel Technical Designer ($1000). I still maintain my license to it, and will probably continue to do so as long as Corel continues to sell proper perpetual licensing. But that price is largely 'artificially' inflated by the vertical market it targets. Corel probably has to pay ridiculous royalties to vertical-market CAD/CAE vendors for the hooks it has for importing and flattening proprietary model formats. In fact, you have to pay $5000 more for an add-on if you want to do the same with CATIA and Solidworks files. (Solidworks offers its own proprietary utility application for merely doing just the same "rotate and flatten" thing, but it's far from a full-blown general-purpose 2D vector drawing program.)

    Set that vertical-market proprietary-format-protectionist price-inflating  junk aside, though, and the core differentiating functionality of interest—explicitly facilitating accurate axonometric drawing—is pretty much matched in Affinity Designer, making a drawing discipline too-long considered 'vertical market' more approachable to all the 'rank amateur' freelances who are energetic enough to expand their illustration repertoire.

    The 'dirty little secret' is: Mechanical engineering entities all over the world that use 'high-end' CAE systems still very commonly use mainstream 2D vector drawing programs when the presentation needs to be of higher commercial illustration quality than the archaic polyline 2D DXFs output from those 'exotic' systems. In fact, there's a whole industry of contractors serving the free world's military's needs for cleaned-up technical documentation, and those contractors use familiar mainstream 2D vector, raster, and page assembly applications.

    Because it's a particular specialty and passion of mine, I can do axonometric drawings in most any mainstream drawing program, using my own methodology I've devised over the decades. And you can't tell whether I've created such a drawing in Illustrator, Draw, Canvas, FreeHand—or Affinity. But it will generally be of better quality than what you can just export from Solidworks.

    So no, lower prices than intentionally 'vertical market' applications does not necessarily reflect 'unprofessional' software.


  20. 13 hours ago, Marder said:

    Serif knows this. They would never sell the program at this price level if they really targeted true professionals.

    Sounds very like every dismissive comment I heard from the sales execs of pre-press 'color houses' in the 80s from across the client-stroking luncheon table whenever the topic of Macs, Postscript, and desktop applications came up—the beginning of the time frame during which color houses started dropping like flies. ;-)


  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. 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.