Jump to content

Search the Community

Showing results for tags 'scripts'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Affinity Support
    • News and Information
    • Affinity Support & Questions
    • Feature Requests, Suggestions & Discussions
  • Learn and Share
    • Tutorials (Serif and Customer Created Tutorials)
    • Share your work
    • Resources
  • Bug Reporting
    • Report a Bug in Affinity Designer
    • Report a Bug in Affinity Photo
    • Report a Bug in Affinity Publisher
    • (Pre 1.7) Affinity Range Bugs Forums
  • Beta Software Forums
    • Affinity Designer Beta Forums
    • Affinity Photo Beta Forums
    • Affinity Publisher Beta Forums

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 7 results

  1. 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.
  2. I was curious to know if there are any hopes that down the road a python or some sort of scripting API will be available for Affinity Applications like Designer/Photo. Working in the film/vfx/games industry for over 10 years now, one of the biggest headaches is developing pipeline tools for Adobe applications due to their constraints and poor choice of Java implementation for API. I would love to see a modern API like python supported in Affinity applications. Thanks guys, keep up the great work!
  3. I currently have several Photoshop compatible color palettes, actions and scripts that have become large part of my computer coloring output. I was wondering whether there is any chance of making Affinity Photo compatible with some or all of these plugins.
  4. Hi, there is one thing I miss from Illustrator and it's the ability to attach scripts, or some metadata, to elements; layers or groups of layers. It's helpful when creating interactive SVGs. Of course it's possible by naming layer/group and edit the code of the exported SVG but it becomes repetitive when you open the SVG again and the code is stripped of the additional code. So the option to have some extra content in the code of an element and keep it intact on re-opening or saving the document, would be terrific. It does not have to do anything, just a field to type som extra attributes to the element and keep them throughout the workflow.
  5. What do you think about a gradient that uses steps and symbol instances instead of colour/alpha values? Basic settings would be: x distance, y distance. Each with the basic gradient controller the apps already have. At its most basic it would serve screen printers well by having circles go from scale 100% to scale 0% with the same control as the gradient tool. A sibling if you will. For replication it could have a drag well to drag symbols and other objects into. At its other end the behaviour along the gradient modifier could be scriptable. As an example: Scale instance object down from 80% to 20% but stop scaling the outline at 50%. Symbols instanced along a controllable path would be a great addition even without the scripting for most users.
  6. I had to get a new computer and reinstall Designer. Now every time I start the program I get a box that says: Windows Security Warning Scripts are usually safe. Do you want to allow scripts to run? Yes No I have to answer before I can use the program. Very annoying. I didn't have this on my old computer. What scripts are they talking about? I had asked earlier if there was an ability to add in a macro (script) to automate things and was told no. So what scripts am I allowing? Is this from brushes I've added? I can't think of anything else I added to the program. Can I add things? Like adobe actions? confused Sig
  7. Hi, I frequently use the Export section to export in SVG - Export at 300dpi and also PNG. However, using the Shortcut Keys is bit hard as I am not a contortionist! ( Need to use the CTRL-ALT-SHIFT-S keys together and I have short stubby pinkies! How can I reset this key combo to a single keystroke please? Also, is there any way I can record a standard set of commands into some sort of scrip[t? e.g. If I purchase a Vector alphabet I need to isolate each letter and doing so by layers is a nightmare (designers note! as nothing is grouped, so the fastest way is to select all items for each imaged char and copy then paste new from clipboard.Save As AD native format then Export in SVG 300dpi and also a copy in PNG format for wider usage. I hope this makes sense! Thank you! Angela
×