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

Recommended Posts

Scripting? - Well, as far as it isn't stepmotherly treated like macros here then and would further also be usable cross-application wise for/on all supported platforms. I guess they probably would reuse something like Javascript/Typescript here and thus orient themselves on already existing things also used by other field players, or what's lately widely used and easier to adopt here. - However, most interpreters used in app scripting solutions aren't that performant in terms of fast execution speeds, so it will be interesting to see how things will then work and perform here.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

On 3/18/2019 at 2:33 PM, v_kyr said:

Scripting? - Well, as far as it isn't stepmotherly treated like macros here then and would further also be usable cross-application wise for/on all supported platforms. I guess they probably would reuse something like Javascript/Typescript here and thus orient themselves on already existing things also used by other field players, or what's lately widely used and easier to adopt here. - However, most interpreters used in app scripting solutions aren't that performant in terms of fast execution speeds, so it will be interesting to see how things will then work and perform here.

Considering Typescript is the language to develop VSCode extensions... yeah, most probably they go the Javascript/Typescript rute.

Link to comment
Share on other sites

On 3/22/2019 at 2:45 AM, angelhdz12 said:

yeah, most probably they go the Javascript/Typescript rute.

I'd vote for that. ( if I could vote :D )

AD, AP and APub. V1.10.6 and V2.4 Windows 10 and Windows 11. 
Ryzen 9 3900X, 32 GB RAM,  RTX 3060 12GB, Wacom Intuos XL, Wacom L. Eizo ColorEdge CS 2420 monitor. Windows 10 Pro.
(Laptop) HP Omen 16-b1010ns 12700H, 32GB DDR5, nVidia RTX 3060 6GB + Huion Kamvas 22 pen display, Windows 11 Pro.

 

 

Link to comment
Share on other sites

  • 4 weeks later...
  • 3 weeks later...
1 hour ago, Michail said:

Isn't the integration of Regex (ECMAScript with Perl extensions) an indication of where the journey might lead?!

This is what I thought as soon as the REGEX engine in Publisher has been released.

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

I'm still hoping for Python instead of JavaScript. That way it's easier to have it talk to other applications to get and sync data across.

Having JavaScript talk to an application only really works if there's a RESTful API or some other form of URL scheme, which pretty much no one does for internal use.

With Python we could talk to pretty much anything to get text into a catalog while it's still being worked on. Also the ML libraries available for Python could really help with doing custom image pickers for large catalogs.

Link to comment
Share on other sites

Python, please!

Done my share of scripting in JScript (for Softimage back then), and lately Python (Cinema 4D, Rhino Grasshopper). It's readability and clutter-free syntax (among other things) make it much more convenient. It's also the de facto standard in practically all DCC applications.

Forget about Apple Script... we need to think outside of our box! (Windows user here)

Thanks!

Link to comment
Share on other sites

  • 3 weeks later...
15 hours ago, ES-LAT said:

I've been AppleScripting inDesign since it was in beta and Quark before that. If this doesn't have a full and robust implementation of AppleScript I can't use it.

Why don't you think outside the box? :13_upside_down:

Link to comment
Share on other sites

 

On 5/16/2019 at 3:26 AM, Tupaia said:

Forget about Apple Script... we need to think outside of our box!

Both platforms support scripting interfaces that an application can implement to support multiple scripting languages.  Rather than focus on AppleScript vs. ECMAscript vs. that snake thing, if the programs interfaced with the standard OS scripting interfaces they would automatically support multiple scripting languages which could be used to tie multiple applications together effectively.

On the Mac, that would be the Open Scripting Architecture (OSA) and includes at least AppleScript and JavaScript as scripting languages.

On Windoze, the equivalent appears to be Windows Script Host (WSH) and includes at least VBScript and JScript as scripting languages, with others available as 3rd-party plugins.

 

The other piece of the puzzle is to support a scripting language that can be used within the app, with the same script working equivalently on both platforms.  My vote for that is Lua because it is engineered for that purpose (most of the other suggestions here are for languages which are frequently hammered into that role but are not designed for it - very few actually are).  Whether it winds up being Lua or some other language, there is benefit in this, but it does not replace the value of supporting the standard OS scripting language(s) to provide the ability to write scripts that tie multiple applications together, which an embedded language within the application will have a much more difficult time trying to accomplish.

Link to comment
Share on other sites

9 hours ago, fde101 said:

most of the other suggestions here are for languages which are frequently hammered into that role but are not designed for it

This is the most frustrating part of this discussion for me. The established languages for scripting InDesign and Quark are javascript and Applescript yet people are talking python, perl, C# or any other language they can think of.

For all those suggesting python, how many of you are currently scripting InDesign with it? How many of you are interacting between apps like Filemaker and InDesign with python? Show me some working code and convince me.

Affinity need to take users away from Adobe and making well established users learn a new language isn't going to help. We use over one hundred scripts here in a production environment. The longest Applescript is now over 1200 lines long. Modifying these scripts slightly wouldn't be an issue but rewriting the entire process in a new language just wouldn't be worth it. This is why I think it's crucial to adopt a similar object model to InDesign.

It's great to think outside the box and dream of a new way to script, but there are millions who are already doing it successfully with javascript and Applescript and I'd humbly suggest they're the ones with the best idea of the way forward rather than people who aren't currently doing it. The current 'professionals' are the people Affinity have to win over, unless their target market is going to be solely consumers and backyarders.

Link to comment
Share on other sites

11 hours ago, kimtorch said:

InDesign and Quark

Affinity products are not Adobe or Quark products.  There is no reason they need to make the same suboptimal choices their competitors are making.

 

11 hours ago, kimtorch said:

How many of you are interacting between apps like Filemaker and InDesign with python?

I'm not but note that at least on the Mac this should technically be possible because there are ways to hook Python, Perl and other languages into the underlying OSA framework - even if nothing else they could use the standard command line osascript tool.

 

11 hours ago, kimtorch said:

The longest Applescript is now over 1200 lines long.

That is indeed a LONG AppleScript, though I've written solutions for various (unrelated) things in Perl which are many times that size.  I think by the time an AppleScript got to be that long, I would be thinking about rewriting it as a native application, particularly if it is performance-critical or gets frequent use.

 

11 hours ago, kimtorch said:

Modifying these scripts slightly wouldn't be an issue but rewriting the entire process in a new language just wouldn't be worth it. This is why I think it's crucial to adopt a similar object model to InDesign.

Even if the Affinity team steps up their game and makes the programs fully scriptable via AppleScript, there is no guarantee that the specific data model would be even remotely similar to the one used by InDesign.  Even with the same language being used the scripts might need more than minor changes to work with a different application (the object model should reflect on the way that the application itself is organized and that might not match up).  There is similarly no guarantee that Adobe won't change their scripting API somewhere down the line and you may need to rewrite your scripts anyway.  Yours is somewhat of a corner case (granted an impressive one) rather than a common situation.
 

11 hours ago, kimtorch said:

It's great to think outside the box and dream of a new way to script,

That is not what is happening here.  There have been numerous suggestions but they are all for well-established scripting languages, no one here is re-inventing the wheel.  I do agree that AppleScript should be supported on the Mac, as I find it rather irritating when Mac apps don't support it (it should almost be required to be considered a "good citizen" on the Mac environment).  JavaScript is another story, as is a kludge of a language to begin with and not a good choice for general application scripting.  The only reason it is a "good choice" for web sites is that it is the only one that web browsers universally support.  Even people creating web apps are starting to create them in other languages then run translators to convert those languages to JavaScript before deploying them...  given that JavaScript was originally designed for use on web sites, that is a fairly good hint that it's not even a good language for what it was designed for, much less for something as different as this.

Link to comment
Share on other sites

3 minutes ago, fde101 said:

Affinity products are not Adobe or Quark products.  There is no reason they need to make the same suboptimal choices their competitors are making.

It's not about making sub-optimal choices, it's about competing with the duopoly market leaders. It's no point having a 'unique' product that no-one wants to move to.

 

I'm not but note that at least on the Mac this should technically be possible because there are ways to hook Python, Perl and other languages into the underlying OSA framework - even if nothing else they could use the standard command line osascript tool.

This is what is frustrating to me. People espouse their personal favourites but no-one has yet demonstrated it in action (and I've already asked a couple of times in this discussion). Saying it's technically possible and making it both user friendly and efficient are entirely different things. Do you really think the average designer who fools around with a few scripts wants to be digging into CLI tools and 'underlying frameworks'?  Both javascript and AS are relatively accessible for non programmers. At the moment, any discussion beyond Applescript and Javascript are mythical because no-one's actually doing it.

 

Even if the Affinity team steps up their game and makes the programs fully scriptable via AppleScript, there is no guarantee that the specific data model would be even remotely similar to the one used by InDesign

Absolutely, but it would be naive to be building a competitor, which uses almost identical functionalities and building blocks, without considering the possibility of a similar DOM. I certainly hope this is not the first time they are considering the scripting implementation because if it is I'll likely be retired before we see it.

 

That is not what is happening here.  There have been numerous suggestions but they are all for well-established scripting languages, no one here is re-inventing the wheel.  I do agree that AppleScript should be supported on the Mac, as I find it rather irritating when Mac apps don't support it (it should almost be required to be considered a "good citizen" on the Mac environment). 

It is actually. People are dreaming of ways to port their favourite language to work. Bridges, conduits, patches, extensions - they are classic examples of 'hammering it to fit' as someone mentioned earlier. I think many underestimate the inter-application operability that comes with AS. IF Affinity simply want automation of their own apps - without inter-app capability - they would be far better off just building a macro engine with a simple language. As they would have absolute control it would be quicker to implement and very complete. 

I absolutely agree with Applescript being part of a 'good citizen' Mac app.

 

JavaScript is another story, as is a kludge of a language to begin with and not a good choice for general application scripting.  The only reason it is a "good choice" for web sites is that it is the only one that web browsers universally support.  Even people creating web apps are starting to create them in other languages then run translators to convert those languages to JavaScript before deploying them...  given that JavaScript was originally designed for use on web sites, that is a fairly good hint that it's not even a good language for what it was designed for, much less for something as different as this.

This is exactly the benefit of javascript. Multi platform with a large existing user base where it's used for related workflows. With the proliferation of web/digital integration, being able to use the same language for both - regardless of its syntactical quirks or omissions - would be a huge advantage. We have both web designers and Indesign operators sitting within arm's length of each other. Some do both.

Link to comment
Share on other sites

This may be a bit of a tangent, but I am wondering if some sort of scripting would be necessary for third-party plugin support.

A very small number of us on this forum have mentioned that we would love support for Antidote, which is a spelling, grammar, typography, and style checker for French and English. For me it has become invaluable in helping us catch errors in our material. Antidote has integrations into apps such as InDesign, MS Office, Apple Pages, and other things (browsers, email, etc.), so that one can run the corrector right in, for example, InDesign, and corrections are made right in the document.

The onus for creating Affinity integration is mostly on Druide, the maker of Antidote, and I intend to request it of them once Publisher becomes public. However, it could only work if Serif provides whatever hooks are necessary. Do you think it would take something such as this scripting for it to be possible?

Link to comment
Share on other sites

3 minutes ago, garrettm30 said:

...However, it could only work if Serif provides whatever hooks are necessary.

That is true. It takes a published API/DOM for a plug-in maker to hook into the application in order for a plug-in to work in a specific application. Now, it may work in conjunction with scripting as regards what a particular plug-in does. Serif has not done so as of yet.

4 minutes ago, garrettm30 said:

...Do you think it would take something such as this scripting for it to be possible?

No. Scripting also takes access to a published DOM (Document Object Model), but I think integration with something like Antidote is far outside any such scripting capabilities.

Link to comment
Share on other sites

1 hour ago, MikeW said:

That is true. It takes a published API/DOM for a plug-in maker to hook into the application in order for a plug-in to work in a specific application. Now, it may work in conjunction with scripting as regards what a particular plug-in does. Serif has not done so as of yet.

No. Scripting also takes access to a published DOM (Document Object Model), but I think integration with something like Antidote is far outside any such scripting capabilities.

Depending on how it is done, a common DOM could be used for both plugins and scripts - in theory, within-app scripting itself could be implemented as a plugin that exposes the DOM to a scripting language.  I wouldn't count on being able to implement proper OS-level scripting support (AppleScript, etc.) as a plugin, but it should still be able to leverage a common DOM.

Link to comment
Share on other sites

I think Antidote's level of interaction is relatively simple. It simply needs to grab some text, whether a selection or the entire document, and send it to the external Antidote app, and then the external app just sends back individual edits as necessary. Perhaps one additional complication is that normally, when text is selected within Antidote, the same text is selected in the original app.

How this is invoked varies by program. Some add buttons to a toolbar, and most of them support text services activated from the contextual (right-click) menu, and finally there is a system-level menubar item. Several different options of integration are available, depending on the app: https://www.antidote.info/en/antidote-10/documentation/user-guide/using-with-your-other-software/mac

Link to comment
Share on other sites

42 minutes ago, garrettm30 said:

most of them support text services activated from the contextual (right-click) menu

Really, this is the best option.  Services are a standard OS feature on the Mac that would allow a bunch of things to work, not just this one product.  I would push for that before trying to get a plugin specifically for Antidote (not that this negates other reasons to want plugin support).

Link to comment
Share on other sites

I know that copy and paste works to some degree. Formatting gets destroyed in the round-trip, but at least it works so I can identify problems and fix manually, but it is is not ideal.

I appreciate the responses. I only meant to ask the question in this thread only insofar as I thought it might pertain to the discussion of scripting, but I think I have moved beyond that at this point, so I will yield back to the original discussion. For further discussion of Antidote, we can defer to one of a few threads where it has been requested, such as this one, where a Druide representative has posted :

 

 

Link to comment
Share on other sites

Related to the overall fruitless scripting debate here, it doesn't matter what sort of language finally would be used, as far as the chosen one is powerful and fast enough to express the kind of things and algorithms people have in mind to build for the tools. So more important is to map a rich reusable set of the internal functions into that language then and also offer integration hooks into the UI.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

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.