Jump to content
You must now use your email address to sign in [click for more info] ×

Search the Community

Showing results for tags 'curve expand'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Affinity Support
    • News and Information
    • Frequently Asked Questions
    • Affinity Support & Questions
    • Feedback & Suggestions
  • Learn and Share
    • Tutorials (Staff and Customer Created Tutorials)
    • Share your work
    • Resources
  • Bug Reporting
    • V2 Bugs found on macOS
    • V2 Bugs found on Windows
    • V2 Bugs found on iPad
    • Reports of Bugs in Affinity Version 1 applications
  • Beta Software Forums
    • 2.5 Beta New Features and Improvements
    • Other New Bugs and Issues in the Betas
    • Beta Software Program Members Area
    • [ARCHIVE] Reports from earlier Affinity betas

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Location


Interests


Member Title

Found 1 result

  1. 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.
×
×
  • Create New...

Important Information

Terms of Use | 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.