Jump to content

Recommended Posts

On 12/27/2018 at 12:19 PM, fde101 said:

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.

I am not sure if we are not mixing up things together.

I thought that you meant using apple script as scripting language for Affinity products (it's not only about publisher). Meaning scripts that Affinity can run to control itself (and get low level control) like transforming text, populating frames with images, get data from excell table, connecting to web to grab something, drawing points and lines... basically anything. For this AppleScript would be a bad choice because its old (last version 2014) and does not have any ecosystem (dont forget the amount of libraries javascript or python already have for any possible usecase) and it's not open-source.

It seems that you talk about ability of Affinity programs to be programmable/automatable from outside with applescript or things like automator. This is very different thing. But this type of programmable user actions is on OS level and you can already do it.

If you put this in OSX  Script Editor

tell application "Affinity Publisher Beta"
	activate
	open "/Users/user/Documents/test.afpub"
end tell

It will work and you can script user actions in the software.

I guess adobe is exposing more controls to OS so more things can be automated this way (and they have it documented here https://www.adobe.com/content/dam/acom/en/devnet/photoshop/scripting/Photoshop-CS6-AppleScript-Ref.pdf ) so you might want to want for Affinity to think about this. Who knows maybe it is easy for them to expose more functionality this way. There is probably some work needed to be done so script editor get documentation like some other software (screenshot of Adobe Illustrator) currently it doesnt.

By the way Apple it seems is already moving away from Applescript to Javascript for OS level automation. In script editor you can switch to Javascript mode and do everything. They cal it JXA - javascript automaton. https://apple-dev.groups.io/g/jxa/wiki/JXA-Resources  

 

But overall i think people in this thread are mainly interested fairly low level scripting access to Affinity products.

Personally i never found much that much usecase for automation of GUI apps on OS level. On the other hand what i totally need for my work is to generate PDFs. Imagine for example you are making book of all pantone colors from excel table - this would be insane without automation (and yes you can generate those pdfs somewhere else but ability to still edit afterwards is priceless).

Screen Shot 2018-12-28 at 15.43.13.png

Share this post


Link to post
Share on other sites
1 hour ago, Florian Karsten said:

But this type of programmable user actions is on OS level and you can already do it.

There is a limited set of actions that virtually all Mac software will implement as scriptable, including the ones you showed for Publisher.

The underlying "open document" action is the same one that is used behind the scenes to ask the application to open a file that you double-click in the Finder for example, so that one just about needs to be there.  B|

Share this post


Link to post
Share on other sites
1 hour ago, fde101 said:

There is a limited set of actions that virtually all Mac software will implement as scriptable, including the ones you showed for Publisher.

The underlying "open document" action is the same one that is used behind the scenes to ask the application to open a file that you double-click in the Finder for example, so that one just about needs to be there.  B|

Yes, and other things don't work. For example, I wanted to get the current document file path to put into Quicksilver (a productivity app like Alfred), and I couldn't make it work. `get path of first document` results in an error. This should be a simple thing to do, but I ended up having to use a much more complicated workaround and it's not reliable.


AD+AP, Mac 10.9, kbd & mouse, casual user since 2014

Share this post


Link to post
Share on other sites

Being able to automate InDesign was one of the main reasons I gravitated to it for so long; I was able to write scripts that would generate barcodes on the fly, populate label sheets from a database with full control over placement, all sorts of things. That said, Adobe's AppleScript support has always been half-hearted, and now Apple seems to be putting AppleScript in the let-it-die department. It's extremely disappointing.

So while full AppleScript support would be nice, it might be considerably wiser if there were an independent scripting engine for Affinity Publisher (and Designer and Photo, to be honest). But it'd have to be able to take input from the Unix world (I routinely generate AppleScripts from Python or Perl and use `osascript` to run them, for example; I'd need a similar process for Affinity applications).

Share this post


Link to post
Share on other sites
On 9/12/2018 at 12:12 AM, kimtorch said:

I believe Python would turn existing ID users off

Not necessarily true.

A number of inDesign scripters asked for Python on inDesign scripting forum. See the post by no other than Peter Karel somewhere in this forum.

Share this post


Link to post
Share on other sites

The whole indentation-as-syntax thing Python has going on reminds me of FORTRAN 77 in which you would make a comment by putting the letter "C" in column 1, columns 2-5 were for labels, etc...

I know there are those who love it, but to go back to that now that we have moved on from punched cards feels programmer-hostile to me and kind of turned me off to that language.

Share this post


Link to post
Share on other sites

As long as one can feed scripts into a shell-level program à la `osascript`, I don't really care what language Serif chooses for the purpose. Sure, it'd be nice to have an API one could call, but then, that would put a hard limitation on what languages you could use. As far as I'm concerned, I don't need to write entire programs in whatever language Serif uses; I just need to be able to create objects and have control over all the attributes I'd normally use the UI for.

fde101: While I've gotten used to the indentation thing, it still bugs me a bit. I'm not sure Python reminds me of punchcards, though; indentation would have seemed wasteful, and made it much more difficult to shuffle the order of statements if you needed to. . . .

Share this post


Link to post
Share on other sites
9 hours ago, Seneca said:

Not necessarily true.

A number of inDesign scripters asked for Python on inDesign scripting forum. See the post by no other than Peter Karel somewhere in this forum.

I haven't had a lot to say here because - to be frank - we don't need Affinity Designer. I WANT to change to Designer, but we already run successfully with the Adobe products and can continue to do so. The point I'm trying to make is that Affinity need to persuade or entice existing ID scripters with a compelling reason to move. They're not going to do that by trashing everything they've invested in either Applescript or Javascript with ID.

The other issue that people keep ignoring is inter-application scripting. I don't just want to script Affinity Designer - I want to talk to Filemaker, Mail, Capture One, Acrobat and any number of other scriptable applications. Just targeting your own app would b very shortsighted and really misses the point of what can be achieved with lateral thinking.

Share this post


Link to post
Share on other sites
8 hours ago, fde101 said:

The whole indentation-as-syntax thing Python has going on reminds me of FORTRAN 77 in which you would make a comment by putting the letter "C" in column 1, columns 2-5 were for labels, etc...

I know there are those who love it, but to go back to that now that we have moved on from punched cards feels programmer-hostile to me and kind of turned me off to that language.

I really don't understand this comparison with Python and Fortran that I come across a lot. Python doesn't restrict where you indent to - the indentation (1 space, 4 spaces, 8 spaces, 1 tab whatever) just marks a block - if things line up they are in the same block. It's no more arbritary than having to use '{' and '}' in C/C++/JS or "begin"/"end" in other languages. Not really a lot like punch-cards (and yes I remember those and programming in Fortran et al.). I've found that beginners find it easier than having to remember to use '{' and '}' and the inconsistencies in C/C++ about where you use braces but YMMV on that. I work as a freelance developer and most C/C++ I see uses Allman (except in the Linux Kernel where it's K&R) and every virtually customer that I work at has coding guidelines for JS/C/C++/C# etc.that enforce a house style - I don't find any of these programmer-hostile, it's just another set of rules to follow (or break ;-) ).

Having said all that - I'd be quite happy for any generic scripting language to appear in the Affinity suite  - Javascript, Python or whatever;  there are advantages and disadvantages to all scripting languages.

Share this post


Link to post
Share on other sites
8 hours ago, kimtorch said:

I haven't had a lot to say here because - to be frank - we don't need Affinity Designer.

I'm sure you meant Publisher.

Clearly, not everybody needs Adobe either, judging by the number of people posting or participating in this forum. So your argument is rather moot.

 Whether it's Python, JavaScript, Lua or any other scripting language it will be chosen by the devs and we will get on with it.

IAC ( Inter-Application Communication) is certainly something that would be incredibly useful to have.

Share this post


Link to post
Share on other sites
16 hours ago, fde101 said:

The whole indentation-as-syntax thing Python has going on reminds me of FORTRAN 77 in which you would make a comment by putting the letter "C" in column 1, columns 2-5 were for labels, etc...

I know there are those who love it, but to go back to that now that we have moved on from punched cards feels programmer-hostile to me and kind of turned me off to that language.

I don't think they will provide a Java/Groovy API just for me. To bad. :D

Ruby is ja nice language, too.

Or do it in Brainfuck. ;)


Windows 10 Pro x64 (1809). Intel Core i5-4670K @ 3.40GHz, 16 GB memory, NVidia GTX 780
Affinity Publisher Beta 1.7.0.221

Share this post


Link to post
Share on other sites

vote for Python. Just great for string processing, regexes, path management and all other stuff that goes with image and text processing. 

Share this post


Link to post
Share on other sites
13 minutes ago, beige said:

vote for Python. Just great for string processing, regexes, path management and all other stuff that goes with image and text processing. 

So how do you handle these things now in your existing InDesign scripted workflow?

Share this post


Link to post
Share on other sites

Since InDesign came out (and for QuarkXPress before that, back to 1994), I used Perl to generate short AppleScript snippets that would then do the application control. That way, I had the best of both worlds: regexes and lots of libraries around, yet still could control the dang application.

I'm really missing my barcode-generator scripts lately.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×