Search the Community

Good day, I will like to add this suggestion to the team of affinity developers. Can you guys give users access to an api or sdk so we can create plugins just for affinity. If this is made available to users, affinity will get more market ground at pull more creators, companies, freelance developers and school to the affinity products. I teach in a American University of Nigeria, and am pulling my students from adobe to affinity. Many have been asking for plugins and Ux related stuffs. I have ideas of plugins that will help UX designers to move to AD. Please answer this request. Thanks and have a wonderful day. @stokerg @admin @Adam

Do you have an SDK or something like OLE for Windows that I can automate processes? I'm a Python and Node JS programmer. An example would be to create a project in Publisher, and change only text and figures, through an external command of some language. That way you could automate processes. An example of this is MS Word, which has OLE WordApplication, where I can send commands, such as creating documents, exporting formats, among others without interacting with MS Word

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!

When is a API/SDK for Affinity Designer happening so I can automate scripts to draw? Adobe Illustrator has one to create macros. Why doesn't Affinity have for the vector graphics drawing programming for macros? https://www.adobe.com/content/dam/acom/en/devnet/illustrator/pdf/sdk/programmers-guide-2017.pdf

I wasn't sure where to post this idea, but here goes... I just saw this today. An open source app (midi2lr) that lets you control LR via a midi controller. The obvious benefits are that you can have a hardware or virtual (think IPad based) device with dedicated analog controls (sliders, buttons, toggles, etc.) custom tailored to interact with AP. Take a look here to see what I mean. http://petapixel.com/2015/08/12/midi2lr-an-open-source-app-that-lets-you-use-any-midi-controller-in-lightroom/ (video at bottom, 1'41") What a great interface for interacting with a photo editor! There seems to be 3 components needed: 1. AP API (possibly via the Extension specification?) 2. MIDI2LR (fork open source project to create MIDI2AP) 3. Midi controller. These range in price from $ - $$$. Is their a high-level API for AP to allow for this type of input? Maybe via an Extension? Not sure as I haven't been able to find any documentation around this specification. Here is another example showing LR being controlled with an inexpensive midi controller. https://www.youtube.com/watch?v=dRwkDZguAQg (16'03") Thanks for your time. Thoughts?

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.

I'm a developer and I like studying other apps and how they are structured, something people call software architecture, especially for software product lines, theme of my masters thesis. This suggestion is based on the knowledge I gained through multiple projects throughout my life and also the Affinity suite itself. I'm also aware the following is true only of the Windows versions for reasons will be made clear ahead but I doubt the approach is different on the macOS version. Here it goes. --- While licensed as separate applications, the core of the Affinity application is contained in a few files (a few DLLs) shared between the multiple apps. Nevertheless, this actually means that when licensing the different application we are actulally licensing the usage of a few parts of an existing API for a particular purpose, depending on the app itself. Thus, Affinity Publisher - with both Designer and Photo functionalities incorporated - is the whole application and the easiest part of what I call Affinity Studio in this idea. So, the whole of my idea is to drop this separation in multiple applications and incorporate them all into a single one (Affinity Studio) with the ability to receive plugins that could explore the entirety of its funcionality through the existing API. I know most people thinking about scripting and plugins on this forum are demanding languages like Python or JavaScript but the reality is that a part of the Affinity suite (including the aforementioned DLLs) is developed using .NET and it would be easier to enable plugins developed in it: makes the lives of the developers (both at Serif and those writing extensions) easier because developing tools are already avalible (Visual Studio has a free community edition and is probably the same tool Serif already has licensed) and exposing the API is a lot simpler (most of it can be seen by incorporating the those DLL to any .NET project). Limits could be stablished but I see everything could be created: new tools, personas, functionalities, file formats, and so forth. Also, despite being mostly centred around C#, .NET allows for a multitude of languages to be used to develop projects (including Python and Javascript). Before anyone can ditch my ideas as unfeasible because of the macOS version, I must remind that .NET Core is already cross-platform (although with some limitations) and can run on macOS and even Linux and if I'm not wrong .NET 5 (droping both Core and Framework from its name) will be released by the end of the year and may have complete support for fully cross-platform desktop applications, dropping also the need to support a separate version for macOS and opening the door to a Linux release with little to no extra cost for Serif. Also, I don't remember exactly where but I've already heard from someone from Serif that the file format for all applications, despite the different file extensions, is exactly the same (go ahead, change the extension of a file and open it, I'll wait) so files are really not an issue but I'd suggest reducing to a single extension for simplicity (I'd go for .afp ). And we don't need to have access to the details of the file format If the exposed API provides the means to incorporate file importers/exporters (read files and create objects on the canvas and vice-versa) that could solve the biggest issue I see in the forums, support for multiple additional file formats, which anyone should recognise it may be an impossible task to accomplish by Serif alone no matter how big their team is. With this approach, Serif could focus on providing one fully capable application worrying only about its core functionality and leave the rest for the community. No matter how big the API currently is, all we would need is a simple "hello world" so we know where to start and how to incorporate these into the finished product. Plugins are also a means to create software product lines, which is my field, and is a means used by many applications over the years. I know with my knowledge I could be providing some of the funcionality requested in the forums and many many more with the proper means to. I know many in this community feel the same and I cannot wait to see what could come out of this (even scripting with Javascript or Python could be achieved throgh this). If your concert is security/privacy of users, I'd state I don't really remember any platform using plugins being overly concerned about it, which I understand could be a big issue depending on Serif's values but I believe this is something the community could regulate on their own: some more concerned would work on evaluating extensions and providing feedback to us all about which are safe to use and which are not and word will eventually spread. If Serif is really concerned about security, they could incorporate the means to remotely block (blacklist) harmful plugins (please, don't tell me you dont know Apple and Google can do that on your phones). Sorry for the long post but I see a big potential in applications like the Affinity suite given the proper means for expansion and I would love to work these ideas out without having to be part of their team itself. I think the ball is in your court now, Serif

i will like to see a sdk or api system which will allow developer make plugins and hack for affinity products. i believe with this feature affinity products and awareness will grow faster and also we will see some amazing stuffs from user. please consider this so i can build some amazing stuff for prototyping . Thanks

Since Publisher currently does not support merging I was wondering what sort of options we would have for a workaround? Is there any documentation of the format of afpub? I was thinking I could potentially write a tool to generate a file that would walk a data source, create elements, size them and place them on pages, then apply the appropriate master page to the page. From there I could open it in Publisher and modify it appropriately. Alternatively is there (or will there be) api or plugin support where we could develop such a plugin independently? I am developing a Card game and being able to merge from my content source database (or csv export) would make this a perfect product.

I've recently bought Affinity Designer and it's a great tool - but it lacks one extremely important feature: A plugin API of some sort. Currently there is no way I know of to add any kind of custom functionality to it. A plugin API would add the great benefit of making it relatively easy to automate common tasks. Also, you guys can focus more on bigger and more important features if we can create plugins for small features by ourselves. I'd suggest using an already available scripting language like JavaScript for creating plugins. Especially JS would be a great language for such a thing because of the huge amount of already existing JS libraries for almost everything you need. As for the API itself, the following features would be great: - Accessing and modifying the properties of elements - Data persistence (Adding custom information to documents. These should be kept even when opened on a computer that the plugin is not installed on) - Filesystem access (needs to be permitted for each plugin by the user. This would provide more/better security) - Network access (also needs to be enabled by the user) You could add some sort of marketplace for plugins, as suggested before. This would let you check plugins for any malicious code and would enable you to gain some extra income.

Hi, in Affinity there are nice tools to stack photos (focus, panorama, ...) :-) It is not possible to sent files from outside the program directly to this tools. But this would be nice, becaus of integration in Lightroolm and similar software. In the moment you can sent more photos to Affinity, but you are not able to use them in the stacking tools. Of cause, a "real" Lightroom integration would be the best for the workflow. For the moment it will help, if there will be a way to send photos to all tools in Affinity (and reimport the result). Regards Stephan

Hello, Thanks to the team for this great tool that is Affinity designer ! This feature ( request ? ) could somehow be understood as the equivalent of brushes in Affnity Photo... The triangle tool and others ( Trapezoïd / Diamond etc...) are neat and really practical ! is there a possibility ( or any plans in the future ) to have an acces to build / add / customize other tools by myself and to add them to the UI? o- suppose i want to create a "logic gate diagram", i would have to use AND, OR, XOR ( and others ) gate symbols. - i could create a tool for each symbol - add handles to customize it ( radius, height etc.. ) as seen as the little red dot. - the description of each tool is a file that would be imported in Affinity designer. Many thanks for your consideration, for taking the time to read my request, and for this great App !

As a programmer I doubt im the only one who'd enjoy having the power and complexity of Affinity Photo as a library for image editing programically. Say making a image classification network and using this for preprocessing. You already have most of this made as its highly likely your GUI just calls methods from some proprietary library you bundle with your software, so why not just document it and let ppl that pay for your products use it in our code? of course have a TOS that dont allow us to make another photo editor using your library but it would be nice to have for doing preproccessing or other fun projects. Like a discord bot to apply some fun visual effects to images users upload. If you ask me this would give you a new market to advertise to, the developer market, a market that is lacking in comptitision for minimal work. Sorry for my bad english Im dyslextic

Not sure if this has been addressed: It it would significantly improve the AP app experience if users could create tailored workflows easily and then batch process multiple shots using AP and Workflow, together with other suppported photo apps, to automate the current tedious one-photo-at-a-time procedure. I would be happy to help with the development of this feature, as it would greatly benefit many photogs I know who are interested in making the switch from traditional PC laptops to the iPad Pro.

A small introduction: Technical Director at a Visual Effects and Photo Retouching house called www.taylorjames.com - I truly believe I work with some of the very best Photoshop artists in the world. I will be aiming to move them over to Affinity Photo once the feature are at parity and we can do things in AP that we can't do in PS. The native support for EXR with data-windows is a big improvement on PS for one! Mixing bit depths is great, masks within masks is amazing! I can see a point in the future when we look back at Photoshop and wonder how on earth we did it! We work on a lot of high end products and a huge amount of automotive work which can be immensely repetitive and benefits massively from tools we've created over the years. Working with CGI generated images we create a huge amount of data, images are often composed of many layers and using scripted tools we can layer up all the images and put them on the appropriate blending modes and into the right folders. I want to be able to design my own tools to make custom contact sheets and reviewing tools and automatically be able to tag layers with custom attributes and notes so we can make automated tools for updating layers and layer comps procedurally! I'd love to see a nice powerful scripting API that allows us to change any property, add layers, adjustments, run tools, open/close files etc... Some of what may seem like the simplest things in Photoshop are amazingly complex! Try to close a layer group in PS using Javascript, it requires creating a new folder which is closed and copying the layers into it and then deleting the old folder as there is no .isOpen folder property! There is an incredible community of script writers out there who will make amazing tools for your software! Check www.scriptspot.com and www.maxplugins.de see what was made for 3dsmax, it's kept an old software running for 25 years! I'm not the biggest Python fan (pretty much because of the indentation rules) but it makes sense to use it and take advantage of the PyQT framework, which I'm hoping you have used to build your application? Congrats on an excellent product, I'm seeing a huge amount of people shout about it loudly which is always a true test and hopefully reduces your marketing budget! I'll be buying my own license to do my own photography work at home too. Regards Dave

Hey, I've just purchased the Affinity Designer program to see if I could make the transition from Illustrator. So far I'm impressed! However, one of the programs I love using with Illustrator is Rightfont They have a one-click and drag & drop functionality that speeds up my workflow immensely. I got in touch with them to ask why they didn't have the functionality and if they planned to implement it. Their response was: It would be fantastic to have this across all your products - especially the upcoming Publisher application. Any chance of reaching out to them and making it happen? Thanks!

Hi all! I know you guys are very very busy prepping for the next full version of Affinity software to be available to customers in the Mac App Store, so this is by no means a biggy issue. I was just wondering if it could be possible in the future to have an automatic or manual upload button within AP (maybe AD as well?) to the online photo hosting service SmugMug? In case you are curious, here are a few links: SmugMug online hosting service SmugMug API (home) Third-party uploaders, downloaders, migration tools and utilities Thank you for your time and keep up the extraordinary work! You make an awesome team! :wub: