Jump to content

Steve_N

Members
  • Content count

    16
  • Joined

  • Last visited

About Steve_N

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Apologies, just noticed I posted this on a MacOS thread. But may be worth mentioning this same thing is happening on Windows.
  2. Finding this SVG/EPS 'pixel' display default a pain here. Have also noticed strange things with changed graphic dimensions of re-imported SVG's. In addition, AD does random weird things when printing layout files to our laser print software. For example, every now and then it will 'print' a file to the spool with a stroke (cut line) massively thicker than set. This then makes the cutter completely ignore the line on the job material. I often need to export to an SVG then re-import into AD for the cut and engrave lines to render as intended. Having to reset the measurement default type for every triple handling layout file is one extra time killer.
  3. Steve_N

    Affinity Designer for Windows - 1.7.1

    Thanks for clarifying and for adding it to the list.
  4. Steve_N

    Affinity Designer for Windows - 1.7.1

    Hi Patrick, Will upgrading this release patch reset custom interface settings similar to the 1.6.5 --> 1.7 upgrade? Thanks
  5. My Apologies, I mistakenly believed this was the affinity@serif >> Designer Beta on Windows forum. Where adding collective voices for function we would like to see in the program, is the most effective avenue suggested by the development team. It's ok, email seemed to be the better channel.
  6. It is important to help users make informed decisions. However, I really hope the team do not view this post as another attack. Rather an articulate voice of inquiry considering where Serif are aiming to position these products in the market moving forward.
  7. Dear Affinity Team, I'd like to preface this post by first outlining that you should be very proud of the care you take in delivering programs with a good user friendly UI. I respect and thank you for that aspect. Unfortunately though, as a newer customer of both Designer (and Photo), I would like to express my frustration and confusion over the absence of two functions in Designer: 1. Curve/Path offset. 2. Accurate, reliable stroke expanding. I really am not wanting (or aiming) to appear as another "me too" whinge over these two hotly argued shortfalls. But I am having immense difficulty reconciling why in this day and age, a vector program would not have the above as integrated, flawless core operating actions? I can't help but restate the obvious here, it's not 1999 anymore. Stakeholders at Serif: You are not competing to "see" if you can be the first vector software developer to implement a wiz-bang new feature which will soon allow designers to "offset a path"! It has already been in use as a solid operating function for users of design programs for almost a decade and a half (maybe more). This is not a "feature request" or "program bling". In 2018 it's as embedded in the vector creation process as the foundational mathematical curve points are. It's like building a car, and proclaiming that wheels are optional becsuse you can start the motor without them. So why sleep on it and continue to avoid biting the bullet? If it's simply because you need to capitalise on "hotter" revenue development avenues (ie iPad versions) for cashflow reasons, then with all due respect, that should not be a sacrifice paying user are expected to make. However, despite the justifications or reasons (which could be argued endlessly from both user and dev perspectives), the one underlying fact remains; If you are charging money to compete in a market as a "ground breaking vector program", isn't it your responsibility and within your best interest to at least deliver the current expected level of functionality that everyday professionals use and rely? Do you really want to alienate that many prospects? I'm sure you don't and I know that nobody can force you to make these happen, but that's not really the only issue at play here is it? Yes, I can understand and appreciate the pressures and economics of development and re-tooling code, and the financial bourden of adding features then fixing bugs. And yes, I value and understand your desire to do things both "right" and "unique" with AD to separate your offerings from the crowd. But if those things amount to a program that has budding and professional graphic artists alike doing constant time sucking workarounds for everyday tasks, then what is so ground breaking about it being brought to market? Ground breaking should not equal "modern essential functions innovatively omitted". Should it? I can't help but notice a common theme on the forum, where it's almost expected the customer concede and accept vagueness on core functionality delivery. An almost "we should not be held accountable for what we do, or do not deliver". Maybe your completely overwhelmed and under-staffed, maybe your not! We don't really know do we? But, at risk of sounding a little indifferent, we are not shareholders in the business with you. It's not our role to know. We paid money for an advertised cutting edge design tool. You expected remuneration for your product, then that IS your role; to deliver that product. I would argue that a vector prgram without a usable expand AND offset function is not actually a vector program. Hard as this is to for you to make happen and embrace, you have decided that you can deliver. I can imagine it must be tiring and relentless feeling like customers are barking expectations at you through forum posts constantly. I can empathise with that as I'm sure often it's not pleasant. Although this can't dilute the reality of what users would expect they are "buying into" versus what's delivered. Users should not be required to beg for essential modern, core functions. Users don't expect to pay money for enhanced, ground breaking workflow then go backwards with time consumption. People pay money to have "things" solve problems and save time. As wiser people than me have observed about life; age is not our enemy, time is. So why force users to spend so much time trying to make functions exist where they clearly haven't been programmed to? Would it be too much to ask if you kindly provide customers the coutesy of when you will implement functional "curve/path offset" into Designer? I have been trying to find ways to bounce files between my 12 year old version of Illustrator (I do not enjoy using that program for outlining) for the one path offset process. But the challenges are too many and important layout elements get lost/altered in the EPS saving/transferring/offset/resaving process. Getting designs setup for the type of work I believed I could do with Designer has become a logistical nightmare. Using the demo for it's full duration didn't reaveal the shortcomings either, as I was focusing on trying to get know the things it could do well. Could I also please request of users who read this. Be mindful before posting with "expand stroke works fine for me". I have relentlessly tried to "squeeze" everything I can out of that function, but it is essentially useless for the kind of accuracy and complexity of work I need it for. It's limit of use for me has well and truly been exhausted. And FWIW: it is pointless attempting to think of using it for kerf compensation. Especially for complex "shape within shape" designs. I am also willing to accept you may completely disagree with my observations here. I won't disrespect that. All the best in your endeavour.
  8. Bingo . Thank you @R C-R for addressing the question asked. And @gdenby for eluding to it in your first response. As R C-R reiterated, the intent of this post was not to seek further workarounds in lieu. I am already employing the approximations, which is WHY I'm asking for the needed cleaner, faster option. Have a great day everyone. I will see if I can find out more about the 1.7 roadmap and beyond.
  9. Hello Developers and Mods, Almost 2 years ago a user posted this question which I'm hoping in this time has been addressed: I know that snapping to geometry is in effect with 1.6.5, but this still does not address the above. Was the ability to precisely create 2 node points at the intersection added to Affinity Designer? If not, when and why? Zooming in and out (to very large scale) is very time consuming when you have many intersecting points and shapes to create and edit. Not to mention, it's a non-exact work around at best for something which I assumed would be a vector work standard function. Thanks for reading.
  10. Yessir, I do. Ah, now I see the confusion. Yes the acciedently posted image was a version before sorting out the anomolies. For some reason images from our older interactions were added back into the post, even though I removed them. It wasn't visable when I hit send. Anyway, I went back in and edited the post.
  11. @JimmyJack Cool, although can you define what you mean? Are you referring; It's still offset after getting it to replicate your outcome, or am I missing a different reference?
  12. Hi folks, I wanted to take a quick moment to thank everbody for their help and suggestions on getting this done. I thought it would be the right thing to do to add info that worked for me in the end. Also, a big thumbs up to @JimmyJack for going above and beyond with some off-forum assistance. This really helped shed some light on a few program oddities while getting accurate sections. For anybody looking to do this type of process while preparing files for laser cutting, basically Jimmy's post above with the four steps is essentially what will get you there reasonably quickly, but with a few specific caveats which I experienced (your mileage may vary though): 1. Make sure before you expand stroke, you have stroke set to solid line. This is probably obvious to most, and although I remember setting mine to solid, somewhere through the process it changed to "brush" and this gave different/inconsistent results (this makes sense since the brush will have variation on the edge feathering and distance). 2. Be very specific about the line width when resizing up to get accurate paths following the stroke. For me, I needed the section to finish up with a 0.1pt stroke for the cutter to follow. So I had to make sure I manually changed the stroke width to x20 (2.0), so that when I did an exact x20 resize of the image, it would be exactly 0.1pt when scaled back down. If I used "scale with object". I ended up with a 2.1pt stroke instead of 2.0pt. Odd but true. Something tells me that the results may be slightly different depending on the original size of you artwork to begin with. 3. When resizing the artwork, keep the expand anchor point set to centre. Again, this may or may not be obvious to more seasoned illustrators, but I seemed to get ever so slightly different results when the anchor point was set to top-left as opposed to the centre. Many thanks.
  13. Ok thanks Jimmy. See above, you keep beating me to a reply
  14. Great post also Jimmy Jack. I'll need to sit down and experiment with all of these suggestions to see how i can streamline it for how my brain processes things (often it's just in buffering overload mode ). I'll post back here once i've had time to go through it all. Thanks everyone for your thoughts.
  15. Thank you gdenby. Responses above in dark orange. Thanks firstdefence. I hear you on all your points. - - - - - - - - - - - - Here's what the laser cutter specifies as vector file requirements. 3 colours: red = cutting, black = raster etching and blue = vector etching. The red cutting line is 0.1pt. And I'm ok with getting that all setup for them. As expressed by most of you above, my initial challenge was trying to decide if I should outline the total image first, then add internal section lines, or vice-versa. In the end I just did whatever flowed then have planned to break and join paths as necessary. Sections like around the eye will have a combination of small acrylic pieces with etched indents that end up painted. Like the pupil, curved line under the eye and the foot-claws. I can see that the sectioning process is going to take a lot longer than initially hoped.
×