Scripting

[arcnor]

Adding my 2c, some features I'd like to be able to access through C/JS are:

• Import/Export capabilities (i.e. being able to write my own import/export plugin for any format), which both requires a way of adding a new file type to the open / save / export sections, as well as being able to read/write all the basic things other formats do, like layers, pixels / vector shapes, etc...
• Not sure if this has been discussed, but I'd like to be able to write a plugin that acts as an adjustment layer, unless that's already taken care of by being able to write a filter (which I'm also not sure will be possible, but I hope it will be).
• Undo/Redo support, hopefully controllable by my code, but whatever we can get otherwise (i.e. if I do a "move layer" then "clear selection", the API can automatically create undo states for both those actions, or it can let me mark a sequence of actions as an Undo/Redo point, which would be preferable as a plugin dev).
• I understand this is more of a "pie in the sky" kind of thing, but being able to write a plugin that interacts / merges with the Affinity Photo RAW importer will also be nice, some of the ideas I have to improve my own workflow relate to RAW importing, so it will be fantastic to be able to affect the process (i.e. by having access to the raw pixel data and being able to write my own contrast slider, as a very basic example).

[Petar Petrenko]

34 minutes ago, arcnor said:

Adding my 2c, some features I'd like to be able to access through C/JS are:

• Import/Export capabilities (i.e. being able to write my own import/export plugin for any format), which both requires a way of adding a new file type to the open / save / export sections, as well as being able to read/write all the basic things other formats do, like layers, pixels / vector shapes, etc...
• Not sure if this has been discussed, but I'd like to be able to write a plugin that acts as an adjustment layer, unless that's already taken care of by being able to write a filter (which I'm also not sure will be possible, but I hope it will be).
• Undo/Redo support, hopefully controllable by my code, but whatever we can get otherwise (i.e. if I do a "move layer" then "clear selection", the API can automatically create undo states for both those actions, or it can let me mark a sequence of actions as an Undo/Redo point, which would be preferable as a plugin dev).
• I understand this is more of a "pie in the sky" kind of thing, but being able to write a plugin that interacts / merges with the Affinity Photo RAW importer will also be nice, some of the ideas I have to improve my own workflow relate to RAW importing, so it will be fantastic to be able to affect the process (i.e. by having access to the raw pixel data and being able to write my own contrast slider, as a very basic example).

Forr this kind of post it would be better if you use numbering style instead of bullets, for easy addressing the answers.

[chocolatkey]

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.

[CM0]

Here are my primary use cases for scripting listed in priority order.

1) Live Custom Effect Layer

Combine the ability of equations, procedural textures and apply image in a live scripting layer.
This would allow custom distortions, color mappings and custom blend of underlying layers.

2) Enhanced custom controls

We need a great set of input controls to make scripting easily reusable.
However, I want to call attention to a couple of unique controls that would add immense power and separate Affinity from the rest as I am not aware if such controls exist on competitors.

• Curves: Allow the user to specify a curve as input control. Affinity's blend ranges is one of the most powerful implementations of such due to the custom curves. Allowing users to use a curve control on input would be immensely powerful for custom scripts.
• Gradient effect. Allow the user to specify a gradient exactly as we do today, but this would simply be input to the script. It would provide the effect area and strengths to apply the effect. Scripts could use the gradient to make very powerful and unique effects that can not be done with transparency gradients.

3) Custom blend modes

Allow creation of custom blend modes by a script. Potentially this can simply reuse the "Live Custom Effect Layer". Just provide a checkbox "list in blend modes" which would then make that effect selectable everywhere in the UI where there are blend modes.

4) Programmatic Brushes

The ability to programmatically tweak the properties currently listed under dynamics, texture, sub brushes.
Pixel level manipulations filtering, the ability to create custom brush effects like other variations of blur, distort, etc.

[Old Bruce]

What I would like is to be able to select a number of groups in the layers panel and run a script which would rename the layers in the group with the group's name and incrementing numbers. So there would be Items 1, and Items 2 plus Shapes 1, Shapes 2, and Shapes 3.

==============

I would also like to be able to take the name of the group and prepend/append it to the names of the layers in those groups. So I have Bob Left Arm and Alice Left Arm etc.

===============

Search for named layers using regular expressions would be useful too. Then I could get rid of the various file extensions in Placed files.

==============

 

[chessboard]

Many good suggestions have already been made. For me, it would be nice if scripts were generally able to replicate (automate) workflows that I do "by hand" but have to repeat multiple times (20, 40, 60 or more times depending on the project). Therefore, it would be nice if scripting was able to control every part of the applications, such as making selections, arranging layers, applying filters, creating, duplicating, moving and deleting objects, opening and saving documents, switching between open documents, applying or changing object styles and so on.

It would also be very helpful if scripts allowed the user to make adjustments while the script is running. For example, you could open the dialog for a filter and let the user make adjustments, and then after pressing "OK", continue the script taking into account the user's input. Or, even simpler, let the user select files using the open or save dialog. It would be even nicer to be able to create custom dialogs for scripts.

[Seneca]

17 hours ago, Old Bruce said:

What I would like is to be able to select a number of groups in the layers panel and run a script which would rename the layers in the group with the group's name and incrementing numbers.

 

46 minutes ago, chessboard said:

Therefore, it would be nice if scripting was able to control every part of the applications, such as making selections, arranging layers, applying filters, creating, duplicating, moving and deleting objects, opening and saving documents, switching between open documents, applying or changing object styles and so on.

Obviously, it's not up to me to answer these questions but it seems to me that all those questions have already been answered by Tim France when he wrote earlier in his post:

On 3/25/2023 at 2:37 PM, Tim France said:

We've not cheated and called directly into the Affinity backend from the Javascript layer, it's all going through the C++ wrappers and therefore through the public C API functions. 

I bolded the most relevant part of that reply.

What that means is that we will have full access to all the APIs the Affinity developers have and not to some reduced subset of calls.

In a way those who desire can become Affinity developers. Those who need automation can automate any part of the software be it Affinity Designer, Publisher or Photo.

And so, 

 

[v_kyr]

1 hour ago, Seneca said:

What that means is that we will have full access to all the APIs the Affinity developers have and not to some reduced subset of calls.

Well, that highly depends on which C++ wrappers the JS layer is mapped to and thus has overall calling access to and/or if there are any possible omissions. You would only have full access if really everything is (would be) mapped accordingly.

Another point is then also how the JS layer is meant/setup to be executed (...is initiated in order to having access to...), so if only from inside of an always already running app, or if it's also executable from outside without the need to run the apps themself at all. - Both would be good to have, since the later would here be preferable for certain more complex scripting situations, as one then hasn't to carry over memory-wise all the UI overhead.

Howsoever, we'll see at some point what ultimately comes out of it.

[debraspicher]

I'm not a marketing genius, but perhaps Serif should use their Affinity social media to spread the word scripting is currently in the works. It would invite a wider range of feedback as well as tip off certain capable users to prepare for what will be their ability to write their own plugins. You could point them here in replies to the comments if they have questions and want to give more detailed feedback.

The forum at the end of a day is simply a tool. It's not an entity with its own AI-like intelligence (yet...) so while there will always be trolls to attract here, it's better to drown that out with active (and productive) discussion.

[CM0]

On 5/23/2023 at 3:45 PM, debraspicher said:

perhaps Serif should use their Affinity social media to spread the word scripting is currently in the works.

It is the single most important feature for Affinity in years. I also believe it is paramount for the future success of the product. Furthermore, AI is eating the world and anything affinity can do to leverage the community to assist in providing integrations to AI capabilities is going to be essential. Going forward, products that don't have any type of API's or scripting that can leverage the productivity boost of AI are going to struggle immensely to be competitive.

Hopefully they will offer an alpha level preview for some of us developers so we could start working together to bring about the needed capabilities and start building some cool demo reels for promotions.

[vladstudio]

Yes! I'm a new-comer to Affinity Designer, considering it along with Pixelmator Pro. The lack of scripting support has been a biggest blocker for me, and it's great to hear the team plans to add it! I will await patiently, together with everyone else 🙂

My 5 cents – it would greatly benefit me personally (and many more, I believe) if you could release scripting support in small batches. Being able to script even the simplest things can often save hours of work. 

[David Cake]

On 5/12/2023 at 7:28 PM, v_kyr said:

With Java, Kotlin, C# ... etc., so JIT compile and certain VM based languages

Right. If you use a language that isn’t a traditional compiled language that compiles to executable code, but instead compiles to a byte code that requires a run time VM, you can do things a traditional compiled language can’t do. This is just word games with definitions. 

[v_kyr]

2 hours ago, David Cake said:

If you use a language that isn’t a traditional compiled language that compiles to executable code

As far as the needed libs and platform dependencies are there, you can do so also with compiled languages.

One example is via fat executable code binaries. As used in former times for NeXT/NeXTstep/OpenStep as so called fat multiarchitecture binaries, in the same manner as Apple does offer it nowadays with combined X86/ARM64 binaries, though in the past with NeXT there was common cross-compile support to up to 4 platforms (NIHS - NeXT, Intel, HP, Sun) via NeXT Portable Distributed Objects (PDO) etc.

Another nowadays example and for more traditional compiled languages like C/C++, you would then use some cross-platform portable framework like Qt ...

Quote

Qt (pronounced "cute"^[7][8][9]) is free and open-source cross-platform software for creating graphical user interfaces as well as cross-platform applications that run on various software and hardware platforms such as Linux, Windows, macOS, Android or embedded systems with little or no change in the underlying codebase while still being a native application with native capabilities and speed.

... and some GCC or Clang crosscompiler.

[garrettm30]

7 hours ago, vladstudio said:

My 5 cents

Haha! Inflation is to be seen everywhere these days, even in our idiomatic expressions.

By the way, welcome to the forums, Vladstudio.

(In case it is not clear, my joke above only relates to the typical expression “my two cents,” not to any criticism on the value of the feedback.)

[fde101]

6 hours ago, garrettm30 said:

Haha! Inflation is to be seen everywhere these days, even in our idiomatic expressions.

 

[EricP]

"Give us some scripts examples"

My primary use cases would be for creative algorithmic graphic design and processing of mostly vector art. 

A good reference for me is Blender, with the ability to script (or node design) custom functions calling existing application features , implement minimal UI dialog using application standard UX components, callable from an icon or menu.

some examples :

• add "objects" to document with control of all their attributes (fills, strokes, opacity, blend mode, fx, position, scale, rotation ….)
• add adjustment layers and live filters with control of all their parameters 
• select document objects based on custom criteria (eg select vector objects with fill hue matching a given value +/-10%)
• randomizing select properties of existing objects (create small color/shape/position variations, randomize gradient orientation)
• generate custom parametric vector shape (eg grids, spirals, random polygons) with live preview, convert to curves ...
• recolouring vector art (applying custom palettes to group of hues of current design)
• applying effects on vector paths (eg merge nodes by distance, custom zig zag, variable stroke width patterns)
• custom tiling patterns of vector or pixel art (through symbols or other means)
• custom tool:  apply custom processing on existing canvas objects/paths/nodes selected with cursor+click/tap, add new shapes on canvas with cursor+click/tap
• place images from disk folder into a clipping mask on document, with control of scale and position within clipping mask

[David Cake]

On 5/25/2023 at 11:53 PM, v_kyr said:

One example is via fat executable code binaries.

Which do not actually go cross-platform, just cross architecture if the operating system uses both, which would be of essentially zero relevance here. You can consider that you have moved the goalposts sufficiently to consider yourself as having won by your own definition if you wish. But it’s irrelevant to current discussion. 
Yes, you can create binaries for multiple OSes if you use a cross-platform code base, but it’s not the same as running the same binary on multiple code bases, which is generally pretty trivial with an interpreted language - and certainly possible with bytecode compiled languages. Though in practice, it often compromises your product significantly (why Java apps are not popular). WASM may prove to be an interesting alternative, but isn’t quite there yet. 

[v_kyr]

6 hours ago, David Cake said:

Which do not actually go cross-platform, just cross architecture if the operating system uses both, which would be of essentially zero relevance here.

Yes those executables had been mainly usable cross-architecture. - Later they went instead the Java way with their WebObjects framework across platforms.

6 hours ago, David Cake said:

Yes, you can create binaries for multiple OSes if you use a cross-platform code base, but it’s not the same as running the same binary on multiple code bases, which is generally pretty trivial with an interpreted language ...

As far as the interpreter's own code base to build it itself (on/for a platform) is compilable on certain systems and therefor the whole is also available for a specific platform (...same for certain possible interpreter modules which use wrappers to underlayed system and third party libs). - So without a runnable interpreter, and/or some possibly missing by interpreter modules needed libs on a specific platform, there's none of that.

Basically for whatever here, if an interpreter, a compiler, or some JIT bytecode runtime system etc., if it's not completely 1:1 portable/adaptable and thus buildable for a system platform, then there is nothing which can be run. So it first of all depends on the overall portability of an underlayed interpreter or compiler and all it's needed resources (dependencies) itself here.

6 hours ago, David Cake said:

Though in practice, it often compromises your product significantly (why Java apps are not popular). ...

That's probably due to the fact that a Java runtime system (JRE) isn't as default everywhere preinstalled and the way how Java apps are usually called/executed. - In contrast to that, on Win systems, there's always a default C#/C++ runtime system available, so most C# apps will run there right out of the box without the need to first install some runtime system for those. Further those compile directly to self executables files in contrast to Java, the later has always to be setup in a system manner to execute related jars via a defined manifest main class. - Another point is, that Java the last years is mostly used for bigger distributed app programming instead of building single standalone GUI apps or the like. - Performance may also be another point for certain speed critical areas of applications, like some in the graphics domain.

6 hours ago, David Cake said:

WASM may prove to be an interesting alternative, but isn’t quite there yet.

Time will show here.

[Frozen Death Knight]

@Jon W A question about the API, will it be possible to add functionality to already existing tools? For instance, let's say I wish to use Expand Stroke every time I vector brush in Designer, will it be possible to implement that kind of automation through scripting?

[Jon W]

On 5/28/2023 at 6:49 PM, Frozen Death Knight said:

@Jon W A question about the API, will it be possible to add functionality to already existing tools? For instance, let's say I wish to use Expand Stroke every time I vector brush in Designer, will it be possible to implement that kind of automation through scripting?

We currently have no plans to allow customisation of existing tool behaviour. 

However, your wish could be easily realised by a script which performs the Expand Stroke command in response to a notional "object created" notification.  

[Frozen Death Knight]

3 hours ago, Jon W said:

We currently have no plans to allow customisation of existing tool behaviour. 

However, your wish could be easily realised by a script which performs the Expand Stroke command in response to a notional "object created" notification.  

Yeah, that could work. Would help users to create more advanced macros that would fill the gap of missing features/tools until you over at Serif add something equivalent/better to the base package. Thanks for the information! 

[rui_mac]

If we can't add new characteristics to existing tools, I hope we can, at least detect clicks/double clicks/drags/drag&drop, etc, in documents/artboards, so that we could implement new "tools".

[michalmph]

On 5/19/2023 at 2:07 AM, chocolatkey said:

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:

@chocolatkey That's what we need more of in this thread - actual case studies.

+1 to "record action and convert to script" - AFAIR this returns an obfuscated version of user-performed actions in ExtendScript, I've used it in a few tight spots when automating the pipeline. Similar thing exists (or used to exist) in Blender, where you could see the Python calls to operations while performing actions - basically, you had an API level log of actions performed by the user. That would be great.

Talking about obfuscation - I think plugin developers might want to protect their IP in some way. Giving them tools to do that would be nice, so their work doesn't automatically become opensourced. That's a prerequisite for a good marketplace ecosystem and user-profit model. Adobe uses a really primitive and easily reversible obfuscation.

Personally, I used to work with very big catalogues that needed a lot of changes parallel to the design process. I'd extract the 'data layer' of the document, like frame contents, image links, product prices, and whatever was becoming an issue, place it in Google Docs, and multiple people could amend the changes simultaneously. The changes would then be backported to the document automatically, with minimum engagement of the graphic designers.

[DieterW]

I really, really, really appreciate that being added. Waiting soooooooooo long. Please also add some easy exchange possibility to provide the scripts to others, easily search for scripts, etc. I am also very sure that this will reduce the feature requests noticeable and then you can implement the most popular scripts into the core. Please prioritize that feature 🙂

[rui_mac]

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...