Search the Community

Hi @kimtorch. We are doing our best to engage with our users and understand their requirements. Our primary focus is to expose existing application features to scripts/plugins; text support is just one part of this. We are software developers, not publishers, and although we often liaise with the Publisher team regarding text matters, they are not really scripting experts. So you might have to explain some things that may seem obvious to you. We are aware of InDesign text tags: as I understand it, they are primarily used to map to text styles on import. What we're trying to understand, and I hope you can explain, is how this relates to scripting. I would guess that perhaps you envisage a script which would run as a tagged text import filter, overriding the tag -> style mapping which would normally be set up manually in the app?

For the record, "Affinity" is the product. It's Serif who needs to spend time. And in fact they do spend time on Good Things™: Application scripting has been confirmed to be in active development, and that may likely also include some kind of plugin API.

They won't. If you are already using Apple Photos.app there are a bunch of tasks you can also automate with the help of macOS own automator/scripting etc. The Net should usually be full of examples of how to perform certain Photos.app tasks automated, like exchange & update image files between Photos and some third party app like APh etc. See also this related thread ...

Thanks for the work you are doing on this. I want to help you make a product that will be seen by others (and myself) as being very useful and I think one of the very best places that scripting should be designed for is time savings and batch processing. I have hundreds of articles that need to use the exact same template. I need to be able to swap out the template on every one of them, and then click a button to recreate PDFs for them all. Can scripting do this? It should. Failing this type of usefulness, scripting is of very little value to me. And I would say probably of very little value to others, as well. "Batch processing is it" when it comes to scripting. Please don't forget batch processing. Otherwise, affinity publisher cannot serve me in the end. Thank you.

If Affinity doesn't gain this feature by the time we get scripting, it would be easy to add a notes or revision history feature with scripting by saving data to user variables (custom fields). I have this on my to do list for when scripting is available. My to do list is getting rather long. 🙂

The year is 2024. I just searched Affinity forums - 6 years since the first scripting support request threads started to appear. It is hopeless, isn't it?

We have basically been told that Serif does hope to implement this at some point, but they are not content with the solutions they currently could use, so it may be some time before this appears as they want to develop something better for when it does come out. Unlikely to happen due to the proprietary/undocumented nature of these formats. Serif has been adverse to adding any 3D features to the Affinity apps and this has often been lumped in with those (correctly or not). There are multiple threads where people are begging for this; indications are that it will come eventually. This has also been requested multiple times; I don't remember Serif specifically commenting on how likely this is to happen, but given the plethora of 3rd-party tools which are inexpensively available (in some cases free) which can easily generate these and export them in a form that can be used within the Affinity apps, I would imagine it to have a relatively low priority compared to various other features which have been requested which would not be so easily done outside the apps. I vaguely remember seeing that even PSD text objects are not fully supported because they are not as well-understood (possibly proprietary/undocumented) as other types of layers? I would imagine that to be true of the effects also... Some PhotoShop plugins are supported. An SDK for native ones is already under development (see the "Scripting" thread pinned at the top of the forum, in which both a scripting API and a native SDK for compiled add-ons are being discussed together). INDD is proprietary and undocumented and its internal format is known to change between releases, so support for that is extremely unlikely. IDML is currently supported for import only. Note that this is also true of QuarkXPress: it can import IDML, not INDD, and likewise does not currently support exporting IDML. I can't imagine them implementing XLS support at this point. I could see XLSX but tables in general need a lot of work in Publisher and there are probably bigger fish to fry than XLSX import support (ex. a table in Publisher cannot currently span multiple pages). Limited imposition functionality is currently integrated into the Print dialog, but is curiously not available for "proper" professional PDF export (which has been pointed out and complained about many times in other threads). Extending existing imposition features to the Export dialog for PDF would be more than welcome and I too would love to see that happen. A few other options could likely be added within reason, but more complete imposition functionality is likely better in the domain of a dedicated application designed for the purpose. A preflight inspector for already-exported PDF files is likely best handled using a separate dedicated application. There are already pre-export preflight features available in Publisher, but they are not included in the other two applications, and I would not expect that to change in the near future as it was obviously a conscious decision on the part of Serif to limit them to that one application. Note however that Photo and Designer files can easily be opened in Publisher to perform any needed preflight work. Thank you very much for the answers and information.

Hi @Eric Designer 2023, welcome to the forums! In general it is best to limit a thread here to one feature, and to at least try to search the forums for existing threads making the same request before starting a new one. These things are specified in the guidelines for posting to this area of the forum. Many of the things you are asking for have already been discussed in the past and there are existing threads on these topics; a few highlights and comments: We have basically been told that Serif does hope to implement this at some point, but they are not content with the solutions they currently could use, so it may be some time before this appears as they want to develop something better for when it does come out. Unlikely to happen due to the proprietary/undocumented nature of these formats. Serif has been adverse to adding any 3D features to the Affinity apps and this has often been lumped in with those (correctly or not). There are multiple threads where people are begging for this; indications are that it will come eventually. This has also been requested multiple times; I don't remember Serif specifically commenting on how likely this is to happen, but given the plethora of 3rd-party tools which are inexpensively available (in some cases free) which can easily generate these and export them in a form that can be used within the Affinity apps, I would imagine it to have a relatively low priority compared to various other features which have been requested which would not be so easily done outside the apps. I vaguely remember seeing that even PSD text objects are not fully supported because they are not as well-understood (possibly proprietary/undocumented) as other types of layers? I would imagine that to be true of the effects also... Some PhotoShop plugins are supported. An SDK for native ones is already under development (see the "Scripting" thread pinned at the top of the forum, in which both a scripting API and a native SDK for compiled add-ons are being discussed together). INDD is proprietary and undocumented and its internal format is known to change between releases, so support for that is extremely unlikely. IDML is currently supported for import only. Note that this is also true of QuarkXPress: it can import IDML, not INDD, and likewise does not currently support exporting IDML. I can't imagine them implementing XLS support at this point. I could see XLSX but tables in general need a lot of work in Publisher and there are probably bigger fish to fry than XLSX import support (ex. a table in Publisher cannot currently span multiple pages). Limited imposition functionality is currently integrated into the Print dialog, but is curiously not available for "proper" professional PDF export (which has been pointed out and complained about many times in other threads). Extending existing imposition features to the Export dialog for PDF would be more than welcome and I too would love to see that happen. A few other options could likely be added within reason, but more complete imposition functionality is likely better in the domain of a dedicated application designed for the purpose. A preflight inspector for already-exported PDF files is likely best handled using a separate dedicated application. There are already pre-export preflight features available in Publisher, but they are not included in the other two applications, and I would not expect that to change in the near future as it was obviously a conscious decision on the part of Serif to limit them to that one application. Note however that Photo and Designer files can easily be opened in Publisher to perform any needed preflight work.

I'm surely not new to scripting in general, but I seriously can't figure out how to build the shortcut based on Paul's tutorial when using iPadOS 16. The commands just don't seem to exist there. (But perhaps it's just me and my admittedly irrational aversion towards the "Shortcuts" app in particular; also on Mac… ) In theory it obviously is, or was.

Hi, I was wondering if there is scripting or macro support in AD2? ? At the moment, I use AHK to achieve some form of automation, but it's not always reliable. So I am wondering if there is scripting available in AD2 and if not, why not?

v2 is a nice update. Unfortunately, palette docking on macs still hasn't been addressed. While the windows version allows two or more columns of palettes to be docked side by side, in macOS only one column is possible. I much prefer the tidyness of docked palettes, and really can't stand the floting ones Would be nice if finally, after so many years, someone took the time to fix this. Would be interesting to know how Serif thinks about scripting. From the perspective of tech savvy users it opens up so many possibilities. Is it ever coming?

Yes! for college APA citations for me if we get scripting/plugins by June.

Welcome to the forums @Dimwit You can read (and follow) this thread https://forum.affinity.serif.com/index.php?/topic/64885-scripting/ for more information about scripting. That seems to be the official place for Serif to tell us what’s happening with scripting so if there’s any news on this then it will either be announced there or the functionality will be in a beta release, which will have its own thread in the relevant forum section. Note: At the time of writing, there isn’t any kind of scripting functionality other than macros, which can only be created in Photo.

Photoshop has a scripting language, that can make actions (Macros) basically a recording of actions you perform in Photoshop, they call these; appropriately enough Actions, these actions are stored as .atn files that you can load into photoshop. Affinity cannot interpret these action files because it doesn't use adobe's scripting language. A PSD file is a proprietary Adobe file associated with Photoshop, Adobe are probably the best to explain what a PSD file is: https://www.adobe.com/creativecloud/file-types/image/raster/psd-file.html Affinity can open a PSD file and can save as one too but if the PSD file came from Photoshop it may have processes and have used features that are specific to Photoshop and that Affinity cannot replicate.

Hi Martin. Serif has shared publicly that they are working on a plugin API and scripting which should enable plugins like this.

I will share the actual afphoto document later, it needs some tweaking to make it usable for those who are not the author. The trick is not a simple formula, but combining multiple techniques to unroll loops, store runtime variables inside color channels of layers (or as blend result from layers) compress / decompress value ranges to [0…1] interval unroll if / then / else statements into math formulas understand that with PT filters you parallelize the calculation of every x/y position in one step, you need to unroll the loops or steps of a script into individual layers. The main challenges: affinity has no scripting you cannot iterate (no for loops) values in layers are bound to interval zero to 0 where to store loop variables? to solve 1 and 2, I flatten iterations into layers. A for loop from 1 to 100 is implemented as 100 PT filter layers. The loop variable is store in one color channel. to solve 3, values of higher ranges (-2 to +2 in this case) are compressed or decompressed by a simple formulas c(u)=(u-min)/(max-min) u(c)=c*(max-min)+min to solve 4, I use color channels as memory: R takes real part of z, compressed as described above G takes imaginary part of Z B takes index (integer), divided by 255 as I limit iterations to this number. R and B are calculated by the well known formula, of course using the decompression and compression. B is incremented as long as len(z) is below 2. the step function helps to mimic an if-then-else statement as formula. if a>b then t else f: var c=step(a,b); c*t + (1-c) *f In c 1 stands for true, 0 stands for false. To get many PT filters I group 2 of them (duplicated linked), then duplicate and group this pair again 8 times to get 2^8=64 layers. all this gives a stack of layers which has the number of iterations in B channel. The other channels can be ignored for visualization. On top a PT filter is added to map the blue channel into all RGB channels. A final gradient map can produce fancy colors.

I like such fractals and mandelbrot set stuff, as it reminds me to good old computer times, where one tried to use the GPU for the math+drawing code parts and the mandelbrot set image symmetry (aka calculate and draw half and reflect it on the axis of symmetry), in order to compute & draw those things faster than commonly. Of course nowadays one can draw such stuff even quite fast with scripting languages. - Here are two Py approaches, the first one is fast and saves the drawn result out as a PNG image ... Py code #1: from PIL import Image, ImageDraw # Mandelbrot iteration function MAX_ITER = 80 def mandelbrot(c): z = 0 n = 0 while abs(z) <= 2 and n < MAX_ITER: z = z*z + c n += 1 return n # Image size (pixels) WIDTH = 600 HEIGHT = 400 # Plot window RE_START = -2 RE_END = 1 IM_START = -1 IM_END = 1 palette = [] im = Image.new('RGB', (WIDTH, HEIGHT), (0, 0, 0)) draw = ImageDraw.Draw(im) for x in range(0, WIDTH): for y in range(0, HEIGHT): # Convert pixel coordinate to complex number c = complex(RE_START + (x / WIDTH) * (RE_END - RE_START), IM_START + (y / HEIGHT) * (IM_END - IM_START)) # Compute the number of iterations m = mandelbrot(c) # The color depends on the number of iterations color = 255 - int(m * 255 / MAX_ITER) # Plot the point draw.point([x, y], (color, color, color)) im.save('output.png', 'PNG') The second example uses instead Py turtle graphics and is therefor much slower for on screen rendering .... Py code #2 (via turtle): #!/usr/local/bin/python3 import turtle import math def mandelbrot(z , c , n=20): if abs(z) > 10 ** 12: return float("nan") elif n > 0: return mandelbrot(z ** 2 + c, c, n - 1) else: return z ** 2 + c # Screen size (in pixels) screenx, screeny = 800, 600 # Complex plane limits complexPlaneX, complexPlaneY = (-2.0, 2.0), (-1.0, 2.0) # Discretization step step = 2 # Turtle config turtle.tracer(0, 0) turtle.setup(screenx, screeny) turtle.bgcolor("#010f7c") screen = turtle.Screen() screen.title("Mandelbrot Fractal (discretization step = %d)" % (int(step))) mTurtle = turtle.Turtle() mTurtle.penup() mTurtle.shape("turtle") # px * pixelToX = x in complex plane coordinates pixelToX, pixelToY = (complexPlaneX[1] - complexPlaneX[0])/screenx, (complexPlaneY[1] - complexPlaneY[0])/screeny # Plot for px in range(-int(screenx/2), int(screenx/2), int(step)): for py in range(-int(screeny/2), int(screeny/2), int(step)): x, y = px * pixelToX, py * pixelToY m = mandelbrot(0, x + 1j * y) if not math.isnan(m.real): color = [abs(math.sin(m.imag)) for i in range(3)] mTurtle.color(color) mTurtle.dot(2.4, color) mTurtle.goto(px, py) turtle.update() turtle.mainloop() And of course things can be additionally color optimized in Py code, so that the drawn output will look much more pleasing then ... Py code #3 (colorings): from PIL import Image, ImageDraw from collections import defaultdict from math import floor, ceil, log, log2 MAX_ITER = 80 def mandelbrot(c): z = 0 n = 0 while abs(z) <= 2 and n < MAX_ITER: z = z*z + c n += 1 if n == MAX_ITER: return MAX_ITER return n + 1 - log(log2(abs(z))) def linear_interpolation(color1, color2, t): return color1 * (1 - t) + color2 * t # Image size (pixels) WIDTH = 600 HEIGHT = 400 # Plot window RE_START = -2 RE_END = 1 IM_START = -1 IM_END = 1 histogram = defaultdict(lambda: 0) values = {} for x in range(0, WIDTH): for y in range(0, HEIGHT): # Convert pixel coordinate to complex number c = complex(RE_START + (x / WIDTH) * (RE_END - RE_START), IM_START + (y / HEIGHT) * (IM_END - IM_START)) # Compute the number of iterations m = mandelbrot(c) values[(x, y)] = m if m < MAX_ITER: histogram[floor(m)] += 1 total = sum(histogram.values()) hues = [] h = 0 for i in range(MAX_ITER): h += histogram[i] / total hues.append(h) hues.append(h) im = Image.new('HSV', (WIDTH, HEIGHT), (0, 0, 0)) draw = ImageDraw.Draw(im) for x in range(0, WIDTH): for y in range(0, HEIGHT): m = values[(x, y)] # The color depends on the number of iterations hue = 255 - int(255 * linear_interpolation(hues[floor(m)], hues[ceil(m)], m % 1)) saturation = 255 value = 255 if m < MAX_ITER else 0 # Plot the point draw.point([x, y], (hue, saturation, value)) im.convert('RGB').save('output.png', 'PNG') BTW Julia sets are fun & charming too ...

I plan to write a script to do this when scripting becomes available. It will be a good way to learn the script model.

Of course we can also make the same for ADe reusage with some Python scripting, as an example with it's fun simple Turtle graphics. - So let's make it quickly instead with some Python Turtle drawings ... from turtle import * for theta in range(0,360,30): fd(100) write(str(theta)+'*') backward(100) left(30) goto(0, -100) circle(100) goto(0, -10) circle(10) mainloop() screencast_turtle.mp4 And if we want to have the whole instead as a SVG drawing for reusage in ADe ... # Use the SvgTurtle package --> pip install svg_turtle from svg_turtle import SvgTurtle t = SvgTurtle(500, 500) for theta in range(0,360,30): t.fd(100) t.write(str(theta)+'°') t.backward(100) t.left(30) t.goto(0, -100) t.circle(100) t.goto(0, -10) t.circle(10) t.save_as('simple_protractor.svg') ... we can use the Python svg_turtle module instead to generate the whole and save it then as a reusable SVG file. simple_protractor.svg

FYI since this 2022 thread you replied to, Serif has since implemented the Tab and Shift+Tab approach to renaming layers so it's easy to rename multiple layers at once. Once scripting is available it should be easy to do what you're asking but until then I recommend using Tab to move from layer to layer. Cheers

Hmm, it should be usually possible to do that from outside of ADe via some Apple scripting and the like. - For example in order to get the laptop monitor resolution (if only that one is active and nothing else as external monitors is connected), one can perform in a command shell (macOS Terminal.app, or iTerm.app, etc.) the command ... ... which will give back then the laptop monitor resolution. When a bunch of monitors is actively used (aka also external connected ones), then the resolutions of all are listed instead. Further one can also size application windows via AppleScript. - Here's an example for "Safari"... ... where ... So by using in Automator an Apple script like this one ... ... or ... ... should then resize the ADe app window accordingly to ... x = 50 y = 30 width = 900 height = 700 NOTE: ...this is just out of my memory here. Meaning I didn't actually tested the above yet for ADe/APub/APh. Another way, for macOS >= Monterey users, might be to use the macOS Shortcuts.app as described here ... The Easiest Way to Resize All Windows on Your Mac Simultaneously to the Same Dimensions ... as far as an Affinity apps main window can react and thus be be controlled that way (...the same would apply here to support by Apple Scripting at all).

Affinity V2 does not currently have scripting support but it's something our developers are working towards, as mentioned here and demonstrated here.

My thinking was that scripting should at least be able to enumerate the named layers & avoid reusing any of them.

There too you would have to identify, jump, move, count (the amount of) ... etc. of the correct layers to use (aka deal with), especially for foreign docs not created by your own and with different layer structures & orders. So to some degree the same applies there then too, though it's then hopefully easier to select a certain range/amount of layers up or down from an actual selected one. - But the whole highly depends on the scripting API implementation and also to what degree then functions have been mapped & been implemented in that there then.

Hopefully, when scripting finally comes to AP this won't be a problem.