Scripting

[Petar Petrenko]

2 minutes ago, chessboard said:

JavaScript may not be a particularly attractive language for purists

I vote for Python because of its elegance, simplicity and efficience, but to be honest, with JavaScript we can have access to plenty of scripts written for InDesign which we can modify if needed to accomodate for Affinity products.

[v_kyr]

Since the Affinity scripting team already spend some amount of time into it's JS implementation, it's now too late for voting and other script language suggestions. Thus people will have to adapt/wrap their prefered prog languange on their own. And in order to be able to do that at all, having a good reference documentation and some related code examples are mandantory essential here.

[fde101]

9 hours ago, v_kyr said:

people will have to adapt/wrap their prefered prog languange on their own

Not necessarily - they could also:

• License a programming language plugin from a 3rd party who decides to market one
• Not write scripts or plugins for the Affinity products and simply use them as-is
• Hire someone else to write scripts for them

[v_kyr]

15 minutes ago, fde101 said:

Not necessarily - they could also:

• License a programming language plugin from a 3rd party who decides to market one
• Not write scripts or plugins for the Affinity products and simply use them as-is
• Hire someone else to write scripts for them

That's what was generally meant here, as all then has still to be made by some people in this scripting theme context. As nothing comes automagically by itself and thus must first be created by someone, no matter if some third party people, or some hired people here etc.

[deeds]

The advantages of JavaScript far outweigh any advantages of Python, IMNSHO, for anything to do with creativity and user empowerment extensions of an engine/core written in C/C++.

It's easy to think of JavaScript as a "lite" and dynamic C with objects/prototypes as an added means of wrapping, and dot notation for access, and go from there.

Further, any programmer able to make something significant with Python will be able to do the same thing in JavaScript, or Lua, Wren, or MaxScript or any other scripting language, as scripting languages are no longer the barriers to production. With the possible exception of Apple Script, which is a wholly different beast able to turn sane men mad.

Similarly, any skilled vector artist can produce with Illustrator, CorelDraw, Freehand, Designer etc. They might not like the workflow as much in some of them, but minus the need for a Blend tool, they can do their vector works in any of these.

However, the processes of making a binding between an evolving program (and Affinity products are definitely evolving) and a scripting language needs (for best rates of production and freedoms of evolvement) a stable, specific scripting language choice for optimal flexibility so the tail doesn't wag the dog.

Any attempt to be a truly agnostic creative engine for all scripting languages will heavily wag the dog and quickly begin curtailing and/or slowing the evolvement of the underlying software, despite the fact that scripting empowerment of a user base rarely leads to significant general buying of the software.

The provision of plugin development in native languages, however, is a whole other thing, and also should not be at all curtailed or limited by scripting language choice, and especially not by a choice to try to be generically and generally extensible by all/any scripting languages. Plugins are a long game, though, and might be over for most creative software, now that we have "AI" that's soon going to be able to control other software. 

 

[chessboard]

For me, as a user of Affinity applications, scripting is much more important than plug-ins. Scripting means that I am able to define a specific task myself that the software performs on its own (for example, batch processing a batch of graphic designs).

Extending the software with plug-ins may be nice and even effective in some cases. But in my experience, plug-ins in Photoshop or Illustrator are far less important to my daily work than the ability to automate tasks by actions and scripting (in fact I really don't use the plug-ins I once installed at all). Often, plug-ins just provide a streamlined workflow or automate tasks (just what scripting is made for) rather than truly extending the software with new functions. Or on the other hand they are almost stand-alone software packages that would work better as separate applications (what they exactly do in some cases).

Therefore from a users view, if we can't get a sophisticated macro or actions system in all the Affinity apps (like in Photoshop), scripting is all the more important. Way more important than plug-ins.

[v_kyr]

7 hours ago, deeds said:

The advantages of JavaScript far outweigh any advantages of Python, IMNSHO, for anything to do with creativity and user empowerment extensions of an engine/core written in C/C++.

It's easy to think of JavaScript as a "lite" and dynamic C with objects/prototypes as an added means of wrapping, and dot notation for access, and go from there.

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.

Quote

Further, any programmer able to make something significant with Python will be able to do the same thing in JavaScript, or Lua, Wren, or MaxScript or any other scripting language, as scripting languages are no longer the barriers to production. With the possible exception of Apple Script, which is a wholly different beast able to turn sane men mad.

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.

Quote

The provision of plugin development in native languages, however, is a whole other thing, and also should not be at all curtailed or limited by scripting language choice, and especially not by a choice to try to be generically and generally extensible by all/any scripting languages. Plugins are a long game, though, and might be over for most creative software, now that we have "AI" that's soon going to be able to control other software.

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.

[v_kyr]

3 hours ago, chessboard said:

... Therefore from a users view, if we can't get a sophisticated macro or actions system in all the Affinity apps (like in Photoshop), scripting is all the more important. Way more important than plug-ins.

The main difference here is maybe, that plug-ins are meant for some predefined specific purposes/tasks, like for example B&W conversions and fine tuning, denoise images ... etc. Where in contrast to that Macros/Action/Scripting allow you to define your own tasks, the way you would like to perform things by reusing an apps build-in capabilities and partly to add own specific additions here.

[fde101]

9 hours ago, deeds said:

The advantages of JavaScript far outweigh any advantages of Python

Granted that Python is one of very few languages that I consider to be worse than ECMAScript...  and that is saying a lot.  Both of them are pathetic.

 

9 minutes ago, v_kyr said:

plug-ins are meant for some predefined specific purposes/tasks, like for example B&W conversions and fine tuning, denoise images ... etc. Where in contrast to that Macros/Action/Scripting allow you to define your own tasks

If done correctly, scripts will simply be plugins with less verbosity involved in introducing them into the system, compiled on demand or interpreted (depending on the language implementation) rather than being pre-compiled.

Outside of hooking into the underlying hardware or operating system there really isn't much if anything that traditional compiled languages can do that scripting languages cannot.

[v_kyr]

4 hours ago, fde101 said:

If done correctly, scripts will simply be plugins with less verbosity involved in introducing them into the system, compiled on demand or interpreted (depending on the language implementation) rather than being pre-compiled.

Of course they could also be treated and used in such a manner if wanted. Other apps do and offer that in a similar fashion via their specific scripting APIs.

4 hours ago, fde101 said:

Outside of hooking into the underlying hardware or operating system there really isn't much if anything that traditional compiled languages can do that scripting languages cannot.

Compiled or interpreted it's just a different code execution model which usually comes together with an execution speed difference. - For example Basic was, AFAI recall, in former PC-/MS-DOS times first an interpreted language, later there was a Basic compiler too. In the past there where some tiny C interpreters too, not just compilers. Also every better LISP implementation comes together with a combined interpreter & compiler part. Programs in Lisp can be interpreted or translated into efficient code by an optimizing compiler.

Lua is another good example here, it's not just one of the fastest interpreted scripting languages, it also comes along with Luac for precompiling code for even faster loading & execution speeds. There's also LuaJIT (a Just-In-Time Compiler for Lua) ...

... and so on.

Quote

Granted that Python is one of very few languages that I consider to be worse than ECMAScript...  and that is saying a lot.

Not really, as we don't know your long time experience and knowledge with either of those.  Further it's ecosystem & runtime env isn't (IMO) almost as bad as NPM here.

[Jon W]

3 hours ago, fde101 said:

If done correctly, scripts will simply be plugins with less verbosity involved in introducing them into the system, compiled on demand or interpreted (depending on the language implementation) rather than being pre-compiled.

This is the approach we are taking. In our world, scripts are just interpreted plugins, with the exact same capabilities as compiled plugins. 

[David Cake]

On 4/18/2023 at 5:06 PM, Jon W said:

In addition, the JavaScript engine is itself implemented using our plugin SDK, to which we plan to add support for alternative scripting engines (i.e. you could in theory write your own plugin to support Python or any other language).

If there is a supported C API, that will be enough to create a plug-in that supports Python. If the JavaScript API is a direct wrapper around the C API, such a Python API would be able would be do anything the JavaScript one could.
If necessary, I’ll write it myself. And open source it.

Regardless of what language people prefer for personal taste, languages are used by different communities, for somewhat different reasons, and multiple options are better than less. I think the teams choices are sensible - an officially supported scripting language is necessary for this to be a feature that is of value to many customers, and JavaScript is probably the most popular choice - but the C API is the real magic here, and they know it.

And it’s great that it we will have the option to make our own scripting options, because we might want to do some thing differently than the official JavaScript API. 

 

[David Cake]

On 4/26/2023 at 7:18 PM, fde101 said:

Outside of hooking into the underlying hardware or operating system there really isn't much if anything that traditional compiled languages can do that scripting languages cannot.

Indeed. And there are a few things that traditional compiled languages can’t do, like relatively easily exchange the same code across platforms. And a lot of the hardware or OS is accessible from scripting languages via libraries anyway. And often you aren’t really getting much speed advantage from compilation when most of the actual computation is going to be taking place inside the host application anyway.

And for everything else, there is the C API. C isn’t my favourite language either, but the C ABI is the lingua franca across interpreted languages, and if you have a C ABI it’s not that hard to whip up a FFI to call it from Rust or whatever else is your favourite.

[v_kyr]

20 hours ago, David Cake said:

... and if you have a C ABI it’s not that hard to whip up a FFI to call it from Rust or whatever else is your favourite.

Basically it shouldn't, though for certain levels of integrity it also highly depends on to/with what objects/methods/functions the C API is then overall hooked to, so what it access wise offers here.

 

20 hours ago, David Cake said:

And there are a few things that traditional compiled languages can’t do, like relatively easily exchange the same code across platforms.

Depends on the overall language design & it's underlayed architecture. With Java, Kotlin, C# ... etc., so JIT compile and certain VM based languages and other available cross-libs you can already easily do that.

[fde101]

21 hours ago, David Cake said:

there are a few things that traditional compiled languages can’t do, like relatively easily exchange the same code across platforms

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.

[v_kyr]

Maybe we should collect some ideas for possible sample scripts, which then could also come along the API & JS scripting docus as so to say reference examples (?).

Here are some few ideas for document related information samples ...

• For a doc iterate over all it's layers in order to get an layers count and also list the layer types/names/ids & their structured order.
• Determine a docs main used working color space profile and also list (print out) all it's used (embedded) icc-profiles.
• List all in a document embedded files and dependent links.
• List the orig text font types used in a document and their possible replacements.
• Determine/get a docs affinity file format version, aka if a v1 or v2 etc. doc file.
• List all defined/assigned color values in a document or palette file etc.
• ... and so on ...

[Jon W]

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

Maybe we should collect some ideas for possible sample scripts, which then could also come along the API & JS scripting docus as so to say reference examples (?).

Yes - please do all feel free to post your scripting-related feature requests here! Whilst we can't promise to implement them all, it would be great to get an overview of what our customers want and expect from scripting. 

[fde101]

30 minutes ago, Jon W said:

scripting-related feature requests

Given the intended parity between scripting and plugin capabilities, a few things that are important to remember if you want to be complete about this:

• File import/export filters
• Custom user interface components (studio panels, menus, menu items, context menu items, etc.)
• Custom tools to be added to the toolbar (with custom context toolbar configurations associated with them) - this one meaning the toolbar with the Move Tool, Hand Tool, etc.
• Custom color pickers which can be defined and added to the Color panel and other related areas of the interface
• Custom brush engines (previously referenced in this thread)
• Custom items to be added to the main toolbar (at the top of the window - this one the toolbar with )
• Custom color spaces (ex. RYB, RGBW, etc.)
• Custom personas (by specifying a name, icon, set of standard and/or custom studio panels, standard and/or custom toolbar items for each toolbar, callback when entering/exiting persona/closing document, etc.)
• Custom smart shapes
• Custom snapping candidate identifiers
• Custom data sources for merge feature (Publisher)
• Custom search criteria plugins for Find and Replace (Publisher)

[Tim Keating]

On 5/12/2023 at 8:03 AM, fde101 said:

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.

Yup. And with modern "low level" languages, like Rust and Go, source code can usually be compiled with minimal fuss on different architectures.

[kimtorch]

Whilst I appreciate everyone wants even the most obscure functions to be scriptable, let's not let 'perfect' get in the way of 'good'. Remember this is a product that currently supports NO scripting at all so I think it's better to keep requests realistic based on where it now sits.

Rather than imagining ideas of what could be done in the future, I suggest people start by submitting what they currently script in InDesign or Quark. This way Affinity have a good idea of what people are currently using and actually NEED in the AP scripting model. From reading this entire thread I'm sure there are a lot of people here who have never scripted InDesign or Quark in their life - they're more concerned about pushing their language preference than actually getting print work done.

But I digress...

Very few of the things I've seen listed are of any interest to us (yes, I know they may be 'important' to others) but we are a publishing company and have a desperate need for the basics of printing and publishing. These aren't things we'd like to do in InDesign - these are things we do literally hundreds or thousands of times a week and need Affinity to support before we'd ever consider changing.

• Generate pages and documents based on templates
• Create frames with definable properties (type, geometric bounds, colours, text properties, name etc)
• I'll reiterate naming of frames as that is vitally important to the way we address target frames in InDesign (script labels)
• Populate frames with text or images allowing all fitting options
• Importing of tagged text and RTF - ideally adopting the Adobe model of tagging so existing frontends would 'just work'
• Create PDFs, jpegs, EPS files with definable presets
• Iteration through frames and placed images
• Ability to manage colour spaces 
• Scripted preflighting

This is obviously not an exhaustive list but it's the primary functions we need to get a start. Our company simply can't run without automation. AP could be the best page layout product in the world but until we can do at least the basics of automation it's essentially worthless to us.

[chradja]

7 hours ago, kimtorch said:

 

• Generate pages and documents based on templates
• Create frames with definable properties (type, geometric bounds, colours, text properties, name etc)
• I'll reiterate naming of frames as that is vitally important to the way we address target frames in InDesign (script labels)
• Populate frames with text or images allowing all fitting options
• Importing of tagged text and RTF - ideally adopting the Adobe model of tagging so existing frontends would 'just work'
• Create PDFs, jpegs, EPS files with definable presets
• Iteration through frames and placed images
• Ability to manage colour spaces 
• Scripted preflighting

I'm currently do a lot professional scripting with Adobe IndDesign and I think you covered here most of the needs. Of course access to a stable kind of ID (or name) of the different block is essential.

But pretty much part of the scripting (on my side) is not only generate full pages, but also piece of them.

Very important also is the ability of the scripting interface to manage or guess all possibles overflows...

[MikeTO]

I'd add that in addition to being able to access the document object model and all object and text attributes, I'd like to see text variables, labels, and generic markers.

[MikeTO]

A few more.

Get (and set) currently selected object / text cursor/range position and attributes.

Get (and set) some of the common settings and current defaults. For example, a script might need to know which measurement system is in use or where files are opened from or saved to.

It would be nice to be able to record actions to generate JavaScript code.

Disable and enable screen redraws, with enable forcing a screen redraw. This would allow complex scripts to do things like generate hundreds of pages without bothering to refresh the screen.

Some way to display a modal progress meter with a cancel button, and of course the ability to update the meter.

Ability to show/hide/position/scale panels, tools, and document windows so scripts can customize the UI.

[Frank Jonen]

On 5/16/2023 at 2:04 AM, kimtorch said:

let's not let 'perfect' get in the way of 'good'

Going for perfect is the only way to arrive at good.

If you're only going for good enough, your best result is going to be mediocre. 

[kimtorch]

36 minutes ago, Frank Jonen said:

Going for perfect is the only way to arrive at good.

If you're only going for good enough, your best result is going to be mediocre. 

This is laughably wrong. Ask Apple, Microsoft, Adobe, Google or any other software producer.

Going for perfect means a product NEVER gets released. Perfect is a utopian aim, but a naive, unrealistic project path - especially for a company the size of Affinity.

InDesign's scripting isn't perfect - but I'm glad we've had access to it for 20 odd years.