Search the Community

That all aside, it's quite safe to assume that once the already announced scripting will be implemented, moving and arranging any canvas object via user defined automation will be possible. It won't be necessary to populate the already kilometers long application menus with even more commands, adding bloat to the app UI. In other words, I'd rather expect – and wish – scripting to be implemented first.

Scripting would be very welcome. Scripting Summa OPOS-marks to a design to print and cut without Adobe or Corel software please?

Both Tim and Jon have been very responsive and I've passed them some additional information offline. I believe they understand the functionality and importance of tagged text in relation to scripting. Whether this results in its adoption is unclear but at least they have a better idea of its value.

The advantages of JavaScript far outweigh any advantages of Python, IMNSHO, for anything to do with creativity and user empowerment extensions of an engine/core written in C/C++. It's easy to think of JavaScript as a "lite" and dynamic C with objects/prototypes as an added means of wrapping, and dot notation for access, and go from there. Further, any programmer able to make something significant with Python will be able to do the same thing in JavaScript, or Lua, Wren, or MaxScript or any other scripting language, as scripting languages are no longer the barriers to production. With the possible exception of Apple Script, which is a wholly different beast able to turn sane men mad. Similarly, any skilled vector artist can produce with Illustrator, CorelDraw, Freehand, Designer etc. They might not like the workflow as much in some of them, but minus the need for a Blend tool, they can do their vector works in any of these. However, the processes of making a binding between an evolving program (and Affinity products are definitely evolving) and a scripting language needs (for best rates of production and freedoms of evolvement) a stable, specific scripting language choice for optimal flexibility so the tail doesn't wag the dog. Any attempt to be a truly agnostic creative engine for all scripting languages will heavily wag the dog and quickly begin curtailing and/or slowing the evolvement of the underlying software, despite the fact that scripting empowerment of a user base rarely leads to significant general buying of the software. The provision of plugin development in native languages, however, is a whole other thing, and also should not be at all curtailed or limited by scripting language choice, and especially not by a choice to try to be generically and generally extensible by all/any scripting languages. Plugins are a long game, though, and might be over for most creative software, now that we have "AI" that's soon going to be able to control other software.

@Jon W@Tim France@kimtorch Guys, this is it. This is probably the most important event in this thread, next to the actual feature announcement. I understand Kim's irritation. Let's just get over this and work towards a good scripting system that recognizes client's needs. I come from the graphic design side. I barely dealt with in-line text formatting. The 400 pages catalog took 24-27 minutes when rendered to viewport in InDesign CS6. This process required saving every 15 pages so InDesign would clear an internal memory buffer, otherwise it could crash randomly. I couldn't get it to work headlessly or by generating the IDML, and there was never time to refactor. To give you a scope of the problem: I had no idea about the text formatting tags. No one taught me that. I didn't find it in the documentation. I didn't know it existed. I used InDesign's built in formatting tools to set styles (line numbers, paragraphs, etc). I can write an RPA that syncs multi-user input from Photoshop and Illustrator, merge them into an individual asset, and push it to a desired position in an InDesign doc. Or do automatic asset management if you need to develop POS for 30 store locations, each with different dimensional requirements. I could stack hundreds of regexes to process stuff without conflicts. But I didn't know about the text tags up till now. (thanks btw :D). I'd suggest you guys figure out how to get meaningful feedback that would let you write a feature spec and gather necessary documentation reference. This thread is peanut gallery, and we need an actual need assessment, and features based on the results.

If you know the history of scripting in Photoshop, it initially seems to have been made purely for internal purposes, for quality review, and then a few motivate customers (iirc a newspaper chair, or maybe even Sports Illustrated) championed it even when it was very very not-customer-ready, because they needed a way to in the case of SI) pull together thousands of shots of the same Sunday football match and have it to the press Monday morning. There are still things broken there, but many people get value. I'd think scripting of some sort would open a lot of markets, not just the usual print folks but markets for all kinds of online media that typically are very speed-driven, things like "take this directory of pictures and put the logo and a bunch of affiliated text on all of them, send to PDFs and be ready to send to the printer because they're wedding-album takeaways" etc. Bulk job, simple in concept but lots of clicking and dragging without a script.

On Mac, it should be possible to access macros in the Library panel via UI scripting, i.e. as a combination of System Events AppleScript that is clicking a UI element in the Affinity window, launched via keyboard shortcut either via Automator/Services, or a 3rd party macro utility like Keyboard Maestro. The Library panel would have to be open(ed), of course.

Hi guys, I think Affinity is the future of design software. The one thing keeping me from switching from Adobe to Affinity is the scripting/automation feature. I have a bunch of scripts running in Photoshop and Illustrator and can't think about switching to Affinity and doing things manually again. You probably got this request earlier, but I'm just signaling the importance of automation/scripting in design software I hope this feature will appear soon All the best from Poland, Sebastian from Keyshorts

What you want is scripting capabilities + an API for Affinity Photo. The Serif Team has posted this; In other words; the Capture One Developers can do it themselves once the scripting feature is available.

You can assign shortcuts for Find Next and Find Previous. But those work only after you have pressed Return or clicked the Find button to start the actual search. On Mac, it should be possible to "click" the buttons via UI scripting, i.e. by utilizing some accessibility features via AppleScript's System Events. That can be run as Automator or Shortcuts plugin or with e.g. Keyboard Maestro, each by using keyboard shortcuts. I've posted a bunch of similar UI scripting examples here in the forums already: https://forum.affinity.serif.com/index.php?/search/&q=system events&quick=1&author=loukash&search_and_or=and&sortby=relevancy

I think one of the problems here is how each of us interprets 'scripting' today. In the early days of InDesign, and when Quark ruled the DTP world, scripting was usually thought of in relation to automation; enabling a script to complete a series of mundane, repetitive tasks that enabled users to focus on more high-value work. In the years since, the concept of 'scripting' has morphed considerably. While we still create scripts to automate repetitive tasks, we now also create scripts to create new tools, workflow and functionality that extend our existing tools, enabling us to perform complex tasks that would have taken hours or days, in seconds and minutes. Going beyond simply creating new tools and functionality (Cinema 4D, Illustrator, etc), scripts can also be utilized to create entirely new generative works (Processing Blender, Rhino, etc). From here it's not a huge leap to see AI as the evolution of scripting. We use it today to perform tedious, repetitive tasks, (object selection, masking, etc) and to create new tools (for writing, style transfer, content-aware fill, etc) as well as to create entirely new works (Firefly, etc). Even the way we create 'scripts' is changing. While we still write scripts in various languages, we also now have tools such as Apple's Shortcuts which employ a Scratch 'block-like' interface, or tools such as Unity, Unreal, etc which also provide visual node-based/flow-control scripting tools. I think that while focusing on matching existing scripting support from other workflows is helpful in the short-term, it could quickly lead to a situation where user expectations have moved far beyond what was considered state-of-the-art just a few years ago, and risk leaving the Affinity suite feeling further dated, and increasingly irrelevant. In the wise words of a fellow Canadian “…skate to where the puck is going to be, not where it has been”.

I realize you're suggesting a second command so that's a neat idea. It would be really easy to do with a script once scripting is selected and then you could assign a keyboard shortcut to it if you liked. In the meantime, if you're good at the keyboard shortcuts, just type Cmd+C, Cmd+F, Cmd+V - I've done that so many times over the decades that it's like breathing. FWIW, the macOS standard for Find (which Serif, Adobe and Microsoft ignore) is to pre-fill the Find field with the current search text for macOS. If you search for "test" in TextEdit, "test" will be pre-filled in Notes, Pages, and Numbers, and in third party apps such as BBEdit and IA Writer. It's probably something that Serif should consider.

That would mean no scripting for me or anyone else!😜

Hello, 1.) In MS Word you can link Figure titles into the text and table of figures, so when you delete a figure all the other figure numbers update everywhere: the figure title, the figure number in the paragrah and the figure number in the figures table. In the same way, when you insert figures, the rest update teh numbering. How can I do this in Affinity Publisher? 2.)Also, on a related note, the book I'm creating will have docens of "examples in design" so the book layout will have an example per page, or spread. I manged to automate the heading of each example with a Numbering Style and adding the text "example". However, do to the nature of the book developement often I have to move spreads or pages to a different location so Example 25 becomes example 10, and example 10 becomes 11 (with the rest of the examples adding one number): please see file attached. 3). the other problem with this is the paragraph that references other example numbers, so when I move the pages I need to re read and find where the refereces to examples are wrong in the text to make them match the Numbered Items. Points 1, 2 and 3 are a kind of a compbination of the same problem. Any ideas on how to do the magic? PS: there is this post in the forum talking about how to automate with merging of documents, but I coun't find anything else related to my problem. I'll be happy creating a simple script, but I have no idea where to start. Josue test.afpub

I truly hope you're kidding. It DEFINITELY requires a filter for import, parsing complex text and trying to format with style runs belongs back in the 90s... The sort of text munging you're talking about would be primitive and horrible. Surely the folks at Affinity are familiar with Quark tags or Indesign tags? Scripting without proper tag support would be like a car without fuel. If you want Publisher to be seriously considered an alternative to InDesign (or Quark) it has to at least support the things publishers need. A short example of InDesign tags: <ASCII-MAC> <vsn:7.5><fset:InDesign-Roman><ctable:=<Black:COLOR:CMYK:Process:0,0,0,1><C\=100 M\=0 Y\=0 K\=0:COLOR:CMYK:Process:1,0,0,0>> <pstyle:><pta:Left><ct:Bold><cs:50.000000><cl:48.000000><cf:Helvetica Neue>Historic boat shed saved in Putney<ct:><cs:><cl:><cf:><pta:> It allows text to automatically format on import either manually or via script. Importantly this covers any inline formatting Eg. a single word in italic, a few words underlined etc. Tagging frames etc is also crucial so you can properly address the target of your function. As I've described before on here, InDesign has script labels which are simple metadata for frames - they can be set via script so you can do things like: (pseudo code) tell active document create frame with properties (100,100,0,0 label:"Putney123", color:"None", text:"this is some text") tell Putney123 set story 1 to Bold end end This means a page can have multiple frames but they can easily be targeted by label. I can't believe that more than five years after this thread was started we're answering questions about features (tags) which were raised in the very first post of the thread. My confidence in Affinity doing this properly is now basically zero as it appears they have no idea what is actually required.

@v_kyr Interesting. I know nothing about Python or Scripting. I have a reasonably good understanding of the Affinity Apps, and I am trying to learn some of the basics of Blender, so my plate is pretty full. I have had some fun and success using Procedural Textures, but Serif could really help make it easier and less painful for those of us who aren't mathematicians or programmers. Affinity's Help Manual is often technically accurate, but not always very "helpful", in my opinion. Despite my frustration, I enjoy the Affinity Suite, so overall, I'm happy using it.

For sure the whole could probably be better documented! - However, personally I don't use those PT + Voronoi filter things in APh at all, as I'm more used to do such things -if I need them- via Python scripting. Though there you also need to know what certain functions of the several Python modules & libs therefor do offer and what they finally do (also in a mathematics sense).

If Affinity would do scripting API with handling import/export/layers users would code that alone. Making scripting API is not only for AI but is for the community to do their own plugins. They should invest in that. It should be wise. To be fair I do not need any feature from version 2. I bought it only because I have hope that they will do scripting someday to do what you want. I`ve heard that small firms easily bend to market but in this case, it`s the opposite. They prefer not to have custom plugins.

The top request in this forum is scripting, which baffles me because Affinity already has a great macro and job processing system. With it users can automate almost anything inside of Affinity without having to write and maintain any code. The main problem it has though, is that it cannot save and load Batch Jobs. Batch Jobs can have many steps and settings, so setting the up every time they need to be run is tiresome. This is the equivalent of building a scripting system but not letting users save or load scripts. I think that Saving and Loading batch jobs is a low hanging fruit that would make Affinity Photo 10x more powerful with 1/1000 of the work of implementing scripting.

The link about scripting support makes it very clear that the demo is not how the Affinity suite will run scripts and plugins; that it is "all VERY early, like pre-pre-pre-alpha," there is not even any timescale for its release, & so on. So about the only thing newish that is revealed about it is that in its 'pre-alpha' state it can run Javascript code. Better than nothing I suppose but the demos don't reveal anything specific about what we will actually be able to do with scripting when it finally makes it into Affinity, or how long we will have to wait for that.

Do you have a link for that? I have not seen anything about it. What specifically have we not known about them working on for years? Scripting support was first mentioned at least 4 years ago when they mentioned that they had not at that time decided what scripting language it would be based on. I am not complaining about anything, just reiterating what they have said in the past about the reasons they do not discuss any specifics about their plans for the future.

Documentation and all the rest that goes with it is very important upon the release of the product. However, there is value in including this functionality early in the beta cycles of the product(s). Even if the scripting is not ready and missing a lot of functionality. It doesn't have to be part of major point releases until it's actually release worthy. Those of us who would love to experiment with it early would send an invaluable feedback to the devs, which in my opinion is as important as the release itself. And those who love living on the edge would start using it early in live projects and learn what works what what doesn't.

I am a V2 user and I have the same opinion as you. Better communication about their development plans would be useful. Why do we need this information? It's easy. Without such information, it is simply difficult for users to make decisions about: purchase migration to the next version building workflow based on their apps From time to time they reveal a veil of secrecy about pricing, updates. For example, they are known to be working on scripting. But it's not enough to make a decision. I don't think this will happen (public roadmap) for several reasons such as: Plans often change during the ongoing development Roadmap gives to much information to other companies. User complaints when the roadmap changes Despite all the inconvenience of a public roadmap, I believe they would benefit more if it were available. What exactly would they gain: They would gain more trust (priceless), By involving users, they could better manage the process of reporting features that users would like to see implemented Fewer dissatisfied customers. More conscious decisions and users, less reasons to complain.

@Tim France Many thanks for the progress report. > Naturally we've been exposing more of the apps' functionality to scripts I hope the ultimate aim is to expose all the app's functionality to scripting. Can you say anything about that? When you expose only part of the app's functionality you have to make a choice -- you'll always get it wrong.

When I'm done working with a photo I usually do a couple of exports: one at full size, for printing or sale; and one at a reduced pixel size and quality to post online. Each time, I have to adjust size and quality in the Export dialog. Does AP offer any way to 'automate' a repetitious series of tasks like these? Some sort of scripting?