Scripting

[RM f/g]

5 hours ago, Old Bruce said:

I would use these sort of scripts in something outside of Publisher, then import the text.

Old Bruce, could you give a hint towards what this ‘something’ would be?

I have been thinking of this solution. ’Something’ would have to support footnotes, so most likely a word processor.

[Old Bruce]

17 minutes ago, RM f/g said:

Old Bruce, could you give a hint towards what this ‘something’ would be?

BBEdit, sadly Mac only and TEXT only so it may not work for your workflow. I love .txt files, only one font in one weight and size. It is heaven there are no Bold/Italic/24 on 30pt

 White Spaces to mess things up.

[RM f/g]

Thanks for your hint.

Myself, I'm Mac only too. I'll have a closer look at BBedit. Who knows?

[angelhdz12]

On 6/21/2019 at 7:33 AM, evtonic3 said:

This is such a lengthy topic that I can’t help but wonder what are people’s goals here to have scripts added to the app? I mean what can one do to better the app that the devs aren’t already doing? Just curious.

Not having to wait for the developers to add missing features and advanced macros/actions.

A lot or programs since 90's allow to do this, like Microsoft Office programs using Visual Basic to automate tasks.

[angelhdz12]

On 6/26/2019 at 8:19 AM, fde101 said:

This is also a great example of why these features should be in user-provided scripts rather than integrated into the software.  The specific corrections are highly specific to the subject material.  Running those corrections on a document which includes programming language code could in some cases change the meaning of the code, rendering the document incorrect.  Particularly with snake-language (err, Python) as the spacing in front of the code is part of the syntax.

Similarly, if the document uses tab stops to format table data, removing "double tabs" could cause data to show up in the wrong column of the table.

This may work extremely well for some kinds of input, but it is not generically safe.  If it is known that the incoming documents are safe to run these corrections on, then allowing the user to write such a script is a great solution for this.

A lot of people complaining about the use of tabs in Python.

So I got a feeling the best 2 languages to automate Affinity programs are Javascript and Typescript (static typing <3 ) .

But something tells me they could end implementing their own language, like Unity with the JScript, Microsoft's dialect of the ECMAScript

[affi.usr]

1 hour ago, angelhdz12 said:

A lot or programs since 90's allow to do this, like Microsoft Office programs using Visual Basic to automate tasks.

Now it is one walk around, but is not very user friendly. For Windows platform you can use AutoIt. Using spy Windows you can get native GUI windows fx. for Affinity Photo:

 

HwndWrapper[Photo.exe;;452e26ab-922c-48d1-ae6b-1160a6b1a0f4]

Using  AutoIt command you can send clicks and keys to simulate real user active work. The most pain is build that way structure to work with it and next create scripting layer called your first created structure. To show up in practise what I mean by structure I paste below example code from Autoit forum (GIMP automation):

Opt("WinTitleMatchMode", 4)

While 1
    If WinGetHandle("[CLASS:gdkWindowToplevel]") Then
        _GetHandles()
        HotKeySet("m", "fractal")
    Else
        HotKeySet("m")
        Sleep(100)
    EndIf
WEnd
Func _GetHandles()
    ;Variables
    global $WindowHandle = WinGetHandle("Programa de manipulación de imágenes de GNU") ;Get handle of the main GIMP window.
    global $ToolboxHandle = WinGetHandle("Caja de herramientas") ;Get handle of the GIMP Toolbox.
    global $WinTitle1 = WinGetTitle($WindowHandle) ;Get title of main GIMP window to test that it is the correct window.
    global $WinTitle2 = WinGetTitle($ToolboxHandle) ; Get title of GIMP Toolbox to test that it is the correct window.
EndFunc   ;==>_GetHandles
Func fractal()
    MsgBox(0, "0", $WinTitle1 & " " & $WindowHandle & @CRLF & $WinTitle2 & " " & $ToolboxHandle) ;Present a message box to confirm title and check handle against the Window Info Program
    ControlFocus($WindowHandle, "", "[CLASS:gdkWindowChild; INSTANCE:2]") ;Focus on the main GIMP window
    ControlClick($WindowHandle, "", "[CLASS:gdkWindowChild; INSTANCE:17]", "main", 1) ;Click File
    ControlClick($WindowHandle, "", "[CLASS:gdkWindowChild; INSTANCE:19]", "main", 1) ;Click Open as Layer...
EndFunc   ;==>fractal

[mcglk]

First off, I don't think a Windows-only solution is sound. Secondly, if this is "user friendly" but Visual Basic isn't . . . wow.

So far, while I work with Python a lot, and clearly don't mind the indentation-structure style of it, I'm resigned to using JavaScript/ECMAScript due to its popularity, or Lua due to its easy embedding. Whatever will work. I'd rather it not have to support an additional REST responder just to provide scripting, as that would slow things down considerably, and in the end be a waste of resources on extra, unnecessary steps.

And for those who still wonder what people use scripting for, I use it for

• Creating barcodes directly in a document;
• Autoformatting and preprocessing of imported documents;
• Repetitive placement of elements;
• and other things as a project requires to save myself time and effort.

 

[Friksel]

19 minutes ago, mcglk said:

First off, I don't think a Windows-only solution is sound. Secondly, if this is "user friendly" but Visual Basic isn't . . . wow.

So far, while I work with Python a lot, and clearly don't mind the indentation-structure style of it, I'm resigned to using JavaScript/ECMAScript due to its popularity, or Lua due to its easy embedding. Whatever will work. I'd rather it not have to support an additional REST responder just to provide scripting, as that would slow things down considerably, and in the end be a waste of resources on extra, unnecessary steps.

And for those who still wonder what people use scripting for, I use it for

• Creating barcodes directly in a document;
• Autoformatting and preprocessing of imported documents;
• Repetitive placement of elements;
• and other things as a project requires to save myself time and effort.

 

Sorry, I didn't read this whole thread, but I'd like the idea of having scripting in Affinity and would use it for sure to solve some repitive tasks.

I would definitely go for Javascript. It's the fastest growing language a lot of people already are familiar with. Not only for websites, but also for use with NodeJs and even Windows programs itself. All editors can work with it, it's easy to learn, not too strict, there an enourmous amount of information about it online, we could use parts of the scripts directly in web applications if needed (and visa versa) and it's super multiplatform. There's also a lot of support for IDE's and text-editors for Javascript and there's active development on the language which is growing a lot last years.

Also people coming from Adobe and did scripting in Photoshop or for example After Effects are used to the Javascript inside Adobe, so they don't need to switch a language either. Not the best reason maybe, but still a plus.

If I would be Serif I wouldn't look any further and use Javascript. Also there are a lot of libraries they could probably easily implement in the software to have Ecmascript (javascript's 'base') working.

My preference would also be to be able to at least import a javascript script directly from file or even better: live reload (like a watcher), so we could create the javascript script with an external editor like VS Code and Affinity would update/reload the script automatically when saving the file in VS Code. That way we could use all features from the IDE of our own preference and Serif doesn't need to build a full javascript-editor to do that. My guess is that scripting would be done by more advanced users anyway and I don't believe they would mind it if there would be no editor onboard in Affinity products and could easily find and use an external editor.

By the risk of repeating what everybody here already said or discussed (and I didn't read)...

My 2 cts 

[angelhdz12]

Yup, definitely it should be Javascript and Typescript (for the ones who love static typing).

Typescript is basically Javascript, with static typing added.

Typescript is the best choice, because then we can know at authoring time, the types of the variables, properties, function returns, etc.

For example:
 

import { Shape, Layer} from "affinity"; 
import * as affinity from "affinity"

var rect:Shape = affinity.document.current.selectedItem();
var rect2:Shape = affinity.document.duplicate(rect);

for(var layer:Layer in affinity.document.layers) {
	affinity.document.select( layer );
}

I have experience with JSFL, an Adobe Flash (now Animate) Authoring environment Javascript API. You can run the actions inside the program, or load an *.jsfl file.
 

Edited June 29, 2019 by angelhdz12
Wrong syntax

[affi.usr]

On 6/28/2019 at 10:12 PM, mcglk said:

First off, I don't think a Windows-only solution is sound. Secondly, if this is "user friendly" but Visual Basic isn't . . . wow.

To be more precise. It is example how can you scripted Affinity Publisher today. It is not easy and comfortable solution. First you have to use this aproach to create more user friendly library. AutoIt I put here as temporary solution before full scripting will be implemented.

Personaly I prefer Python for short and robust code. I dislike JS as sometimes not clear for me.

[Pipeliner]

I only work with Python for automations. It can be slow sometimes but is easy to laern for beginners. Hope there will be the possibility to script with Python someday

[Undecided]

Add a stable API and those users with the expertise (and a burning desire to so so!) can develop new bindings beyond the obvious candidates for interpreted languages (Javascript or Typescript; Python). Personally I'd like to see something for compiled languages too (C++, Rust) but my skills aren't up creating a binding.

Although I've echoed some preferences myself, I still don't think saying "It must be language x or language y" is the way. Better to set things up from the outset so that other bindings are possible later on.

Speed of execution isn't so much of a thing from where I sit -- much likelier to build a complex single page table setup than a 1500-page behemoth these days! For my uses, speed of development wins over execution speed nearly all the time. That's why I'd love to see Python. But I could live with Javascript/Typescript with only limited grumbles

[rcheetah]

I think scripting support would be a wonderful feature. I would love a good documented API, maybe even a well done scripting environment (persona?) with an included library/documentation.

As of languages I would prefer something fast to write and easy to read like python, maybe even something eloquent like ruby. Javascript has a hideous code structure (things like }); are completely normal), though there are also many pros for JS. 

But maybe think about making scripting more accessible for the average user. There definitely are ways of doing this, if one is willing to go there. Drag and dropable scripting may be possible, or even node-based programming like NodeBox. 

Well, this should of course not replace normal scripting, but extend it and let more users be able to use the capabilities of scripting. 

[garrettm30]

On 7/6/2019 at 8:55 AM, rcheetah said:

Javascript has a hideous code structure (things like }); are completely normal)

Just a side note, but that example is typical of jQuery (which I have never cared for myself for that very reason), but you usually don't have to use such awkward syntax in pure JavaScript.

If I had a vote, I would pick JavaScript over Python. I've used both, but I am more familiar with JavaScript, and I happen to like braces and semicolons as compared to indentation only.

But I don't have a vote. Whatever solution is eventually delivered, I will be tempted to learn how to make use of it, and then I'll be playing with power.

[Samwise]

I too, +1 for scripting - javascript preferred.

[thomaso]

I'm curious to know if a script interface could enable the often-desired left-to-right writing function LTF.
Since I'm not a scripter, it sounds simple in my imagination "just" to flip every text frame horizontally + additionally apply the same to each single glyph, too.
Possible it's more GPU demanding than a proper LTF programming but could it work at all as a permanently running background task to flip characters while typing?

[Wosven]

11 minutes ago, thomaso said:

I'm curious to know if a script interface could enable the often-desired left-to-right writing function LTF.

Usually scripting is a different way to use the fonctions we have in a program, those we usually access clicking on button or with shortcuts, using the data those functions/button access.

Scripting permit to add calculus, work on text, dupplicate, move, etc. depending on conditions and values, and send back to the app those datas modified. But it won't really be able to add functions that doesn't exist to the app like RTL, (your example is only a visual effect, but all styles options should apply to those texts and respect the language proprieties).

RTL would be more a plugin or module able to modify the way the apps work internaly, constantly (each time the text is modifiedadjusting lines, etc.).

[thomaso]

1 hour ago, Wosven said:

constantly (each time

Thank you, Wosven for clarifying.

I guess my fault was to expect from a script to wait hidden in the background, watching the foreground events permanently and start acting by itself if specific events occur.

[Wosven]

12 minutes ago, thomaso said:

watching the foreground events permanently

Some can do this, but I don't think we'll get this ability from the start, and managing RTL with scripts seems a little bit too much: a lot of parameters and calculations to be done backward… After APub already finished its own calculations.

APub isn't really stable for now when you test 250 pages with complex master pages. Perhaps it'll be "easier", later, for the dev to add a second mode that do what must be done once and for all, with a setting for RTL.

And for security and stability, scripts have usually limited actions.

[affi.usr]

6 hours ago, thomaso said:

I'm curious to know if a script interface could enable the often-desired left-to-right writing function LTF.

Why not?

https://stackoverflow.com/questions/20306726/right-to-left-text-in-tkinter#43534569

from tkinter import *
from tkinter.constants import *
root = Tk()
text = Text(root,,font=('Tahoma',8))#I need RTL and Right justified text!

text.tag_configure('tag-right', justify='right')
text.insert('end', 'text ' * 10, 'tag-right')
text.grid()

scrl = Scrollbar(root, command=text.yview)
text.config(yscrollcommand=scrl.set)
scrl.grid(row=0, column=1, sticky='ns')
root.mainloop()

For now on your position I will be write script to reverse text with simple dialog where put text to format. Next when you click proceed you get text in clipboard and then paste them where you want with Ctr+V. For better automation and integration you can add shourtcut to your script and run then. Maybe is not perfect, but it's nothing complicated. You can use AutoIt to handle it or any scripting language which you prefer if only can create GUI.

AutoIt:

ConsoleWrite(_Revert_text("Reverse this string") & @LF)

Func _Revert_text($text)
    Local $aSS = StringSplit($text, ""), $sTmp
    For $i = $aSS[0] To 1 Step -1
        $sTmp &= $aSS[$i]
    Next
    Return $sTmp
EndFunc   ;==>_Revert_text

https://www.autoitscript.com/autoit3/docs/functions/InputBox.htm

https://www.autoitscript.com/wiki/InputBox

https://www.autoitscript.com/autoit3/docs/functions/ClipPut.htm

[MikeW]

Or one can just use an application that handles RTL, LTR and vertical text.

Might be a novel idea...

[Raphael Santos]

One more vote for python as the future scripting language for the affinity suite.

Not only is a very easy language to learn, it is very easy to teach.

We have struggled for years trying to teach  lab members to code, with frustrating results.

We have changed to python with very positive results.

Please consider python!!!

All the best,

Raphael

[ES-LAT]

Call me when you have full AppleScript support on a mac.

[Graeme W]

8 hours ago, ES-LAT said:

Call me when you have full AppleScript support on a mac.

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. 

[fde101]

On 8/20/2019 at 4:12 AM, Graeme W said:

If we get scripting then it won't be Applescript.

In this case it simply won't be possible for some people to meet their requirements.

 

On 8/20/2019 at 4:12 AM, Graeme W said:

Pretty sure Apple EOL'd it years ago

I've never seen ANY evidence supporting this common theory.

 

On 8/20/2019 at 4:12 AM, Graeme W said:

it's not cross platform

No scripting solution that can integrate multiple applications across an environment can be at this point due to security restrictions within the OS.

 

On 8/20/2019 at 4:12 AM, Graeme W said:

would mean the devs having to spend their time on multiple scripting interfaces

To fully meet the requirements of production workflows on both platforms, this will almost certainly be necessary.

 

On 8/20/2019 at 4:12 AM, Graeme W said:

that is a lot of work to do

Yes, it is.

 

On 8/20/2019 at 4:12 AM, Graeme W said:

choosing a language that would suit every platform is a must

Unfortunately not possible to do in isolation.

 

As I explained previously in the thread, there are two major use cases here with different and currently conflicting requirements:

• The ability to script within the application.  This can be done with a cross-platform scripting language which could be selected by the Affinity team and integrated into the product; I proposed Lua due to the fact that it is engineered for this purpose and is likely to have the fewest security hazards and be the easiest code base for the Serif team to maintain - others seem to prefer ECMAScript (JavaScript) which has interesting semantics in a few places (but the syntax stinks) while others clearly prefer that snake thing for some incomprehensible reason.  Using a common language across platforms for this has the benefit of allowing scripts to be written once and shared by users on multiple platforms.
• The ability to combine multiple applications.  This cannot be done with a language integrated into the product and must use a solution provided by the host operating system.  In this case, to support the needs of users integrating applications within their workflows, there is no choice.  For the Mac, it must be OSA (AppleScript); for Windoze, it must be WSA (VBscript I think?)

 

Note that much of the work required to provide this support, if carefully designed, can be done in such a way that all of the requirements could use a common base within the application code, minimizing the amount of effort to support multiple scripting languages (and a plugin interface).

If a system is set up internally which exposes a "document model" that is common to plugins and to the various scripting languages, then the general scripting support could be implemented internally once, and the various languages and the plugin interface could hook into that common model.  In this way, most of the "application" side of the scripting interface could be coded and maintained separately from the specifics of the individual scripting languages (OSA, WSA, Lua/Perl/Snake/CrypticThingUsedOnTheWeb/etc.) and from the native plugin interface.

Then people who wanted to use the internal scripting language could do so, those building workflows across applications could use OSA/Applescript on the Mac or WSA on Windoze, and native plugin writers could hook off of the same document model.  As the applications expand and add new capabilities, Serif would only need to update the document model once and plugins and the scripting languages would all fall in line.