YouTube videos:

https://www.youtube.com/playlist?list=PLuW3sE8aHqZa_9BBRIDKAUnLH65JZ-PRC

Blog:

https://coppieters.nz/?p=525

What is Tightener?

Tightener is 'automation glue'.

It is not functional in its own right - you use Tightener to make it easier to build software.

Tightener helps with many aspects of software development: activation and licensing, metrics, data exchange between disparate systems,...

It helps automating various applications by adding a standardized API to a range of apps.

This API is independent of the application being controlled, or the scripting language being used for controlling the apps.

The apps being controlled can be anything, including Adobe Creative Cloud® apps like InDesign® or Illustrator®.

The controlling scripts could be written in any language: JavaScript, Python, PHP, C++...

Example use cases:

• A scripter wanting to protect and monetize their scripts without having to deal with a complicated app store.

• A Node/JS or PHP-based web server needing to integrate with InDesign Server for renderings.

• Developing a Python script in a Jupyter Notebook in order to automate InDesign Server. Test the script against a local copy of InDesign, then changing a single line and immediately run the same script from the same IDE in a remote instance of InDesign Server.

• An InDesign user interactively constructing a Python script in a Jupyter Notebook.

• A Node/JS developer writing a single JavaScript to build a complex document using InDesign, Illustrator and Photoshop.

• A UXP developer building a UI and using Tightener to interact with an extended app DOM

Design principles

Tightener is all about 'separation of concerns'.

Tightener:

• does not dictate what scripting language you should use
• does not dictate what user interface framework (if any) you should use
• is not limited to a small set of apps
• is easy to integrate because it has no external dependencies
• does not dictate how you want to handle licensing
• does not dictate how to handle payments from your users

To embed basic Tightener into a native app, all you need is a standard C++ 11 compiler with the Standard C++ library. Basic Tightener is fully self-contained, but it does not provide the activation/licensing features.

There is an larger version of Tightener which also handles activation/licensing features. In order to handle the cryptography and communications needed to do this, it uses OpenSSL, zlib, and libCURL.

There are various DLL versions of Tightener, which can be linked into third party programs.

Tightener can easily be integrated into any environment that offers C or C++ bindings. This includes Adobe Creative Cloud applications, QuarkXPress,...

The target audience for this project is wide: on one extreme of the scale, I want to help creative people with limited developer experience write scripts for automating their apps, at the other extreme, I want to make it easy for seasoned developers to integrate a web server with InDesign Server.

Why Tightener

Tightener came about because I had a number of issues with Adobe's strategy for automating its Creative Cloud apps.

Remember the days when scripting Adobe apps didn’t require a CS degree? When people with a passion for printing, photography, or design could just jump in and start scripting?

Those days seem far gone with the advent of UXP and UXPScript.

That’s where Tightener comes in. I'm gradually winding back the clock, making scripting approachable again, especially for those who have the domain knowledge and the know-how but don’t feel compelled to get a degree in computer science as well.

Tightener is a toolbox for developers, easing everything from script writing to monetization, from inter-app communication to usage tracking.

For small developers and not-for-profit, Tightener is free.

It is all about empowering small developers, handling the nitty-gritty of activations and metrics, so the developer can focus on what they do best.

The goal is to make small developers successful.

ExtendScript: on life support

ExtendScript offers us a usable way to access the various document DOMs, but ExtendScript is dying.

The available tools are suffering from neglect and one by one, they become unusable.

Between a rock and a hard place

I fear we will soon be in a situation where 'the old' does not work any more, and 'the new' does not work well enough yet.

That’s called ‘being between a rock and a hard place’.

The goal is to provide us with what I think we need (DOM access), and reduce our exposure to breaking changes by Adobe.

This project should help limit the damage caused by breaking changes and give us a little bit more control over timely fixes.

Separation of concerns

There are a number of concerns that I keep in mind.

Independent of Programming Language

I want to separate the DOM from the scripting automation language used.

ExtendScript forces us to use a JavaScript variant to access an app’s DOM. If you want to use, say, Python, to automate an Adobe Creative Cloud app, you’re out of luck.

That does not need to be so.

DOM access and the scripting or programming language used are two separate concerns and they should also be separated into independent parts of the automation support infrastructure.

What language you use, what IDE you use, what debugger you use... should all be irrelevant to Tightener.

No External Dependencies

Basic Tightener has been built without external dependencies. All you need is a C++ 11 compiler and the standard C++ library.

The aim is to make integrating Tightener into any plug-in code easy, and not cause any 'dependency hell'.

InDesign plug-in developers know what I am talking about.

A major time sink I face when developing InDesign C++ plug-ins is a recurring struggle with external dependencies.

InDesign is written in C++ and has dependencies on a host of external code bodies: Boost, OpenSSL, zlib, icu…

Each time Adobe updates InDesign, my plug-ins need to be recompiled using the correct InDesign SDK for the new version of InDesign. That used to happen every two years, then every year, and now it has started happening multiple times per year.

And often, at the same time, InDesign's own dependencies change. For example, recently the InDesign team quietly switched from Boost 1.65 to Boost 1.72. The unfortunate consequence was that any plug-ins that rely on Boost also need to make that dependency change and that can force a trip through 'dependency hell'.

Updating a plugin involves not just compiling against an updated InDesign SDK but also discovering and updating all these additional dependencies to carefully match any dependency changes in InDesign. And that is a major time-sink.

Connectivity

Another recurring concern is connectivity. We often need to automate ‘across’ a network wire.

Basic Tightener has no network capability, on purpose.

Instead it offers the tools to easily add communication between multiple Tightener nodes on multiple computers.

The necessary network communication layer can be added by setting up two Tightener-enabled gateway nodes that know how to interact over the network.

These gateway nodes can be written in any language (e.g. Node/JS).