Search the Community

If the apps follow Apple's Human Interface Guidelines, yes. Affinity doesn't. Well, see above, in fact: In apps that actually follow Apple's H.I.G., I can tab between UI elements, changing focus without having to point and click. It's a usability and accessibility issue. The tab key has always served a key role on MacOS in this context. And this is not that easy in the Affinity UI mess. Although there are ways and workarounds, e.g. via Keyboard Maestro macros and System Events UI scripting. I've posted quite a few such examples and experiments in the past here.

Speaking of import/export, is there any news on whether there will be some form of text tags for scripting formatted text?

And what do you base that on? Just on that last statement from Tim? That just indicates that the whole is still in progress & in development state, so some more things do work now and have been in a state to be internally reused for certain tasks and tests. But it doesn't tell you how complete the C/C++ API interface and JS scripting engine is at all now, or when the whole is in a state to be released at all. Further there is also much more than the coding things only named so far to do, namely the whole user & usage documentation of available API & JS functions (aka a concept overview, function list overviews, function explanations, various examples ...). - For developers the later said/named things here (writing the docus & user guides ...) takes in contrast to writing prog code usually more time to build & set them up in a manner, understandable and usable for end users at all.

Only to a point... All code is ultimately interpreted at some level. When it is interpreted by hardware we call it "native" and when it is interpreted by software we call it "interpreted" or "emulated" but in the end it is being interpreted at some level. There have been hardware implementations of the JVM byte code format (https://en.wikipedia.org/wiki/Java_processor) and a hardware implementation of the smalltalk byte code format has at least been considered if not implemented so at some point an equivalence with capabilities is reached and the differences become a matter of performance due to levels of abstraction and implementation characteristics. Many of these scripting languages are actually being compiled into some byte code or internal data structure format or another by their "interpreters" which then interpret the byte code rather than trying to execute the scripting language directly. In a sense, they are compiling the code and then executing the compiled code, no differently from a native code workflow, except for the specific architecture of the compiled format and the fact that they are interpreting the results in software instead of in hardware. There are examples of implementations of fully native compiled languages that can accept the source code in the same way that a scripting language interpreter would, compile the code and execute it with the same immediacy of a "scripting" language, further blurring the distinction between them (the GNU Haskell compiler offers a "runhaskell" command which does this for Haskell code, for one example). At the same time, it is possible (and sometimes quite easy) to write scripting language code for many scripting languages that is specific to a particular operating system. In Perl for example I would just need to write a "system" command to run some outside utility that is only available on some specific operating system, and that code becomes non-portable.

I'm going to have to disagree on this one. It is partly a matter of perspective. Blender does not conform to the user interface guidelines of practically anything - it is off in its own little world - so from that perspective, yes, it is a "foreign" piece of software no matter where you run it, with its own distinct learning curve and not quite fitting in with anything else. However, people did experiments in the past (before some of the sweeping improvements that have been made to the UI in more recent versions), and found that if they took someone experienced in Blender, and someone experienced in one of the commercial 3D apps, and had the Blender user and the other app user do the same thing (this was for modeling if I recall correctly), the Blender user could generally do it much faster. Blender's interface is not optimized for new users or to make it easier to learn (again, this has improved in the more recent versions, but it still is not the main focus). Rather, it is optimized for speed of working after you learn it. Someone who spends a lot of time working with Blender can become very fast in what they are doing - this is one of its primary benefits. Blender is an example of a true professional interface for people who heavily use the same app frequently. It is not a good UI for people who use it sporadically or for people who want to walk up and just start using it (again, this is improving with the current versions, but is still not the main focus). When you look at it from that perspective, Blender is a program that people try to conform to a different mold than the one it is primarily intended for, them come away from it disappointed that it is not what they expected. When you approach it for what it actually is, the interface is quite good. Of course, it is not completely perfect even within that category, as evidenced by the fact that they chose to base their scripting on the Python language. Sad.

And guess now what GC internally uses for exif data handling. Also a bunch of other graphics/image GUI tools do make use of the exiftool libs here. Finally it's a matter of taste if one uses CLI tools like the initial exiftool, or some GUI frontend/app for that. Same as using ImageMagick CLI tools instead of GraphicsConverter here, where the later is a commercial one, but IM is more powerful for automation & scripting purposes etc. - I also recall that the free XNView MP can also add exif data, though don't remember if for PDF files too or not. There's also this commercial ExifEditor for macOS here, though it might not deal with PDF files directly (never used/tried that).

Have a nice trip. AFAIK scripting will appear after v. 4.0 and it is about 2+ years

I am going away and then I won't really have access to affinity for a long while. I want to be able to try out scripting once before then being that there is no release date or cycle yet.

This is the one thing stopping me buying Affinity Photo. I need command-line scripting so I can automatically apply image adjustments to image files without having to click buttons in a GUI. For the moment I am using a very old version of Photoshop (CS6!) to do what I need, but would switch to Affinity Photo immediately if it allowed me to do the same thing. Specifically, right now with Photoshop I can: Create an Action that adjusts the currently-loaded image, saves the result to a specific folder, then closes the image. Run the below Applescript (via the command line) to get Photoshop to apply my Action to a specific file. Repeat over and over for multiple files via a command-line script. tell application id "com.adobe.Photoshop" open file "MyFile.jpg" do action "MyAction" from "MyActions" end tell I assume this is not possible currently with Affinity Photo? Any idea if Serif has any plans to implement it? (I am aware that Affinity Photo has a batch-processing GUI, but I need this to be initiated from the command-line, because my command-line script does other things with the generated image files after running the above.)

Personally I usually think of scripting and plugin API as two different things: 1) "Plugins" deal with calculation intensitive tasks like blur, sharpen, color manipulations and similar things that require pixel-by-pixel calculations. This is CPU intensitive and might even be able to utilize GPUs. Plugins are typically written in low level programming languages like C++ or GPU shader languages which are fairly difficult to learn. (Skill level: Expert) 2) "Scripting" means calling existing functionality from an easy-to-learn high level programming languages like javascript or LUA. Such scripts don't need to run very fast, as they're not doing heavy calculations. (Skill level: Mediocre) I think Affinity Photo should offer both. But am I right in assuming that this thread is about point 1 (plugins) rather than 2 (scripting)?

There are already some Py scripting libs for topo maps etc. which do such borderline framings etc. - One PyGMT based example can be inspected & followed here ... https://www.earthinversion.com/utilities/pygmt-high-resolution-topographic-map-in-python/#plot-data-on-the-topographic-map https://towardsdatascience.com/easily-plot-earthquakes-data-on-top-of-the-topographic-map-in-a-few-steps-c165673035b4 ... etc.

The plugin API is still a work in progress and is not ready for customers to use yet. Refer to the thread linked above, on Scripting, for various posts explaining this. The plugin API and the scripting API are apparently being developed together, so it seems likely they will be available around the same time, whenever that happens to be.

It's going to be javascript right? Wish it would rather be Python . ChatGPT seems so much more proficient with Python while it took hours if not days to make it write you a working javascript for Photoshop. We need scripting system that works with ChatGPT nowadays please. With Affinity apps I am afraid it would be like persuading it to write you a script for 3d max vs Blender where ChatGPT instantly shines.

It's likely Wishes Pro would have issues in the ME version of InDesign as well in this regard (or the hack for using ME features in a western version of ID). There is no GUI means of accessing these OT Features--though it can be done via scripting. Because a western ID version these ME features are off by default, there isn't an apparent issue in them. At least all the above to the best of my recollection.

Hi ! Trying to make the change from inkscape to Designer, I was puzzled by the disappearance of the "object exchange" tool, which to me sounds like one of the simplest possible tools to implement given access to the API (copy object one position (x,y); write position (x2, y2) from the second object as position for object one; write the copied (x,y) back as object 2 position). Since it is a priori such an easy function to write, is there any rationale for not including it? This issue is made significantly worse by the lack of API reference and tools for custom scripting / integration with other softwares. Such exposed APIs are what made the success of many "open-source" projects such as Blender, Inkscape, vscode and many others: your software cannot be missing features if the users can add them for themselves. Please consider such a move, which would be in everyone's best interest and would make your software suited for larger scale professional applications. Best regards

If someone in the Scripting development team at Affinity could answer me this, it would be great. In other applications I use, that allow for scripting (mainly, Cinema 4D and VizRT), besides being able to create scripts that can be executed from a menu listing (Cinema 4D, only), I can also attach a kind of a "tag" to an object that runs scripting code in real time, whenever the scene/document is changed/refreshed. That way, I can perform scripting operations on the object that the "tag" is attached and also on its children. Will Affinity scripting abilities only allow for scripts that can be invoked from a menu or will we have a new type of "tag" to attach to our "layers/objects" that can allow us to add abilities/behaviours to any "layer/object"? Something like my mockup...

Affinity has a real good Keyboard Shortcut option in Preferences. Please consider adding keyboard shortcuts for the transform options so users can set their own shortcuts for these options. Example: I can set CTRL+Alt+CMD+X for Transform X. Then in future, when I press CTRL+Alt+CMD+X, the X field in the Transform panel will become highlight and I can type in the value, without needing to use the mouse to select the field. Or I could set CTRL+Alt+CMD+9 to the top right anchor point. Then when I want to change the anchor point of an object, I can just type CTRL+Alt+CMD+9 without having to use the mouse. Mock ups: ^ A mock up of how it would look. Note that there is a new "All Affinity" option so you can use the same shortcuts across all the affinity apps (Photo, Designer and Publisher). ^ Once you've set a shortcut, you can type it and the relevant field will automatically become selected. WHY WOULD THIS BE USEFUL? 1. Automation Affinity doesn’t have scripting support, but it does work very well with automation packages such as Keyboard Maestro. Being able to transform objects on the page is a key automation task. At the moment, this can be achieved by using a tool such as Keyboard Maestro to access the transform panel by emulating mouse movements. However, this is very prone to failure. Being able to enter keyboard shortcuts would ensure Macros are less prone to failing. 2. Reduce repetition If you have a lot of objects to transform, using the mouse gets tedious. Being able to type keyboard shortcuts is more efficient. POTENTIAL DRAWBACKS AND SOLUTIONS Coming up with separate keyboard shortcuts for the transform panel options may be cumbersome (e.g. CTRL+Alt+CMD+X is quite the command to remember). However, because this feature would be made available via the Keyboard Shortcuts option of Preferences, the user is free to set shortcuts that work for him/her).

As you already know there are actually not that much scripting possibilities for the Affinity apps. Further since you've obviously already made up your mind about scripting here and found a solution that works for you, it doesn't seem necessary to mention everything else that is available as an external scripting app here! Neither of these, I was just saying that if you spend months with Swift (as you tell) just in order to move some desktop app windows, that you then probably did something essentiell wrong here, during your tryout phase to learn Swift.

I agree with @jbmanos when he says we're talking about two different things. 1. is creating scripts within the Affinity applications themselves to extend or enhance the existing functionality of the apps. These 'scripts' are also sometimes referred to as macros, extensions, tools, plug-ins, etc. I think this is what most people are referring to when they talk about scripting with regards to the Affinity applications, and are similar to those scripts, extensions, plug-ins found in other applications such as Adobe Illustrator, After Effects, Blender, etc. 2. is automation of the Affinity apps from the host environment, using tools such as AppleScript (macOS, OSA Open Scripting Architecture) and Shortcuts (iOS/iPadOS and macOS). This type of scripting is often involved in creating complex automation workflows between applications, such as those used in the printing and gaming industries. This type of scripting requires app developers to provide a 'Dictionary' (API) with commands accessible via OSA, which is what @jbmanos is asking for. It's not in place of in-app scripting, but an addition that allows the Affinity applications to be utilized within much larger workflows. Also, the newer 'Shortcuts' feature that is available on iOS, iPadOS, and macOS is a bit of a reimagining of how these workflows could not only be created, but utilized. AppleScript/OSA scripts are also supported within Shortcuts. It's also worth mentioning that many apps support both scripting extensions within their own application, as well as providing automation features that can be utilized to chain together much larger automation workflows between applications (including those from other companies). Adobe Illustrator, InDesign, etc. all provide an OSA automation 'dictionary' in add to their own internal scripting capabilities, which has made them indispensable to many industry workflows.

Just ignore them. Unfortunately there is no blocking of threads opens by users on the ignore list. i think there are alternative browsers for forums like this who offer additional functionality. It can be done on client side with some scripting (I’m unable to do this myself).

I agree with the suggestion for more robust scripting since I'm still unable to use Affinity Photo to complete tasks I can do in other Adobe products (even PS Elements) in an expedited workflow that makes sense. Affinity Photo will not launch external Photoshop plugins from macro playback, even if I don't care about it saving all the external plugins settings. I thought I could always create extra keyboard shortcuts to do similar things in a hurry. The documentation claims you can create keyboard shortcuts for plugins under the filter shortcuts, but no. The plugins do not show up here in Windows no matter what I do. No shortcuts for me. I've seen this as a long running complaint and bug report from Windows users that's never been fixed. I guess people need to resort to scripting with something like Autohotkey or Microsoft PowerAutomate, if they want it to work (not exactly my first choice). Even sad-sack Corel (the company where formerly good programs go to fester and die a long slow death) has scripting capabilities in Paint Shop Pro. Maybe because they got them when they acquired it from JASC 20 years ago. They can also launch Photoshop plugins as part of playback. But they have a lot of other issues which makes me want to avoid them. Affinity Photo is a good looking program with a lot of quality features but it still has some real bugs and holes in its feature set (better automation and scripting is one; better automatic subject selection is another). I really want to love it and use it as my main editing program but it needs to fill in some of the gaps before I can. I don't mind that I've bought it twice since it's my contribution to try and support someone who's not Adobe. I want to see someone else give them some competition, it's unfortunate that it's not truly a competitive product for many things I do. Keep up the good work and I hope to see scripting support sometime.

Hi, I've been lurking in the forums for quite a while now on scripting-related topics, hoping to see it added to the Affinity Suite. I run a comic localization company, and we use InDesign and Photoshop extensively in our business. Since people were mentioning usecases, I will give an example of the two main ones it would be great to have so we could switch our large team over to the affinity products: 1. I have built up a complex system (web GUI, server etc) to control (the very expensive) InDesign Server. We received thousands of chapters from Japanese publishers in InDesign containers (it's the dominant format in this industry). Since our team operates in Photoshop, not InDesign, I have a system that ingests these files, and converts them to PSD files. I also have an alternative pipeline that exports the contents of an entire InDesign project to a PDF file. Both of these are essential to our workflow. I know that due to the difficulties of implementing .indd support in Affinity Publisher, the full workflow will probably never be truly replaced, but Publisher can at least open .idml which we can mandate the usage of to some extent. An essential part of this is mimicking the "Bridge" functionality. I can use the (admittedly ugly) "BridgeTalk" functionality of InDesign Server to interact with both InDesign and Photoshop at the same time, so having the functionality to script between different Affinity apps would be nice, although not required. Throughout this entire workflow, something that has been really nice about Photoshop's scripting is that I can do literally anything I can with Photoshop actions in the scripting language. The process is a little painful, but if the docs suck for a specific operation, I can record an action in Photoshop, then use publicly available tools to convert the action file into a bunch of scripting commands, which has helped when doing things people don't normally do. Overall, the Photoshop portion involves importing the exported PDF layers from InDesign into a document as layers (with a specified DPI), then turning the entire thing into a smart object, and resizing the document and occasionally changing its format to grayscale. Something that I miss with the resizing step is the ability to specify the resizing algorithm, so if we could have the same control Affinity Photo currently gives you in the GUI (Lanczos etc) that would be great 2. We have written tools based on publicly available scripts (such as https://swirt.github.io/typertools/) which improve productivity for our freelancers greatly. I can't emphasize enough how much work this tool saves people when lettering comics. It's probably the single most important reason they can't switch to Affinity Photo, because all of #1 still technically would work since Affinity Photo can read PSDs (even with smart objects!). We need the ability to build complex GUIs that are built-in to the program (or at least as a pop-up window that does not prevent focus on the document). I don't like saying this, but I think Adobe's choice of going with a "webview" was the correct idea, because there's no GUI toolkit as extensible, hackable, and for which you can find devs that's better than chromium. I think exposing your own widget toolkit would be better for puritans and for the experience, but I'm not sure how you're going to possibly implement every possible widget someone needs, meaning they'll be constrained and therefore irritated when they don't have e.g. a special color picker, custom vertical fader, or whatever else their GUI requires. As a side-note, we are currently working on developing another script/GUI in photoshop to allow for direct uploads/downloads of the documents to our project management system. Some kind of `fetch`-like API access would be nice. I know the difficulties and dangers involved with letting a script communicate with the outside world, but I don't think you're going to be able to compete with Adobe without an equivalent to their "Socket" API. I hope this helps you a bit, and I eagerly await scripting abilities.

Bar and QR codes is the sort of thing I expect will be relatively easy to do as a plugin, or even script, once the scripting and plugin features are available. Calendars too.

Note: there are a bunch of calendar generation tools available, either on the net as online tools, or as specific apps, or as plugins for word processors and other common apps, or as common system CLI tools etc. All of these can be mostly used to generate all sort of calendars for a (re)usage in the Affinity Suite. - Thus I list here just a few of these calendar tools, so mostly some online and CLI tools, which don't need any account requirements, or to be extra bought. Online calendar tools ( should be usable without account requirements ) Advanced calendar creator (can generate various sorts of calendars) Basic calendar creator SVG Calendar Generator (by Mensch Mesch) Create a calendar for any year Calendar Generator Design a custom calendar Make Word calendar online (can generate various sorts of calendars) PDF Calendar Fantasy Calendar Generator Personal life calendar generator ...etc... OS CLI tools: cal (macOS) ncal (macOS) Gnu gcal (macOS + Win, very powerful) Gnu gcal manual ...etc... Python Scripting: calendar module calendar module tut workalendar module ...etc... (to be continued over time)

Well, that's common for many interpreter-based languages, so in your argumentation I honestly don't see the sole named & outweighed advantage of Javascript over Python, or any other powerful scripting languages here. - So there is no real advantage of using JS here, beside that it's the Scripting teams decission to take that as a scripting base. And maybe the hope that most people are maybe more familiar to it, as the Adobe products and OSes do offer to use it too for scripting purposes. AFA you know any of them well enough, as there are many language specific and also syntactical & object model differences between all of them. So all in all converting code from one into another isn't always a nobrainer here, pretty much the same as with compiler based prog languages. Not sure what a plugins API is meant here to have to do in/with the scripting context? As plugins do hook/connect/bridge into the app and so far for the Affinity apps don't reuse any internal specific Affinity functionality beside let's say an image layer exchange. - Also AI has still to evolve some longer time before being of any real help to generate full blown functional Plugins, or right out of the box funtional app specific scripts. It's still at it's early steps here in this context.