zixdesign

101, if we are talking about script support for Affinity Publisher in javascript there are tons of things people need to do on the industry side of things. E.g. batch processing of files/folders and documents, document cleanup, script enhanced search and replace, multiple formats export, automated flightchecks... even on the creative/document creation side there are tons of things that can be done which don't require plugins or full fledged programming language/compiled packages. I am sure people will want to link AI into this as well, but for most of the industry side it is not needed or wanted. Printing processes are very specialised, most of them are connected to specific printer types and/or RIPs, and we don't need or want a randomly creative AI to muck things up at that level. WASM compliancy sounds like a good idea to me, just as long as standalone scripts are still allowed. Which is kinda the whole idea with scripting support.

HTML5? Well, that might be nice, but while it has some text features that many page design apps has lacked and may still be lacking, I think it might be too limited for page design. CSS3 is very nice but there is also things like master pages, anchored objects, conditional text... unless this is precisely what Publisher is already using - or some extension of it - I would feel doubtful. HTML5 extended (albeit a contradiction in itself) with CSS 3 extended perhaps...

ICML is only exceptionally wordy when you need to be able to create new content. For changing existing content in existing stories it isn't that bad. We have used a script that isolates the actual text content from the tags for... well, about as long as ICML has existed. Yes, the InCopy markup language is very wordy indeed, but it can be made more usable. For Publisher, the way to go would be to use their own equivalent to ICML (PCML? just a suggestion), and maybe to create a tagged format from that. I don't think using Adobe's markup languages with Publisher would be a good thing in the long run - unless Affinity haven't actually copied the entire text motor from Adobe. Which sounds unlikely.

Or if you would like to develop a tagged format of your own. If so, pandoc could surely be updated to support it. There is an internal markup language in Publisher like ICML, yes? Just that it hasn't been released yet?

Yep, welcome to industrial publishing Next up: a markup language for the document and the ability to export and import ML text portions. Like with InDesign's InCopy format. (Quark's tagged text format is very old and had very bad form so let's forget all about that).

That's good enough for me. Much the same way it was done in InDesign. Since Javascript reads and writes text files, for those that can stand using a conversion-to-txt stage, excel, filemaker and others would still be available the old fashioned way. That's really great if that works Would make it worth it learning either the one or the other for me. Thank you programmers, thank you for the update @TonyB!

Well, since this is (or was) all about scripting support for Affinity Publisher, I think we are getting far beyond here. As long as the scripting language is easy to access and that scripts are easy to run inside an Affinity application, we should be fine. Reasonable choices would be Python, Javascript and the like. Maybe Swift could be made into some scripting extension of some kind, I don't know where Apple put the limits. But in my head at least, Publisher would be the run-time environment for the code, and it would not need to be compiled or packaged or built in any way to be run. Running it from within, say, a panel window inside Publisher, should be enough.

There is no such thing as a secure language. There may be safe or unsafe implementations of code or of a run-time compiling of it, but that is up to the developer. I think all the languages that might come up for discussion already have HTTP and file system access, and necessary limitations of them, built in anyway. This would, or so I think, in 99% of the cases be run locally on a computer, for controlling objects within documents. It would be run as an extension of the application, using whatever is available in the DOM. People will want to do batch processing, so there has to be at least rudimentary file system access. But most jobs done by scripted extensions can be done without even a network available, as long as the files have ended up on the user's drive before processing starts. Or were you thinking of security as in "somebody might steal my code"? That is usually done by compiling (or whatever you like to call it). For comparison, ExtendScript has .jsxbin, for those that like to use it. Personally I don't care much for that. It is better to have the code editable immediately if you want to make small changes, as you will want to.

It is not hard to understand that InDesign is a real beast to compete with. It would be great to see some steps being taken in the right direction though . I understand it is complex and all that, and also of course, we need to understand that it took a few years even for a giant like Adobe to push InDesign to supersede Quark in this respect, even though it was launched as a "Quark-killer", with a very modularised buildup, promising fast development of plugins from third-party developers. But while Quark had its XPress Tags, it had nothing like InDesign's ESTK. The way forward for Affinity? Maybe it could be good to utilise extended javascript, like Adobe did. I am not a developer, I just "cheat". It sounds like a lot of work making the DOM and parts of the interface available for a scripting language. But since we have other possibilities today, maybe it would be smart to look at, for instance, Lua? Python would be another possibility, having been used a lot for similar things, and being just as easy, if not easier, to learn than Javascript. It may feel more "worth it" in these days to learn Python, for an inexperienced would-be Publisher automator developer. To continue with the more technical aspects: the big big change for InDesign and usability/automation friendliness came when they switched from INCX/INCD to ICML/IDML. Every collection of objects (one or many) in a document could be replicated in any other document by the use of so called snippets (INDS), supporting every possible object you can think of making inside inDesign, save for the actual document "framework". Best of all, the code is valid XML, not just some tagged text. The same goes for every collection of objects in a text frame/story. The code is very wordy, and a bit strange when you look at it, but the way they solved it, everything in a story is viewed as a "text style range", so there is no hierarchy with paragraphs and such. This also means the underlying "tagged text" is totally portable. But very hard to read for a human being. I can heartily recommend a look at the code in an InDesign snippet, or an exported InCopy Story. It is totally readable (although, as I said, very wordy) in any text editor.

+1, please open the apps up for any suitable scripting language. I don't much care which one either. If you do it will extend the usefulness of the applications immensely. We have several hundred scripts we use for InDesign, about 20 of them every day, and it is all functions that are customised to the way we work, doing exactly what we need, saving hours and days of work on almost every file we process. Without them, we would step back about 10-20 years in processing. If InDesign didn't "have scripting" it would be rendered useless for us and we would need to ask our clients to please send us something else. I work with tech/layout support for translation, but there are so many other professional use cases in DTP and publishing where scripting is the "absolutely necessary" feature.

And HTML/CSS should not be there either. Doesn't belong at all.

Thanks a lot, @dominik Back @ work again, will follow this with interest as it unfolds.

As someone new to the Affinity suite of apps (hi all :)), but with rather a long time of using ExtendScript for InDesign (and a weeny little bit for Illustrator + Photoshop as well), I am waiting eagerly to see what happens with Publisher. I couldn't agree more with kimtorch here, in your last post - a tagged text of some kind, encompassing any and all possible formatting of the text, and preferably also (like ICML) being able to handle inline objects, that would be very very good.