Jump to content

Lmpessoa

Members
  • Content count

    36
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Lmpessoa got a reaction from Hesh-Art in Plugin-Support for Designer   
    I'm trying to draw a bit of attention to a very simple API but one that could be really powerful. I believe the more support it gets better the changes we are heard this time.
     
  2. Like
    Lmpessoa got a reaction from Hesh-Art in Plugin-Support for Designer   
    I would not count with support for any existing plugin for any other app. Adding support for plugins is already hard enough; adding the same support provided by another platform requires an additional layer of code translating what the plugin expects to what the program actually provides and little can be done if there is anything the program cannot/will not support.
    When plugins are supported by the Affinity suite, I expect nothing different from it supporting their own set of plugins and providers of existing toolsets may choose to port their code or not. But remember once the door is open others may provide similar or even better extensions.
  3. Like
    Lmpessoa got a reaction from SrPx in affinity designer export to illustrator   
    This is not an easy issue. Nowadays the AI file is a PDF file only serving as an envelope for the actual AI file contents. While the PDF part is well documented and easy to read/write, the AI stream is proprietary and undocumented, including an undisclosed compression method, making it harder to be read/written. AfD can read AI files by reading the PDF envelope, not the AI stream in it (but files must be saved with the option to create a PDF compatible file, even thou it is always a PDF file or you will only see garbage after importing). It would require a large effort of reverse engineering to allow any other application (not just AfD) to export AI files so I wouldn't expect this any time soon (although someone might be try and solve it if a plugin architecture were available).
    Right now what you can do is export the files you work with your team in another format supported by both applications like EPS, SVG or even PDF.
  4. Like
    Lmpessoa got a reaction from July-Nov in Request 2D CAD Persona   
    +1
    I sure would love some of these too. For me in particular I've always missed a trim tool in similar apps (maybe it is due to my background in CAD but they sure are handy). I don't really think we need a "CAD persona" for that, all we need is a few additional tools. Some like drawing using a bit more of math could be achieved through 3rd-party extensions but it seems those aren't really a top priority at Serif.
  5. Like
    Lmpessoa reacted to rmhaarlemmer in Epub   
    Hi, I am missing epub as well. Hope you people from Affinity are going to add this soon...
  6. Like
    Lmpessoa reacted to DaveE in Dimensions tool in Designer   
    Great to see the new features in the latest release of Designer, well done Development Team.

    A 'Dimensions' facility was a much talked about and requested for addition to the Designer back in 2015; search for the thread started by by tabtabai on 15th October 2015. 
    I believe this facility should once again be brought centre stage for inclusion at the earliest possible update.
    Thanks.
  7. Like
    Lmpessoa got a reaction from m.vlad in API Think Tank   
    I've been following the forums for a while now since I've decided to switch from the "A" suite and, of all the features requested by users, the most are support for a given file format. Also some users have been heavily requesting for an API they could use to automate stuff (or build stuff - some ideas also came to my mind while writing this) and I think these could be handled with a little bit more of effort in building an API. Since most programming languages are object-oriented I'm also thinking in such terms while I write, however I'm not being specific on language.
    I believe two kinds of plugins could be allowed: SCRIPTS, which would only help in automating repetitive tasks (think about closing a document for printing) and mostly would only manipulate the document without any sort of argument, and PLUGINS, which would be developed on a chosen platform (I'm pretty sure the Affinity suite relies on .NET) and would enable usage of every feature the platform has to offer. This dual approach is adopted by apps such as ZWCAD and could be great for different uses but it is not a mandatory thing.
    As for the API itself, the idea would be to enable means to programmatically:
    access a document (either by creating a new one or retrieving one currently open), layout the document (creating slices on AD or new pages on AP, for example), create, retrieve, modify and/or objects in the document (create shapes, change attributes like colour, add text, etc.), request users to select objects or a point on the document (to ask the user where action will take place). Basically that is allowing anything on an app to be done programatically (yes, with the right script, one could simply automate a complete complex drawing, I'm not asking why would you). I'm thinking of basic object-oriented programming here:
    // in some pseudo language doc = new document rect = new rectangle object set brush in rect to X add rect to doc ... I'm also well aware the amount of effort and code required to implement this API so I'm not expecting this to be available tomorrow (or in the next version) but I think we'd have to start gathering ideas about this somewhere. Here are some examples of what I would expect that could be achieved with this API:
    import/export to X file format (PLUGIN): triggered by selecting a file in a recognised format, it would (1) read from a file and create a document and the objects in it using the API representing the contents of the file or (2) traverse a document (or a slice of it in AD) and write it to a file in the chosen format, QR code (PLUGIN): it would open a dialog for the user to enter the info on the QR code (format version, size, tint, text, etc.) and create a group of rectangle objects based on that info. After that, it is just a series or rectangles and does not depend on the plugin (of course this approach does not allow the QR code to be edited, or even its info to be viewed, but I'm sure some other approaches can be taken - like storing arbitrary metadata on objects and groupings and even restricting some of these to be undone), create a draft in PDF format (SCRIPT): this would just add the word "DRAFT" in the background of every page (in a publication - to the original or a copy of the document that exists only in memory), trigger the export to PDF function (it is already embedded on the app, so why not make it accessible) and then remove the "DRAFT" word from every page (since it is not meant to be part of the final document). This could also be done as a PLUGIN if one would like to specify the tag text and colour. Perhaps the biggest concert of Serif in providing us an API is related to security/privacy of its users and that's a noble reason for not releasing an API yet. Of course PLUGINS could be more dangerous than SCRIPTS from this point of view since they have a broader access to the native API of the platform (from enumerating/reading/writing files arbitrarily, to spanning threads, to sending data over the internet) but I've never seen anyone complaining about those issues on Photoshop or any other app that enable the use of plugins. You choose to use plugins from a reliable source and Serif could even be a curator for one of those reliable sources, but nothing mandatory.
    Another solution to this (and this would take a more considerable amount of time) would be Serif to create a full development platform with each and every API exposed (file access, document access, etc.) in order to minimise the existance of malicious plugins (and someone will always find a way to bypass it, trust me) and restrict programming languages to the one Serif itself choses (I'm not really fond of it but it seems the most claimed in the forums is Javascript). I could live with that with the right API.
    I'm not in anyway affiliated with Serif and I don't know if they have already decided on any of the issues I raised and my intent here is not to discuss the exact implementation the API will take (thou it could certainly be fun) but to gather opinions on it, specially on whether the API should use an open platform or a more strict one to prevent malicious extensions, and to gather things people would be interested in doing with the API and are not sure I covered above. I would also like if this space were to be used by Serif to talk to us about how they view the issue of the API and how/when they are planning to handle it and to it discuss with us in order to create something really useful for everyone.
  8. Like
    Lmpessoa reacted to July-Nov in Request 2D CAD Persona   
    Would it be possible to have a 2D CAD persona added to designer?
    The current persona is great for artwork, but the addition of CAD tools such as creating circles using tangents and extending/trimming lines would be useful. for plans.
  9. Like
    Lmpessoa got a reaction from m.vlad in API Think Tank   
    I've been following the forums for a while now since I've decided to switch from the "A" suite and, of all the features requested by users, the most are support for a given file format. Also some users have been heavily requesting for an API they could use to automate stuff (or build stuff - some ideas also came to my mind while writing this) and I think these could be handled with a little bit more of effort in building an API. Since most programming languages are object-oriented I'm also thinking in such terms while I write, however I'm not being specific on language.
    I believe two kinds of plugins could be allowed: SCRIPTS, which would only help in automating repetitive tasks (think about closing a document for printing) and mostly would only manipulate the document without any sort of argument, and PLUGINS, which would be developed on a chosen platform (I'm pretty sure the Affinity suite relies on .NET) and would enable usage of every feature the platform has to offer. This dual approach is adopted by apps such as ZWCAD and could be great for different uses but it is not a mandatory thing.
    As for the API itself, the idea would be to enable means to programmatically:
    access a document (either by creating a new one or retrieving one currently open), layout the document (creating slices on AD or new pages on AP, for example), create, retrieve, modify and/or objects in the document (create shapes, change attributes like colour, add text, etc.), request users to select objects or a point on the document (to ask the user where action will take place). Basically that is allowing anything on an app to be done programatically (yes, with the right script, one could simply automate a complete complex drawing, I'm not asking why would you). I'm thinking of basic object-oriented programming here:
    // in some pseudo language doc = new document rect = new rectangle object set brush in rect to X add rect to doc ... I'm also well aware the amount of effort and code required to implement this API so I'm not expecting this to be available tomorrow (or in the next version) but I think we'd have to start gathering ideas about this somewhere. Here are some examples of what I would expect that could be achieved with this API:
    import/export to X file format (PLUGIN): triggered by selecting a file in a recognised format, it would (1) read from a file and create a document and the objects in it using the API representing the contents of the file or (2) traverse a document (or a slice of it in AD) and write it to a file in the chosen format, QR code (PLUGIN): it would open a dialog for the user to enter the info on the QR code (format version, size, tint, text, etc.) and create a group of rectangle objects based on that info. After that, it is just a series or rectangles and does not depend on the plugin (of course this approach does not allow the QR code to be edited, or even its info to be viewed, but I'm sure some other approaches can be taken - like storing arbitrary metadata on objects and groupings and even restricting some of these to be undone), create a draft in PDF format (SCRIPT): this would just add the word "DRAFT" in the background of every page (in a publication - to the original or a copy of the document that exists only in memory), trigger the export to PDF function (it is already embedded on the app, so why not make it accessible) and then remove the "DRAFT" word from every page (since it is not meant to be part of the final document). This could also be done as a PLUGIN if one would like to specify the tag text and colour. Perhaps the biggest concert of Serif in providing us an API is related to security/privacy of its users and that's a noble reason for not releasing an API yet. Of course PLUGINS could be more dangerous than SCRIPTS from this point of view since they have a broader access to the native API of the platform (from enumerating/reading/writing files arbitrarily, to spanning threads, to sending data over the internet) but I've never seen anyone complaining about those issues on Photoshop or any other app that enable the use of plugins. You choose to use plugins from a reliable source and Serif could even be a curator for one of those reliable sources, but nothing mandatory.
    Another solution to this (and this would take a more considerable amount of time) would be Serif to create a full development platform with each and every API exposed (file access, document access, etc.) in order to minimise the existance of malicious plugins (and someone will always find a way to bypass it, trust me) and restrict programming languages to the one Serif itself choses (I'm not really fond of it but it seems the most claimed in the forums is Javascript). I could live with that with the right API.
    I'm not in anyway affiliated with Serif and I don't know if they have already decided on any of the issues I raised and my intent here is not to discuss the exact implementation the API will take (thou it could certainly be fun) but to gather opinions on it, specially on whether the API should use an open platform or a more strict one to prevent malicious extensions, and to gather things people would be interested in doing with the API and are not sure I covered above. I would also like if this space were to be used by Serif to talk to us about how they view the issue of the API and how/when they are planning to handle it and to it discuss with us in order to create something really useful for everyone.
  10. Like
    Lmpessoa reacted to SpongeBob in Measuring a path and other measurement tools and guides   
    Hi Team,
    I also use AD to draft clothing patterns and other work where measurement is of supreme importance and work has to be precise. Features that will help with this are missing in AD. I'm sure you are adding and will keep adding features;  I would realllllly appreciate it if you could bring these features to AD soon. I'm dependent on it to use them for my work and it's absolutely necessary.
    Following are some scenarios and features that I think will help;
    1) Using pen tool, when I click a point and move my mouse/cursor etc, I want to know the measurement of how far I'm going; so I'll know when to stop and click my next point.  Similar to how some of the dynamic guides work.
    2) When I select a series of nodes on a path, I want to know the length of that curve or line.
    Without these two, for me it's not efficient to work in AD and is too time consuming to get the results I want..Hope to see these in AD updates soon..Thank you very much!
  11. Like
    Lmpessoa got a reaction from Jowday in Get correct document icons here   
    This would work mostly for macOS only since it is a little tricky to convert ICNS to ICO.
    I've been into this topic myself (just recently acquired AFDesigner) and agree with this but I wanted the icons to be a little bit more stylish and would like to cover the possibility of associating the apps with additional file types, if the user does not have another app for handling them (like SVG, IDML, AI or PSD). Also, it seems you didn't cover AFPhoto in your set.
    Well, here is my version:

    Instead of uploading ICNS or ICO files, I'd rather share my AFDESIGN file, fully editable and copyleft so anyone can work and enhance them and Serif may consider them as part of their copyrighted intelectual property and to use them (or any variation) if they please.
    branding.afdesign
  12. Like
    Lmpessoa reacted to Thomahawk in Get correct document icons here   
    Very good, Lmpessoa. Thanks for posting this.
    I like yours even more than mine. You do really understand what GUI standards mean and how usability and intuitivity work. I dont understand affinity here on this. Not following established standards makes no sense. We have a GUI to use it, not to make it a mess.
    Right, I did not include the AF photo, because thats the one exception where I prefer the thumbnail. However, I still did not get to work it in OS X Mojave for desktop or symbol view, the right icons only show up in list view.
  13. Like
    Lmpessoa reacted to Ulysses in New Icons - PLEASE DON'T!   
    Lots of us agree! The current icons are pretty cool, dramatic, and different. They're very distinguished from other icons in the dock.
    But compare with currently shipping icons with the ones that seem to be proposed in the beta. I'm not as crazy about them. Are you? They're a bit flatter, less colorful, and just not quite as interesting (sincere apologies to the team who designed these... no personal harm intended) No, they won't make the software run better or worse, but it would be nice to see icons we like.   
     
    P.S. — Affinity Team, it looks like the Designer app icon is a little bit different from the rest in that it doesn't have the little bump-out on the top side the way the other two do. If this icon design is where it's headed, at least make them consistent with the bump-out. Give us a little STYLE!     

  14. Like
    Lmpessoa reacted to Ulysses in New Icons - PLEASE DON'T!   
    Really enjoying the suite of software otherwise, though. Keep up the good work, Serif Team.  
  15. Haha
    Lmpessoa reacted to TonyB in Affinity for Linux   
    We would only make a Linux version if we were confident we would recoup the $500,000 it would cost us to build it.
  16. Thanks
    Lmpessoa reacted to Patrick Connor in Affinity apps in different versions   
    The studiolink and edit in will detect the version of other apps installed and only function if they understood (by the software) to be file compatible. So in your example they will each work independently, but the StudioLink option in Publisher 1.8 will insist that Designer is updated to a compatible version if it thinks 1.7 is not compatible. The functional determination of inter-program "compatibility" is being designed at the moment.
    For now you can assume 1.8.x Publisher will need 1.8.n Designer to enable StudioLink but in practice it may be more flexible than that if file format has not changed.
  17. Like
    Lmpessoa reacted to reminous in Rename artboard from canvas   
    H there,
     
    I wish we could rename the artboards when doubling click over its name direct from the canvas instead depending on the layer panel to do so... It would be much more intuitive!
    Reminous
  18. Like
    Lmpessoa reacted to Nikola Kovac in Preferences window UI is frustratingly designed   
    There it goes, my inspiration that is, out of the window, and I lost it trying to change who knows what shortcut key... again.
    As a professional in video, animation, 3d and audio I have used many many applications over the years, and find Affinity package a real refreshing leap forward. However, I must admit that the preferences window across all three Affinity apps (Photo, Designer and Publisher) is one of the most useless I have ever encountered. I am not afraid to switch and learn applications and am ready to customize the new ones I learn to my own best practices, and the preferences window is my friend or it should be, but Affinity's is not at all. Please let me try to explain what I find is wrong with and suggest some changes which I did not think a lot about, but seem much simpler to use. Let's start:
    1. The preferences window uses a unique visual paradigm, completely different from any other dialogue I have encountered in the rest of the application. It has a header with Back/forward buttons, "home" button (with an odd icon and a drop-down menu) and search bar. No other panel, toolbar, manager, assistant or any other window in Affinity uses this paradigm or at least my humble knowledge of the app does not bring any into the mind. I doubt that this is good. For instance having tabs, like some other windows would do the trick no need for back/forward buttons, no need for home button, no need for drop-down menu, just 7 simple instantly accessable tabs.
    2. search bar is a sneaky red herring! It is in fact dangerously useless! I'd like to change a shortcut for brush size in pixel persona? typing any of these terms does not help me to find where to do it. It seems that this search bar is good for searching only a couple of dozen words which does not make any sense at all, either you make every single preference item that can be change searchable or get rid of the search bar because the way it is now is frustratingly useless.
    3. I will not go in depth on my thoughts about "General", "Color", "Performance", "User Interface" and "Tools" pages as I do see some benefit of "bite sized" preferences pages even if some items on them seem to belong to another page, and the number of these pages could actually be decreased. (for instance half of the "Tools" preferences could easily belong to "User Interface" tab)
    4. Checkboxes, since they have really powerful results would benefit from tooltip help with a more verbose description of what they do.
    5. "Miscellaneous" could easily be renamed to "factory resets" or something on that line, as that is what it does.
    6. And now I come to my nemesis, the "Keyboard Shortcuts" page. Where to start?!
    a) there is a search bar on the upper right, that is as we said a sneaky trap, and a red herring. It does not help us here, and will take us "home" probably finding nothing of interest.
    b) we need to use these two fiddly drop-downs. The first one could easily be replaced with beautiful Draw, Pixel and Export icons cutting the number of actions for picking persona to edit to only one click (or even better none.. read on). The second one is really unintuitive as its items partially overlap in different personas. It took me a while to get the idea that this second one is contextual to the first one (as the list changes "behind the curtain")... I got it only after learning my way a bit around the app so I recognised that some items belong to some personas.
    c)  a quick overview of other buttons and check boxes in this upper region of Keyboard Shortcuts page;
    "Apply to all" -what? to all what? I had to dig through the manual to see what it does, and all it would take to fix it is to call it "apply shortcut changes to all personas" without this information there is no way to know that there actually are some connections possible between personas. As if the for instance, brush size in pixel and draw persona must be separate.
    "Ignore Modifier—Lets you create shortcuts using a single letter designation instead of using keyboard modifiers." says the manual, and I still do not get it. Does it allow me to pres only the letter in application without modifier keys and get what I want? No, as Ctrl+S is stil "save" and "Ctrl+Shift+S" is stil Save as. Does it filter out the input of Modifier keys while assigning new shortcuts? No. So what does it do? Maybe a better explanation in manual would help, and a more verbose checkbox title or tooltip.
    "Load/Save" what? it loads and saves what? a file obviously, but what does that file contain? All shortcuts, or only those in focus? Maybe "Load Shortcut configuration" or something on that line would be better. to be continued...
×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.