Jump to content
You must now use your email address to sign in [click for more info] ×

Recommended Posts

Having done my fair share of scripting in InDesign myself, I can assure you that JavaScript and the way it is integrated is everything but a smooth experience.

You get to choose between half-hearted integration where scripts need to be run from a list on a panel where it runs once and then it's over, and a second scripting engine that keeps the script running, which is necessary for creating your own menu items that can respond to user input at any time. The latter leads to all sorts of craziness and bugs and quirks, especially when the script is run twice (which might happen randomly if you try to load it automatically with InDesign), both engines make it difficult to use shared code between scripts in separate files. Not to mention that at this complexity level, the shortcomings of JavaScript as a language are just painfully apparent (not to mention Adobe's developer tools – ExtendScript Toolkit is an abomination). I found myself cursing more than saving time and resorted to writing only scripts that I absolutely needed and without any of the user friendliness required to share them with other users.

I've also written a vector-based particle system in Python that generates SVG files that can be opened in Affinity Designer – everything about that experience was smooth, efficient, and enjoyable, unlike fighting with ExtendScript.

51 minutes ago, kimtorch said:

I'm not aware of any standard Mac app which supports python but literally thousands that support Applescript.

The level of control required for writing extensions for a professional graphics or multimedia software differs from small automation tasks that Apple Script is intended for. There is no doubt that one can solve complex tasks in AppleScript of course, but it's by no means well suited nor intended for that type of thing.

Remember, we're not just looking for a way to automate quick tasks, otherwise we'd be discussing an improved macro feature. We want a solution that is easy, quick and simple with a low learning curve for simple automation tasks, but scales well for complex tasks that border on a plugin, satisfying the demands of experienced developers and giving the end users a well-integrated experience.

If you look at professional film and visual effects software like Maya, Blender, DaVinci Resolve, Modo, TheFoundry Nuke – they all use Python, and their scripting capabilities are way beyond what JavaScript and AppleScript would usually be used for. With Maya, the learning curve for creating, say, a basic script that creates a bunch of objects in your scene is extremely low (for someone without programming experience, I'd say even easier than JavaScript). But if you want to and have the skill, you can also achieve the same level of integration that a C++ plugin would have, or integrate the software with your effects pipeline for the next StarWars or Pixar movie.

51 minutes ago, kimtorch said:

If Affinity do the syntax and object model right, a lot of existing ID code could even be reusable/transportable which would be a HUGE consideration to switching.

As much as we would all love this, there is just no way that porting existing InDesign scripts will be that easy. Any developer will tell you that you can't just copy and paste code from one platform to another. The internal object models of Affinity and InDesign are different enough that you'll have to rewrite most of the code anyway. Trying to make the Affinity scripting API as similar to InDesign's as possible would severely limit its usefulness. There is no point in Serif copying Adobe's mistakes for the sake of compatibility that won't be achievable anyway.

Not to mention that the Affinity API needs to cover Photo and Designer as well, and InDesign, Illustrator and Photoshop all have very different ExtendScript object models, so which one should the Affinity be modeled after?

52 minutes ago, kimtorch said:

I believe Python would turn existing ID users off - it certainly would me as I don't want to learn yet another language.

I would encourage you to take just a few minutes to skim over an introductory Python tutorial – the simplicity is kind of addictive, I think you'll like it!

Link to comment
Share on other sites

Just because Adobe's implementation isn't great doesn't mean Affinity's won't be.

This aside, the major thing that you're missing is the integration with other applications. For example, I can't use Python to access a Filemaker database and script that into AP (or ID). I can't easily tap into my Mail program or Capture One or Excel or my own apps. People tend to forget the cross application integration that Applescript allows.

I'm not for a moment suggesting Applescript or Javascript (with which I have little experience) are perfect, but they *are* extremely practical and Applescript in particular allows far greater inter-application functionality than any other available language. This is something Affinity should consider - are they just going to script AP or are they going to allow functionality to be greatly extended with access to non-Affinity apps?

Link to comment
Share on other sites

10 minutes ago, kimtorch said:

...and Applescript in particular allows far greater inter-application functionality than any other available language. This is something Affinity should consider - are they just going to script AP or are they going to allow functionality to be greatly extended with access to non-Affinity apps?

The main issue as I understand it is in order to keep functionality on both OSs even semi-equal, and if Serif used AppleScript on the Mac, to achieve the same level of extra-application functionality, it would take using VBA (I suspect). And while I do a little VBA in Excel, Word and CorelDraw these days, it really isn't the best way to go and requires the installation of say Visual Studio or the like.

Of course, if Serif wrote an AppleScript interpreter for Windows I would be all over it. Simple langauge and yet has enough power I think. Windows would lose out on the extra-application support, but I would welcome AppleScript for inside Affinity applications.

Whatever they use I cannot imagine it would be something that requires users to download, install and configure Python. Even if they did write an installer that would pull the correct libraries.

How well JS integrates is really up to Serif. But it cannot simply be "JavaScript." It has to be extended else there won't be the ability to build dialogs and capture more than simple input requests.

Mike

Link to comment
Share on other sites

Python will just be bundled into the applications and loaded as a library. As mentioned above, virtually every other content creation package as well as virtually all other commercial applications that want to offer scripting are using Python these days (LUA is the other one you see occasionally).

AppleScript is not portable, VBA is not portable, Javascript is honestly a terrible application scripting language (though you get a little bit of synergy from how ubiquitous it is in the web design world) and requires at least as much infrastructure if not more than Python to include in your software.

I'm going to go out on a limb here and predict that the Affinity scripting language is going to be Python.

As far as learning another language goes, Python is so ubiquitous these days that learning a little python will pay back dividends over and over for you in the future. Also when you're using it as a scripting tool you don't need to know much of the language as you can get a long way (farther than Javascript in my opinion) by just copying and modifying example code.

Link to comment
Share on other sites

5 hours ago, MikeW said:

But it cannot simply be "JavaScript." It has to be extended else there won't be the ability to build dialogs and capture more than simple input requests.

Dialogs, menus are all part the GUI.

Serif can elect to allow JavaScript to call all those elements which are part of the software anyway.
So, no, I don't think JavaScript needs to be extended to deal with that.

Interesting times ahead. :D

2017 27” iMac 4.2 GHz Quad-Core Intel Core i7 • Radeon Pr 580 8GB • 64GB • Ventura 13.6.4.

iPad Pro (10.5-inch) • 256GB • Version 16.4

Link to comment
Share on other sites

Regarding integration with other software: You can access Apple Script interfaces of other applications from Python scripts with Apple's Scripting Bridge. You could certainly talk to FileMaker from within a Python script that way.

An Apple Script interface that's basically "tell application Affinity to run the following python code" would also be conceivable for the other way round, though the coding experience that way admittedly wouldn't be great, so some basic Apple Events and COM support (as well as command line switches!) would definitely be useful. Adobe is running a dual-platform strategy, too, with COM/Apple  Events in addition to their own ExtendScript.

With Python, another great opportunity would be to also allow installed Affinity apps to be used as a scripting library so that it can be used from standalone Python scripts. Autodesk Maya and Toxik as well as DaVinci Resolve offer that option for example. This would allow you to write a script that runs outside Affinity, but generates, uses and manipulates Affinity files using the Affinity engine. That would allow you to solve problems via scripting without the user having to manually open Affinity apps and click around in them.

That way you could, say, make a Python script for Resolve that applies an Affinity Photo macro to each frame of a clip for example, or one that automatically loads news graphics and lower thirds from Designer files and allows you to update the text objects contained inside from within Resolve, but have the resulting graphic rendered by Affinity with any effects and complex clipping you might have applied to the text. Or automatically generate catalogs based on your product database and a template, send them to an external designer who is using Affinity Publisher and when they send the finished file, automatically fill in the most recent prices for each product with a second script, all without anybody except the designer having to click around in Publisher. All you'd need would be a license of Designer installed on that machine.

Or combine this with something like Flask and you even have a viable alternative to Adobe's insanely expensive InDesign Server that would require only minimal effort on Serif's part because it would just be the regular scripting API packaged into a Python module.

One thing we'll have to consider, though, is that Affinity products run in Apple's store sandbox on the Mac and on iOS. This may impose restrictions in terms of what's possible in terms of cross-application communication.

Also, the discontinuation of Automator doesn't exactly inspire confidence in the future of the AppleScript platform – I hope I'm wrong, but I have a hunch that AppleScript may not have the brightest of futures.

Link to comment
Share on other sites

29 minutes ago, Peter Werner said:

Also, the discontinuation of Automator doesn't exactly inspire confidence in the future of the AppleScript platform – I hope I'm wrong, but I have a hunch that AppleScript may not have the brightest of futures.

That's something that came to my mind too.

I think Apple is working on another solution. I don't think they want to abandon automation at all, they want to improve it.

Who knows some sort of simplified Swift for automation?

2017 27” iMac 4.2 GHz Quad-Core Intel Core i7 • Radeon Pr 580 8GB • 64GB • Ventura 13.6.4.

iPad Pro (10.5-inch) • 256GB • Version 16.4

Link to comment
Share on other sites

5 hours ago, Seneca said:

Dialogs, menus are all part the GUI.

Serif can elect to allow JavaScript to call all those elements which are part of the software anyway.
So, no, I don't think JavaScript needs to be extended to deal with that.

Interesting times ahead. :D

I meant to actually build dialog boxes. Not call up ones like a macro can. That cannot really be done well without extending JS. 

Link to comment
Share on other sites

Quote

I would encourage you to take just a few minutes to skim over an introductory Python tutorial – the simplicity is kind of addictive, I think you'll like it!

I'm just not finding that to be the case.

I'm an illustrator. My interest in scripting is not just a glorified macro; I use Javascript to programmatically draw things.

I'm not a programmer per se, and don't play one on the internet. But I've been able to accomplish profitable things with JavaScript in surprisingly short order and with quite productive results:

  • FlashScript interactive simulations which replicate the behaviors of real-world mechanical systems (multiplex wiring, regenerative exhaust systems, air brake systems) for training.
  • A whole library which effectively adds important missing features to AI, including a set of non-modal palettes for facilitating axonometric drawing in any isometric, dimetric, trimetric orientation.
  • Similar interactive axonometric tools by using Javascript to manipulate SVG in ordinary HTML.
  • Integrating Javascript into FileMaker Pro calculations to build interactive axonometric "visual calculators" that run in FileMaker's WebViewer objects.

I quit expending energy developing AI-specific Javascripts the instant Adobe started its Captive Customers scheme. But found it easy to lateral my developing Javascript familiarity from FlashScript to so-called ExtendScript to plain vanilla Javascript in HTML, and even into FileMaker Pro. I did all the above without reading tomes on Javascript. I've done it by just learning the basic syntax logic on W3C, looking at a few examples, and referring to the program-specific Object Model documents.

Looking to do similar things in Inkscape meant getting familiar with Python.  I've expended way too many hours of precious little spare time reading various Python books, starting with downloading the resources that have to be installed on the machine, dinking with the command line interface, yadda yadda. While there's nothing "difficult to understand" per se, I have yet to accomplish anything actually useful with it, don't find it any more intuitive than JavaScript, don't particularly care for its sensitivity to white space.

Can I do it? Sure. But I've already found the afore-mentioned ubiquity of JavaScript across platforms and disciplines advantageous. I have yet to see any compelling reason to "start all over" with Python, other than it's been adopted by Inkscape for developing extensions. But that already seems more cumbersome than what I was doing with Javascripts for AI. (And yeah, I know this is mainly just a matter of my familiarity.)

Again, I'm not the expert in this. But every time another language comes along, its devotees start over-evangelizing it as a replacement for everything pre-existing, and frankly I've grown weary of that over the last few decades. It's not that I have anything "against" Python. My own daughter-in-law uses it for various things (mostly related to gaming). But I also don't see JavaScript "going away" by any stretch and even in my modest experience, I have had much opportunity to appreciate its general versatility.

So, for what it's worth, and since we rather presumptuously seem to think the Affinity Team's decision is going to be driven by a "scripting election" in this thread, my vote is for Javascript--and a very thorough object model document. Seems a safe bet to me.

Oh...and having abandoned MacOS almost two decades ago, and despite being an avid FileMaker Pro devotee, I have no more use for scripting anything with a proprietary language prefixed by "Apple…" than anything strictly proprietary to Adobe.

;-)

 

Link to comment
Share on other sites

29 minutes ago, JET_Affinity said:

Looking to do similar things in Inkscape meant getting familiar with Python.

Inkscape is by no means representative of what Python scripting looks like when it is well integrated. Inkscape's Python seems like an extremely crude API that requires you to mess with some SVG DOM, write a bunch of superfluous boilerplate and integrate a bunch of third party libraries to do anything useful. That's by no means the fault of the programming language.

I wouldn't want to use that, either.

See this example of what a basic script for Illustrator in Python (using COM due to lack of native Python bindings) looks like. Not very different from JavaScript, really.

37 minutes ago, JET_Affinity said:

downloading the resources that have to be installed on the machine, dinking with the command line interface, yadda yadda

Nothing of the sort would be necessary with a proper embedded Python interpreter. You could of course mess with third party packages if you wanted to.

43 minutes ago, JET_Affinity said:

I have yet to accomplish anything actually useful with it

As an example, I'll attach a simple graphic that I generated with Python (using the interpreter that came pre-installed with OS X). The script can render to PNG using PIL (as attached) or write an SVG for use in Designer or Illustrator. Took me a lot less time than doing something like that as a script compared to doing it by hand. I can use any gradient for colors, use an image texture to modulate the size, birth or position randomization of the particles, color the connection lines, and much more. The result can be manipulated in Designer as if it was created directly with its drawing tools.

@MikeW:

1 hour ago, MikeW said:

I meant to actually build dialog boxes. Not call up ones like a macro can. That cannot really be done well without extending JS. 

Nothing can be done with a programming language per se except do maths and data manipulation. Scripting always means "extending" the language with an object model. User interfaces (whether on desktop or mobile) are no different than documents, layers, text frames and cat objects in that respect. Some scripting APIs just skip the UI part (or, cough, rely on Flash or HTML), which obviously leads to a rather underwhelming user experience.

0021.png

Link to comment
Share on other sites

Seneca wrote:

> I don't think that a half-hearted approach to scripting will do.
> Do it properly from the start. We should be able to automate everything. InDesign is a good example here.

I wholeheartedly agree. Scripting is useful only when you can script everything you can do in the interface. That's what sets InDesign scripting apart from Photoshop, Illustrator and all the other scriptable Adobe applications. In InDesign you can script everything. Photoshop and the others expose only part of their document models, which has frustrated script writers for years. I'm for JavaScript and/or Python. If you go for JavaScript, please add a component that allows us to read and write files.

Link to comment
Share on other sites

On 9/12/2018 at 12:12 AM, kimtorch said:

I believe Python would turn existing ID users off - it certainly would me as I don't want to learn yet another language.

Probably not. Python support is a popular item in InDesign's feature request forum (User voice).

> If Affinity do the syntax and object model right, a lot of existing ID code could even be reusable/transportable which would be a HUGE consideration to switching.

That would indeed be useful but is hardly likely to happen.

Link to comment
Share on other sites

  • 2 weeks later...

I realize that Serif is not taking a poll to decide on a scripting language, but if it were, my vote would be for Python. 

There may (or may not) be a minor increase in the learning curve, but in my experience it is considerably easier to use when developing and debugging scripts of even modest complexity. It also has a much wider range of capabilities.  It is useful for tasks ranging from simple scripting to advanced computer vision and AI (when used in conjunction with some of the existing Python packages and libraries out there), and therefore is considerably more future-proof.

Not that I have any insight into Serif's development process or plans, but a Python scripting capability might even be useful to their own development teams.

Link to comment
Share on other sites

  • 3 weeks later...
On 9/15/2018 at 11:24 AM, Peter Kahrel said:

Python support is a popular item in InDesign's feature request forum (User voice).

As soon as Affinity released Affinity Photo and Affinity Designer to the wild, requests for scripting capabilities in these apps equally soon emerged.

At that time (3.5 – 4 years ago) I was all for JavaScript. Now, I'm not sure whether Python would be a better choice.

I have a feeling that Adobe is working towards supporting Python in their suite of apps.

I would be delighted if Affinity offered both languages as an option. Python in particular has been  a very popular choice of recent because of the whole ML shebang and has gained in popularity as a result of that. 

AppleScript would be a popular choice among the Mac programmers, but unfortunately, as far as I am concerned it's a dead end. Apple itself hasn't done anything to AppleScript over the last decade and I suspect they are working on a new scripting solution, most probably Swift based. Most of all AppleScript is not a cross-platform solution and therefore it cannot be taken seriously as a viable option.

2017 27” iMac 4.2 GHz Quad-Core Intel Core i7 • Radeon Pr 580 8GB • 64GB • Ventura 13.6.4.

iPad Pro (10.5-inch) • 256GB • Version 16.4

Link to comment
Share on other sites

1 hour ago, Seneca said:

At that time (3.5 – 4 years ago) I was all for JavaScript. Now, I'm not sure whether Python would be a better choice.

7 minutes ago, fde101 said:

QuarkXPress has evidently supported AppleScript for some time but recently added JavaScript and seems to be making a big deal out of it.

Regardless of what Serif ends up doing as regards scripting, it is only going to be as good as the DOM support is. Case in point is QXP's JavaScript support. QXP's DOM and methods to manipulate the DOM is growing, but unless it gets a move-on I'm afraid interest will wain and so will development.

So while I have just a preference of JavaScript vs. Python, I don't really care. But I would recommend to Serif to have its scripting support pretty well fleshed out as regards the document model and its methods before it is introduced. It is this area that more is better.

Mike

Link to comment
Share on other sites

  • 1 month later...
On 8/31/2018 at 7:14 AM, kimtorch said:

Ability to export using defined PDF Presets (export to myPath with PDF Preset "My Preset")

Yes, that would be very useful in my case. I export my PDF with multiple presets as I need versions for backup (no rasterisation, no downsampling), the printers version (300dpi, all rasterised, downsampled), a preview version (100dpi, optimized for file size) and a softproof version (same as preview with changed ICC profile).

Building up general functionality for those special cases can somehow clutter the options, so scriping is the way to go.

I care if it's JavaScript, Python or something you think is fitting as long as it runs under all platforms.

Scriping support with AppleScript only running in the mac version sounds really wrong.

Windows 10 Pro x64 (1903). Intel Core i7-9700K @ 3.60GHz, 32 GB memory, NVidia RTX 2080
Affinity Photo 1.7.2.471, Affinity Designer 1.7.2.471, Affinity Publisher 1.7.2.471

Link to comment
Share on other sites

48 minutes ago, Steps said:

Scriping support with AppleScript only running in the mac version sounds really wrong.

The benefit of AppleScript / scripting bridge support, to my way of thinking, has less to do with extending any one application and more to do with being able to tie applications together more effectively.  Other languages such as JavaScript, Lua, and that snake thing are only useful for tasks that happen inside of a single application.

 

In fact, while scripting bridge is Mac-only, there is a similar facility in Windoze in the form of WSH: https://en.wikipedia.org/wiki/Windows_Script_Host

 

I think there is room for both: support for the platform-specific methods to tie the products together more effectively with other scriptable applications (to play nice with others), and an internal language (Lua, JavaScript, AffinityScript, whatever) to extend the functionality within the application itself.

Link to comment
Share on other sites

3 minutes ago, fde101 said:

The benefit of AppleScript / scripting bridge support, to my way of thinking, has less to do with extending any one application and more to do with being able to tie applications together more effectively.  Other languages such as JavaScript, Lua, and that snake thing are only useful for tasks that happen inside of a single application.

 

In fact, while scripting bridge is Mac-only, there is a similar facility in Windoze in the form of WSH: https://en.wikipedia.org/wiki/Windows_Script_Host

 

I think there is room for both: support for the platform-specific methods to tie the products together more effectively with other scriptable applications (to play nice with others), and an internal language (Lua, JavaScript, AffinityScript, whatever) to extend the functionality within the application itself.

This needs the biggest effort on Serif's site to implement and maintain, but it would surely give best results.

So I fully agree with you here.

Windows 10 Pro x64 (1903). Intel Core i7-9700K @ 3.60GHz, 32 GB memory, NVidia RTX 2080
Affinity Photo 1.7.2.471, Affinity Designer 1.7.2.471, Affinity Publisher 1.7.2.471

Link to comment
Share on other sites

I am doing both print design and also programming websites. And i have generated some books using indesign scripting.

  •  Indesign scripting is not good because it is many things slapped together with old legacy support. Also the Javascript there is really old. This does not mean Javascript is bad choice.
  •  Apple script is really bad choice for multiple reasons:
    • It is not platform agnostic - i am mac user but there are many win users and you just need shared ecosystem of scripts period.
    • This would mean having Serif supporting multiple languages one on mac one on windows. Too big burden.
    • As far as i know apple script is going away. It might just happen that apple just kills it.

So any good scripting language will do honestly. Current Javascript, Lua or Python are all good choices. I am sure Serif knows about all of the above and are working on some unified scripting solution for all of affinity software.

If you would ask me Javascript would probably be best choice (similarly for how most game engines use JS for scripting) because it is just most commonly used programming language. It has biggest amount of libraries, tutorials and resources. You will easily find someone who can program JS. Biggest plus actually could be (in future) similar thing what adobe is doing. Including light webrowser and using html+js for scripts UI - this is easiest way how to add some UI to your software. This is not possible with python or lua.

Anyway Serif please do it some day. And please do just One proper way.

Link to comment
Share on other sites

22 hours ago, Florian Karsten said:

And please do just One proper way.

The issue here is that any "one" way that works on both platforms will be limited to working only within the application.  Support for OS-level scripting languages such as AppleScript allows multiple programs to be tied together and automated using a single script, so that the functionality of several scriptable applications can be combined.  A scripting language built-in to the product can't do that.  There is a place for both.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.