Graeme W

Yes, that's true. Most of the scripting with Adobe products I have got involved in was mainly 100% inside InDesign - one script does have to call out to Illustrator which is handled via BridgeTalk and has resulted in an absolutely horrible bit of code but does what it needs to. There is definitely a need for both of these functions in addition to working cross platform too which makes things pretty tricky. Hopefully if/when we do get a scripting solution there will also be some sort of centralised repository on here along with a dedicated sub-form inside the "Learn and Share" area to promote the use of scripts and help each other learn.

The main reason why Javascript is in the discussion is that this is what is used in InDesign and the other Adobe creative apps. Many of the people looking for scripting in Affinity apps will no doubt have built scripts in those and so using Javascript would make sense in that there would be an easier transition in that regard. I havn't used Quark in a long time (v6.5) so I have no idea what that uses other than just Applescript. There are plenty of Javascript libraries out there, for example https://github.com/exif-js/exif-js - however, that is where the argument for Javascript does fall down in that because Adobe's Javascript implementation hasn't been updated in well over a decade you cannot actually use any Javascript libraries because they are all using newer features that break in Adobe's environment. For example when I built my last large InDesign script I needed something to write tests in - the best I could manage was getting 14 tests running in Jasmine before it would die. I don't know Python but that's only because I have not yet had a need to learn it. If we get Python-based scripting in Affinity then great, I guess I will have a reason to learn it. I just feel like the focus really needs to be on making sure that whatever implementation is chosen gives us the depth comparable (or better) to that of InDesign as opposed to the half-assed implementation of Acrobat Professional.

I can't speak for others but I would definitely want scripting automation within the Application. I am looking at what InDesign offers in this regard - Acrobat is woeful in comparison. My main use case is a custom import/export tool which can handle several versions of a custom XML document format we use. It does do a few other things with some custom GUIs and stuff that InDesign offers (even if it's implemented them poorly). It does have a sub-feature that calls out to Illustrator but that is only because scripting in Acrobat and Illustrator directly are so poor in comparison. I also have a few utility scripts doing a few things, have previously written a companion app for an asset management tool which processed and submitted data. Plus there is an awesome script I found a while ago called Calendar Wizard which can automatically setup pages with the dated squares for every month with a whole bunch of configuration options. So, without an alternative with scripting, I have to keep my old mac book with CS4 going for a while yet.

If we get scripting then it won't be Applescript. Pretty sure Apple EOL'd it years ago and besides it's not cross platform so would mean the devs having to spend their time on multiple scripting interfaces. We need scripting capabilities to rival InDesign and that is a lot of work to do so choosing a language that would suit every platform is a must.

Nothing against Python other than it's not a language I have used before. However, it's not just InDesign that uses Javascript. I would imagine either language would be a good choice, providing the API is broad and detailed enough to really allow maximum control just like InDesign offers (and not the pathetic minimalist offering like Acrobat)

Adding a +1 to the vote for scripting / API support. InDesign's Javascript support (despite being ancient) is a very high-bar to aim for but something in that direction in the final release would be amazing. If we had that we could definitely migrate most of our work machines over to AP instead of being forced into Creative Cloud at some point in the future - we're still hanging onto CS5 for dear life at the moment!