Search the Community

Like most professionals do, I need this, too. +1 I would also agree with scripting support or an API, so users could write their own export-tool. b

What I suggested are instead more using some common language (bash, perl, python ... etc.) scripts than Automator based. Though there are for sure also ways to do it with Automator. All of the above named scripting languages support regular expressions, which are handy for extracting/stripping/appending/including portions of characters in a string (the file name string). - Perl for example has a "rename" command which can deal with regexp, python is also powerful in that regard. - It depends on what you personally feel more comfortable with here, namely using some shell based script processing or some GUI tool instead. There are also Mac desktop related ways to do so, in general there are many ways which lead to Rome.

On which OS are you working and what scripting capabilities do you have there? - In order to rename 800 files that way I would build a custom renaming script for that task, or use some appropriate already available third party tool for the job.

For the time being, indeed I do, because I just came out of a four-year-long MA and am still more than seven months away from a PhD scholarship application; basically, I'm on yet another “extended vacation” of sorts, though I have that application to make and an entire book to publish, so there's that. But rest assured, I only “waste” time with stuff I really care about. I see it more as an investment, really; I always stood to gain a lot more, that's why I even bought this thing, knowing full well it wasn't finished, in the first place. Oh, I also bought Publisher, even while being extremely mad at Serif and knowing that, because of their really weird choices (and the fact they foisted them upon us, instead of giving us some much needed workflow and document model customisation), it wasn't likely I would be using Designer frequently for the foreseeable future. But much like I had already used Designer to make .EPS/.PDF files that I then imported into InDesign, considering how cumbersome Designer actually is I may end up, if Serif doesn't get their act together, throwing in the towel, and doing the exact opposite by using mostly Inkscape in combination with bits of Designer and the Designer Persona in Publisher, depending on exactly what kind of artwork I'm dealing with, because InDesign is really becoming that horridly buggy as of late. It now reeks of QuarkXPress 5 in a bad day. As for fully replacing Photoshop with Affinity Photo, the jury is also still out on that one, but out of the three components of the suite it's probably the one I'm most optimistic about. My purchase decisions are almost never political or emotional, but strictly technical and very self-serving. You see, €40 really is peanuts for me, even if I end up not making much use of an app, as I absolutely must keep tabs on things and stay ahead of the curve so that I can keep being the influencer I've been for many years (9 in an official capacity, to be precise, and around 16, if you count all the way back to when I entered my Uni and started becoming the unofficial go-to guy for all things Mac). Besides, I'm running all this stuff on a 5K iMac with 40 GB of RAM and a secondary 24'' screen. It really doesn't make much of a difference how many different apps I work with at the same time and how I deal with linked files, as I have way more computing capacity at hand than I should usually need anyway (all that RAM is there for the one-off VM, and the 32 GB I had for many years on my vintage and trusty 2009 27'' model did indeed save my proverbial behind on more than one such occasion). To say that I'm not a normal user is a bit of an understatement. As for Affinity's “StudioLink” thing, well, that's all nice and cool, but I don't really need it per se. I've been doing this kind of stuff for almost 19 years now, and I know I can devise my own workflows, complete with stuff like GREP styles, scripting, batch actions and whatnot, and make them work faster and be more optimised than anything Serif may come up with by themselves (and even if their default way is marginally faster, it's probably not worth the hassle of retraining my muscle memory for it). Still: I would like to see these three apps blossom into something barely functional, as a whole like Serif intended and heavily promoted, and finally chuck everything else into the bin. Is that too much to ask? I know I will keep fighting for that dream.

Yes, basically a sequence of key-presses or mouse movements and clicks. But not scripting as most of us use the term.

Thanks. Yes, that makes sense. You do not have all those capabilities in Photo. You can record many (but not all) of the things you can do with the mouse or keyboard shortcuts. You can allow the user to adjust parameters on Filters and Adjustment Layers that your macro adds to the document. But to see what can or cannot be done in a macro you really need to try recording a macro and see if you can record the functions you want to record. I don't think there is a full list anywhere of what can or cannot be recorded. There is no scripting capability.

Let me see if I can find relevant comments on Scripting capabilities for users, from Serif Staff members, but just by memory, the idea is that it will be accesible to anyone. Best regards!

Personally, I'd prefer a Javascript-based scripting implementation (with a thoroughly-documented object model). But now is probably not the time, since the program's functionality is still very much a work-in-progress. JET

That is a shed load of code you'll be working with. I am quite likely wrong but I would think your result would be easier realized with a pure scripting solution using the text string as a variable. I don't see how an SVG file would simplify things.

»» you can still import your custom tagged plain text (or even html tags) and then use simply Search and Replace to remove the tags and apply equivalent paragraph and character formatting to text That would become a lot of work if we're talking about a long document with complex formatting — the kind of work I'd hope to avoid. I've done that kind of thing in the past when I had to. It was tedious and time-consuming. In such cases it's as if the computer isn't helping so much as hindering — creating more work for you rather than less. When you can run scripting within a program to help automate such a task, that helps ease some of the pain. »» There might be a bug in Publisher as it currenly does NOT remove the tag even if the Replace field is left empty, if the replacement contains a style criterion Sounds like a bug, all right. If you want to be rid of the tags entirely — when formatting during the replacements is not an issue: Assuming the program supports character classes and "greedy" matches, this should work (not tested on any real-world document in AP, but I've done this kind of thing many times in the past): Search for: <[^>]+?> That is: find "<", then 1+ of anything that isn't ">", up to — but no further than — the next occurrence of ">" ... and for "replace" use: nothing at all. This would kill ALL of the elements at once — <p>, <p class="xyz">, <h1>, <ul>, et al. The expression could become more complicated if you also want to remove all closing tags and/or those like "<br/>" in a single pass.

I tried a couple of Word "clone" programs. LibreOffice was buggy...won't take the time to troubleshoot. Uninstalled it. Next was a demo version of an inexpensive program called SoftMaker Office TextMaker. No bugs so far. (I know, I know — give it time...) Next step: Small HTML file containing CSS definitions such as: p.test {} Right — just "{ }". Absent the braces, this doesn't work. The test document contains such text as: <p class="test">something here</p> This does create a paragraph style "test" in the TextMaker file. Don't know yet about character styles. Having already devised tagging schemes for plain text that became XHTML files, I can see that it wouldn't be difficult to do the same again. The scripting (Perl) is a bit tedious, but once it's done it's done and then you have your HTML file. Open it in the Word (clone) program, import the styles of a previously set-up .DOCX file, and this might be workable after all. Well, for self-authored text. Tediously re-tagging someone else's manuscript would be...ugh. How AP treats incoming Word styles is another matter. No clue on that yet. And no clue yet whether AP will accept — or choke on — .docx files created in TextMaker.

If the underlying architecture doesn't now support plug-ins, I wonder how much difficulty they'll have adding that later. I never used InDesign — I was out of the book-pagination business long before it became "a thing" — and haven't seen its tagging system. Is it ghastly, along the lines of SGML? My recollection of XPress Tags is a bit hazy. If memory serves, XPress Tags permitted you to specify not just character styles, but named paragraph styles during text import — yes? I actually worked on a book about QuarkXPress way back then. I suppose I could just go look it all up. :-) Even rudimentary tagging would be better than nothing. {pstyle:"some-style-name"}Some text {cstyle:"italics"}with formatting{/cstyle} via tagging.{/pstyle} I suppose that to someone who's never used systems like that, it looks decidedly user-hungry. But to people accustomed to scripting it's a walk in the park. I did this in creating a simple e-book once. Devised my own system of text codes (far simpler than the above) and then wrote scripts to transform the simple codes into XHTML in which the style names matched what was already set up in the ePub editor. Not worth taking the time for a small job, but absolutely worth taking the time to set up if it's a long document. In the end you save a lot of time and headache...

To be more precise. It is example how can you scripted Affinity Publisher today. It is not easy and comfortable solution. First you have to use this aproach to create more user friendly library. AutoIt I put here as temporary solution before full scripting will be implemented. Personaly I prefer Python for short and robust code. I dislike JS as sometimes not clear for me.

Now it is one walk around, but is not very user friendly. For Windows platform you can use AutoIt. Using spy Windows you can get native GUI windows fx. for Affinity Photo: HwndWrapper[Photo.exe;;452e26ab-922c-48d1-ae6b-1160a6b1a0f4] Using AutoIt command you can send clicks and keys to simulate real user active work. The most pain is build that way structure to work with it and next create scripting layer called your first created structure. To show up in practise what I mean by structure I paste below example code from Autoit forum (GIMP automation): Opt("WinTitleMatchMode", 4) While 1 If WinGetHandle("[CLASS:gdkWindowToplevel]") Then _GetHandles() HotKeySet("m", "fractal") Else HotKeySet("m") Sleep(100) EndIf WEnd Func _GetHandles() ;Variables global $WindowHandle = WinGetHandle("Programa de manipulación de imágenes de GNU") ;Get handle of the main GIMP window. global $ToolboxHandle = WinGetHandle("Caja de herramientas") ;Get handle of the GIMP Toolbox. global $WinTitle1 = WinGetTitle($WindowHandle) ;Get title of main GIMP window to test that it is the correct window. global $WinTitle2 = WinGetTitle($ToolboxHandle) ; Get title of GIMP Toolbox to test that it is the correct window. EndFunc ;==>_GetHandles Func fractal() MsgBox(0, "0", $WinTitle1 & " " & $WindowHandle & @CRLF & $WinTitle2 & " " & $ToolboxHandle) ;Present a message box to confirm title and check handle against the Window Info Program ControlFocus($WindowHandle, "", "[CLASS:gdkWindowChild; INSTANCE:2]") ;Focus on the main GIMP window ControlClick($WindowHandle, "", "[CLASS:gdkWindowChild; INSTANCE:17]", "main", 1) ;Click File ControlClick($WindowHandle, "", "[CLASS:gdkWindowChild; INSTANCE:19]", "main", 1) ;Click Open as Layer... EndFunc ;==>fractal

Hi Hanterdro, Regarding Photoshop plugins/addons compatibility this is a little more complicated than that. Photoshop plugins are developed using Photoshop's software development kit and (some of them) designed to take advantage of more advanced Photoshop's features/functionality in particular automation, scripting, custom ui/panels (extensions) etc, which are simply not available in Affinity Photo (or were implemented in a different way). Although we keep improving support for them, we will always be limited by the differences/different implementations between the two programs. Regarding HDR Efex Pro in particular, I believe we can do something to fix this - the free Google version of the plugin worked with Affinity 1.6 (albeit in a limited fashion). I've already passed this/logged the issue with the dev team to be looked at.

the panels don't obey my scripting commands in autoit or ahk... possibly I'm not a good enough script writer... I'll do my best to not convey my frustration again... perhaps I just failed at that too. this is just not the way you guys are supposed to be 'killin it'.

Yes people are requesting API/Scripting... they will not touch Affinity designer with out it. I attempted to suggest Affinity designer to some motion designer colleagues and the answer was w/o API/Scripting support they will not use Affinity Designer. It isn't worth their time otherwise. Love what you guys have done so far and I want to see Affinity Designer grow just as much as you guys.

Hi photoadele, Welcome to Affinity Forums Photoshop actions, extensions (panels) and plugins relying on automation are not supported in Affinity Photo. These add-ons where developed with Photoshop in mind and rely on Photoshop's features/scripting and/or on Photoshop SDK (software development kit) to provide such functionality. I don't know if you are already aware but Affinity Photo provides a basic built-in filter for Frequency Separation... (menu Filters -> Frequency Separation...). There's a video tutorial here covering how it works (it's for version 1.6 but it can be followed in v1.7 as well). I believe some users also developed and shared a few frequency separation macros (for Affinity Photo) in the Resources section on this forum but I may be wrong. I will post them here if I find them.

Yeah, that's what I am doing now. I am hoping for the ability to save find/replace searches, but if some sort of scripting were created, I would probably take great advantage in the same way you suggested, and my need for saved searches would be greatly reduced.

Hi everyone here on the forums! My name is Jace, i'm the chief and founder of a marketing group located in New York with a team of five graphic and web designers on board. so as you can figure out alone, i'm spending a tremendous amount of money in subscribible licence purchases, just to cover my adobe creative apps... When i heard that there is a new competitor to Adobe with a range of 3 productive alternatives apps - overall - a one time purchase, it was very interesting, and i decided to try it out if to check out if it comes on the daily work for my small team, and yes, i can say fully confident that it's really wonderful how they get done such amazing products. In fact, there is one reason why i feel that i can't switch right now to those apps. and no, it's not because there is still a range of features that is currently unavailable in this (1'st) version of affinity, like 'image tracing' and 'scripting' and more, taking in mind that its a new suit of applications, and it will forsure get big updated with the time. The reason why i can't change my office apps to affinity, and in the same time to reduce my adobe bill to half or less (i still need the web and animation tools from them) is simply 'right to left' support. After a deep trial season, i figured that rtl lang. are not supported, and i can't stick with a program that will have problems every time there will be a few words in any of the Middle Eastern languages like arabic or hebrew (something i don't have daily, but also occasionally is enough to be a concern). Actually, i will have now to stay with Adobe. and i'm sure that the day things will change, i will be back with you. the affinity serif apps are super fast and stable! hope it will be soon. All the best!

First I want to congratulate everyone in Serif for creating this awesome software and trio. After being a user of the Publisher Beta and being active in this forum, I have collected a list of features that I need for my work (mostly book interior design) and some that others requested. I'm not saying that Serif should provide them in the near future, but I hope it helps them see what's needed and give an outline for other members of the community. And I hope affinity will release an official roadmap for Publisher soon. Languages: Support for CTL: Complex Text Layout, Indic and RTL languages like Arabic and Hebrew CJK: Vertical text and proper punctuation Text: Footnotes/Endnotes Insert variables based on paragraph/Character styles/Index entries... Paragraph styles spanning through columns Compatibility: Open IDML files Scripting Tables: Tables Spanning through pages Repeat header when a table span to another page Calculations inside tables RegX: Save RegX Find/Replace Execute Saved RegX Find/Replace from inside paragraph styles eBooks: Export to ePub Option to set HTML tag +/- class for each paragraph style. Export to pure HTML file — I wanna know your idea about implementing HarfBuzz for Complex Text Layout —

But that ReaScript API supports in it's ReaScript/EEL and ReaScript/Lua API (so in both) to create/draw filled/unfilled rectangles... ... and for LUA the same functions ... ...so with these functions via a loop which alters a rect with gfx.rectto(x,y) it should be easy to do that directly via Reaper scripting.

Hmm the need of 128 slider images just for one slider sounds somehow to be app related very inefficient to me. Suppose you have to setup different colored sliders, that would mean to setup a bunch of images then just for simpler UI elements. It would be probably more efficient to programatically build a custom drawn slider. However, since the Affinity line doesn't support scripting your best choice is possibly to code some SVG script here then, meaning to either draw a two rects one positioned over the over and variing the cover size/height of the top filled rect, or to use one rect and a apply various different dimensioned gradient fills for that. In order to build 128 or more of those, perform the whole through a loop with variing loop index and var settings for the positions, size and fill values.

Basically for a more variable usage the software itself only needs a good external accessable C/C++ API for interface connectivity. Everything else (services, some language access etc.) can be mapped and build on that one then. If it would be half way good documented then even by third parties. - For casual users an internal API with a hooked on powerful scripting language implementation would be probably enough. Also, in either case, the whole thing lives and dies with the quality of an implementation and related useful documentation.

This doesn't mean what you think it does. The "language" in the proposed solution consists of the service calls that Affinity publishes over this internal web server. Whoever wanted to script this in some "arbitrary" language would in effect need to learn two languages instead of one: the language of the service calls, and the language they are using to try to access them. It would add the burden of managing the client-side connectivity to the service on top of the need to deal with the interfacing. While it would theoretically be possible to create client modules/units/packages/libraries for an assortment of languages, how would this be any better for the typical user than using an equivalent module/unit/package/library that wrote out AppleScript code and submitted it using the OSA tools or vbscript code and submitted it using the Windoze equivalent, while at the same time opening up the system-level scripting libraries to make this work coherently with other applications in the way that the OS authors intended? This "solution" is adding some illusion of familiarity for a small subset of users at the cost of massively increased complexity and overhead, not to mention worse performance, for the majority of users. This doesn't actually solve anything.