Scripting

[Jose Alvarez]

One more vote to Python.

Despite the fact I'm a Indesign scripter long time ago, I think Python is a more powerful, cross platform language. Not JS for WINDOWS and AS for OSX, one ring to rule them all 

Greetings from Spain!

[Xakiru]

Javascript is the right choice, look around you guys.
Lua or python should be ok too, but what matters is to have a way to script exporters.

[daveharrisonnet]

+1 for scripting

I think javascript would be the way to go given the state of play of the current developer ecosystem. JAMSTACK etc

[thomaso]

On 8/30/2019 at 4:02 PM, RM f/g said:

Can we, indesign users, still use applescript/javascript in the future

I wonder, since APub is able to open .IDML files, if it could also be possible to use scripts from InDesign in APub? I imagine it might work for specific layout objects and UI items, in particular those which have both apps in common. Or maybe after running a translator script to swap application specific vocabulary?

If yes, that might also mean, if this language(s) get supported by APub, then there would be available scripts from the beginning, and experienced scripters and users, too. Looks like a win-win-win situation

[MikeW]

2 hours ago, thomaso said:

I wonder, since APub is able to open .IDML files, if it could also be possible to use scripts from InDesign in APub? ...

No. There is no possibility. Even if/when Serif adds scripting, the methods, api, etc., will be completely different...and that even if Serif extends JS like Adobe did.

[Sylvain G.]

I understand the complexity of a 100% cross-platform scripting solution. This could be especially challenging when dealing with objets outside the application.

But you should _at least_ consider enabling AppleScript support on macOS where it comes almost for free with any Cocoa application.

No need to build anything, just accept AppleScript events so we coud at least do some UI scripting.

[michalmph]

I'm looking to get invested into Affinity software. I love the programs so far, but scripting is a must have for me.

Did we get an official decision from Serif if scripting is going to be supported in the future? If yes, any rough timelines?

Most of my commercial work is DTP process automation and pre/postprocessing with Photoshop Illustrator and InDesign.

 

I see many people posting preferences for scripting languages in this thread, so I'll give my view on it as well:

- Python has huge amount of libraries for most tasks, and in recent years became supported by an increasing amount of applications. Many people learn it as their first language in the academia, and it's steadily growing in popularity in the last 15 years. (source:  https://insights.stackoverflow.com/survey/2019 and https://pypl.github.io/PYPL.html)

- Javascript is the original cross-platform language supported by the Adobe ExtendScript software. A lot of people using the Affinity software for UI design and web development most likely come with it as part of their skillset.

Personally, either is OK for me, with a heavy preference towards Python.

 

 

Edited May 14, 2020 by michalmph

[angelhdz12]

I also vote for Javascript or Python. TypeScript is gaining terrain. NodeJS added TypeScript, Vue added Typescript. VSCode extensions are made with TypeScript. Ionic for mobile/desktop/web apps is using TypeScript.

I would love to have a statically typed language to control Affinity programs:

let circle:Shape = document.selection[0] as Shape;

for(let object:any in document.selection) {
  console.log( object );
}

But I agree with michalmph's about Python "having huge amount of libraries for most tasks".

But I read a comment here with a really nice idea. Regarding of the chosen language, building like a server, where we can send HTTP request (or connect to it via sockets/workers?), so we can use any language we want.

I would then, use the Dart client. Like the Discord Client API that there's a port in so many languages.

[Lorox]

Regardless of what script language might possibly be the "best" (due to lack of knowledge I'm regrettably far from voicing a sound opinion on that) I have to say, though, that I'd VERY much like to have scripting support in the Affinity apps. From a practical point as a designer/user I'd really love to have the sort of possibilities I had (or still have) with the Adobe apps (especially Illustrator) that rely on the use of customizeable scripts leading to special visual "effects" which the app by default doesn't offer..

From this point of view I'd think the actual script language to choose would be the one which best supports creation, distribution and (non-techie)user-friendly usage of interesting scripts...

 

[sfriedberg]

I'm with Lorox.  I loathe Visual Basic for Applications, but I have written a number of scripts in it because it's what the applications in question supported.  Everybody has a favorite scripting language.  If you wait long enough, most of them will vanish into the misty past of trendy tools with no longevity.  I don't even try to predict the exceptions, and use whatever is available.

[Frank Jonen]

Going by most user friendly and easy to read/write, cross platform, most connectivity to other application, there really isn't another choice but Python. It became the lingua-franca of inter-app communication (despite D-BUS) and in-app automation. I think Adobe might have been the only ones who run JavaScript embedded into a desktop app (outside of browsers and browser-based apps).

As far as adoptability: I don't think JavaScript/ECMA has ever been accused of being user friendly. 

[sfriedberg]

Everybody has a favorite scripting language, Frank.  But no scripting language is everybody's favorite.

In practice, the Affinity document/object API and its binding to the scripting language is going to be far more significant than the language itself.  An incomplete, poorly organized and badly documented API/DOM will be agony to use in any scripting language.  Conversely, a comprehensive, modular and well-documented API/DOM will be easy to use in any scripting language.  We don't need Serif to give us Python, or Lua, or Perl, or ECMAScript, or FORTH, etc.  We need them to give us an API.

[MikeW]

An API without a language means nothing. Serif will need to make a choice. 

If Serif will eventually include html5 export, JS is the logical choice as the html5 will be depending upon it. Unless they also make a mini server to upload as well. Maybe I'm wrong. 

[thomaso]

2 minutes ago, MikeW said:

Unless they also make a mini server to upload as well.

Can you explain this please? In what way is an upload related to a script language, and why "unless...also"?

[sfriedberg]

4 hours ago, sfriedberg said:

 API and its binding to the scripting language

 

3 hours ago, MikeW said:

An API without a language means nothing.

Emphasis added to the original to promote clarity of reading.

[michalmph]

Is this thread turning into a battle of which language is better, with no support for any language anywhere on the horizon?

From my point of view there are two really important questions right now:

1. Is there going to be a scripting feature of any kind that lets me automate stuff and integrate Serif apps with my current Adobe pipeline? (api calls, plugins, inbuilt script editor, whatever, as long as there is documentation for it)

2. If yes, are there any estimated timelines when it becomes available?

Until these are known, there's no purchase decision from me.

Additionally, I don' t think that there is any point in discussing language support and approach to scripting at this stage - because of the two points above, and because it's Serif's business decision that should be based on their analysis of the market and client base, not personal preferences of a bunch of people with varying degrees of experience on an internet forum. To put it bluntly - I'd prefer to have good job security with Affinity apps scripting in my portfolio, rather than having the apps support my preferred language.

[Jered]

3 minutes ago, michalmph said:

and because it's Serif's business decision that should be based on their analysis of the market and client base, not personal preferences of a bunch of people with varying degrees of experience on an internet forum.

Yep. You're right. 😅

[Grzeniu]

Vote up for any scripting possibility. Even starting from very basic possibilities and step-by-step implementing more and more. If that would be added in 2.0 and new license needs to be purchased - no problemo, I'm all in. Scripting will be so useful!

[willyt]

Python for me. It's used in most other software that has pro scripting now. Others have mentioned graphics software, it's also pretty common in CAD. Also, if you need to do stuff to AppleScript other applications on Mac it's easy to call out to AppleScript from python. Here's a bit of Python code I wrote in my CAD software that takes some regenerated renderings and replaces them in a report using AppleScript:

if os.path.exists(reportDoc):
    log("Looking for report {} to update".format(self.chosenReport))
    script = """
    set imgs to {{""}}
    set replaceList to {{{}}}
    set reportDoc to POSIX file "{}"
    set diagramsFolder to "{}"
    tell application "Pages"
        activate
        set the activeDoc to open reportDoc
        tell activeDoc
            repeat with theImage in images
                set theFile to file name of theImage
                set theFilePath to diagramsFolder & "/" & theFile
                if file name of theImage is in replaceList then
                    try
                        set file name of theImage to POSIX file theFilePath
                    on error errMsg
                        display dialog "A problem occurred while trying to replace the image: " & theFile
                    end try
                end if
                copy theFilePath to end of imgs
            end repeat
        end tell
    end tell
    get imgs
    """.format(replaceList, reportDoc, self.diagramsFolder)


    log("Report {} located".format(self.chosenReport))
    p = Popen(['osascript', '-'], stdin=PIPE, stdout=PIPE, stderr=PIPE)
    stdout, stderr = p.communicate(bytes(script,'UTF-8'))
    log("{} {} {}".format(p.returncode, stdout, stderr))

If you use javascript you lose access to the whole ecosystem of python packages that can be used to do basically anything. e.g. I've written stuff that takes images taken on my phone and uses a python library to extract the EXIF data to get the lat long and direction and then uses another python library to do GIS calcs to translate them into the coordinate space of my CAD drawing and then uses the python integration in my CAD software to place the lines representing the points and direction of the photos on a site plan. Took me about a day to put that together in python. I have no idea where I would start trying to do that in javascript because, as afar as I am aware, there are no easy to use libraries available to do this stuff in Javascript.

[Graeme W]

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.

[willyt]

For sure. I think I am looking at it from the point of view of workflow scripting that interacts with other software and files on my machine and probably remote servers. If you were looking at it from the point of view of coding graphics and page layout using a DOM like system without leaving whichever Affinity product you are in then javascript probably makes sense as most people with javascript experience that you will be getting to write code in your graphics apps will be coming from a DOM scripting background. I have to say that I'm already compromising by choosing Python though, Ruby is my favourite. 😅

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

[fde101]

On 9/17/2020 at 8:23 AM, willyt said:

It's used in most other software that has pretends to have pro scripting now

fixed

 

On 9/17/2020 at 8:23 AM, willyt said:

If you use javascript you lose access to the whole ecosystem of python packages that can be used to do basically anything.

There is also a small army of packages for ECMAScript (which people still call JavaScript in spite of the standards) that can do basically anything; same can be said for Perl and several other languages.  Perl is preferable to either of those languages but not really all that great either.

In all honesty I have yet to encounter a scripting language that I actually liked.  Ada is clearly the best general-purpose programming language out there, but far to heavy-weight for use as an embedded scripting language.

In particular though my vote is against anything that uses curly braces for delimiting blocks or indentation as any part of its syntax.

 

On 9/17/2020 at 9:07 AM, Graeme W said:

I havn't used Quark in a long time (v6.5) so I have no idea what that uses other than just Applescript.

ECMAScript, which they also erroneously call JavaScript: https://www.quark.com/documentation/quarkxpress/2018/english/QX.js Scripting Guide/_b6943351-85b6-4c72-aff9-1eafbaa1918e.html

 

On 9/22/2020 at 12:23 PM, Graeme W said:

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.

Yes, that would be a good thing.

[MikeW]

58 minutes ago, fde101 said:

[QuarkXPress] ECMAScript, which [Quark] also erroneously call JavaScript:  ...

You say potato, I say...

Quote

JavaScript was invented by Brendan Eich in 1995, and became an ECMA standard in 1997.

ECMAScript is the official name of the language.

From 2015 ECMAScript is named by year (ECMAScript 2015).

So while it is technically named ECMAScript, it is so because of the standards once taken over. But I don't know of any back-end web developer who calls it anything but JavaScript unless they are referring to the standards and specifically as to what version of the standards.

[fde101]

48 minutes ago, MikeW said:

You say potato, I say...

Whatever name you want to stick on it, it is a convoluted mess.

Two functions in the language which should by all means work quite similarly end up working completely differently because they were designed by two different companies shooting for mutual incompatibility to try to edge the other out of the market then both ideas were adopted into the "standard" for the same language.

Even when people try to design languages that are hard to use they still tend to wind up creating something that is more consistent with itself than ECMAScript/JavaScript is.