API Think Tank

[Lmpessoa]

I've been following the forums for a while now since I've decided to switch from the "A" suite and, of all the features requested by users, the most are support for a given file format. Also some users have been heavily requesting for an API they could use to automate stuff (or build stuff - some ideas also came to my mind while writing this) and I think these could be handled with a little bit more of effort in building an API. Since most programming languages are object-oriented I'm also thinking in such terms while I write, however I'm not being specific on language.

I believe two kinds of plugins could be allowed: SCRIPTS, which would only help in automating repetitive tasks (think about closing a document for printing) and mostly would only manipulate the document without any sort of argument, and PLUGINS, which would be developed on a chosen platform (I'm pretty sure the Affinity suite relies on .NET) and would enable usage of every feature the platform has to offer. This dual approach is adopted by apps such as ZWCAD and could be great for different uses but it is not a mandatory thing.

As for the API itself, the idea would be to enable means to programmatically:

• access a document (either by creating a new one or retrieving one currently open),
• layout the document (creating slices on AD or new pages on AP, for example),
• create, retrieve, modify and/or objects in the document (create shapes, change attributes like colour, add text, etc.),
• request users to select objects or a point on the document (to ask the user where action will take place).

Basically that is allowing anything on an app to be done programatically (yes, with the right script, one could simply automate a complete complex drawing, I'm not asking why would you). I'm thinking of basic object-oriented programming here:

// in some pseudo language
doc = new document
rect = new rectangle object
set brush in rect to X
add rect to doc
...

I'm also well aware the amount of effort and code required to implement this API so I'm not expecting this to be available tomorrow (or in the next version) but I think we'd have to start gathering ideas about this somewhere. Here are some examples of what I would expect that could be achieved with this API:

• import/export to X file format (PLUGIN): triggered by selecting a file in a recognised format, it would (1) read from a file and create a document and the objects in it using the API representing the contents of the file or (2) traverse a document (or a slice of it in AD) and write it to a file in the chosen format,
• QR code (PLUGIN): it would open a dialog for the user to enter the info on the QR code (format version, size, tint, text, etc.) and create a group of rectangle objects based on that info. After that, it is just a series or rectangles and does not depend on the plugin (of course this approach does not allow the QR code to be edited, or even its info to be viewed, but I'm sure some other approaches can be taken - like storing arbitrary metadata on objects and groupings and even restricting some of these to be undone),
• create a draft in PDF format (SCRIPT): this would just add the word "DRAFT" in the background of every page (in a publication - to the original or a copy of the document that exists only in memory), trigger the export to PDF function (it is already embedded on the app, so why not make it accessible) and then remove the "DRAFT" word from every page (since it is not meant to be part of the final document). This could also be done as a PLUGIN if one would like to specify the tag text and colour.

Perhaps the biggest concert of Serif in providing us an API is related to security/privacy of its users and that's a noble reason for not releasing an API yet. Of course PLUGINS could be more dangerous than SCRIPTS from this point of view since they have a broader access to the native API of the platform (from enumerating/reading/writing files arbitrarily, to spanning threads, to sending data over the internet) but I've never seen anyone complaining about those issues on Photoshop or any other app that enable the use of plugins. You choose to use plugins from a reliable source and Serif could even be a curator for one of those reliable sources, but nothing mandatory.

Another solution to this (and this would take a more considerable amount of time) would be Serif to create a full development platform with each and every API exposed (file access, document access, etc.) in order to minimise the existance of malicious plugins (and someone will always find a way to bypass it, trust me) and restrict programming languages to the one Serif itself choses (I'm not really fond of it but it seems the most claimed in the forums is Javascript). I could live with that with the right API.

I'm not in anyway affiliated with Serif and I don't know if they have already decided on any of the issues I raised and my intent here is not to discuss the exact implementation the API will take (thou it could certainly be fun) but to gather opinions on it, specially on whether the API should use an open platform or a more strict one to prevent malicious extensions, and to gather things people would be interested in doing with the API and are not sure I covered above. I would also like if this space were to be used by Serif to talk to us about how they view the issue of the API and how/when they are planning to handle it and to it discuss with us in order to create something really useful for everyone.

[Lmpessoa]

Just another example taken from the idea of @July-Nov of what could be accomplished with the proposed API: drawing using math properties like circles using tangents. Some kind of illustrations require precision and while one can do all the math to create it (think of the representation of the graph of a equation for a technical book, for example), one could provide an extension that solved this matter in a simpler, easier way.

[algo]

I also think that an API would be great.

Some Adobe applications can be automated by using a JSX (Java Script) file. I've used it to automatically convert images exported from various applications whenever they are saved into a certain folder to print and web formats (resolution, dpi, colour space, cropping, etc). The converted files have been saved and renamed according to the format to different locations. Such scripts are quite handy if you create a lot of CGIs and don't want to spend too much time on preparing the images for the media they are shown in.