kimtorch

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.

No. We don't use Word.

Precisely, but I didn't think it would need to be explained when Quark and Adobe have been doing it for decades. For @Jon W and @Tim France , the reason this is important is the script code which needs to be written. If you don't have the ability to read tagged text then parsing and trying to assign styles has to be done in the script code which would be horrendously bad. I'd go as far as saying people simply wouldn't do it. If you can read tagged text through an appropriate filter an entire formatted, aligned, coloured and styled text block can be done with a single line call: place tempfilepath on myFrame showing options no given «class rtfo»:yes

Here's a typical workflow for us (we're a newspaper/magazine publishing company). Editorial is written in a (proprietary) app running MySQL (most editorial systems do similar). The writers never open InDesign. A section will be applied to stories (Front Page, EGN, Real Estate, Features, Entertainment, Sport etc) In our particular case, we apply styles based on section. EG. Front page heading might be Helvetica Black at 120/110 where basic news might be Helv. Bold 72/70. Captions will be different as will Bylines and Intros. This general style is set as soon as they select the Section but editorial staff can also add styles to any word or text run and custom tags will be added to the text. If we want a word in Bold for instance, it might be simply enclosed in <b></b> tags which are interpreted by the app into correct InDesign tags before insertion into the database. This is all handled by the app - editorial staff never have to enter any tags. It also calculates depth and shows previews so they can be sure sizing is correct (they can manually over-ride a heading for instance) Once the story is saved to the database, a companion app is used to call stories onto the page. It creates (by script) the required frames and labels them with the Story_ID, partID (Heading, Sub Head, Caption, Intro, Body, pull-quote, Cross Head etc). Then the story is placed (by script) and the tags are interpreted by InDesign so the text is formatted exactly to style - regardless of which section they've chosen. Editorial staff know nothing about styles, they simply allocate stories to the correct section. The real beauty of this is it requires NO styles to be set-up in InDesign - so no, it doesn't map existing styles - it is totally independent of character or paragraph styles and can be done on a brand new machine with a clean install and still work. It also handles updates and corrections. If a journalist changes a story, removes words, changes sections or italicises different words in a story that will all be reflected when the story is re-imported and the text will always be formatted correctly. Updated stories are flagged in the Place app so prepress people know they need to be updated. I should point out it places images and brings them in with styled captions. It has functions to send directly to Wordpress (and Apple News) and the styles are automatically translated - although these are mapped to the existing styles on those platforms. Everything I've said, importing text, setting styles, linking captions with their images, styling heading, sub headings, intros, bylines and body text is ALL done with scripting and tags. Scripting in professional publishing isn't about creating fractals and pretty lines. It NEEDS to be able to manage large quantities of text and format it seamlessly. Here's another example. Someone builds a 400 page catalog. All the data is in a database with tags. It can be flowed onto pages, frames created and labeled based on sku numbers, text formatted, images placed and styles and colours applied based on the section of the catalog. You could potentially build the entire thing in a few minutes. I appreciate you're trying to get this working but I'm not sure exactly which users you're trying to engage with. This has been one of my concerns since starting this thread - many of the people commenting sound like they have never scripted Quark or InDesign - they seem more intent on pushing their favourite programming language. I'm sorry if I'm sounding harsh but I'm staggered the functionality of scripted document production and tagged text needs to be explained. It's really automated publishing 101. The line in your post I find most interesting is "We're software developers not publishers". This is why you need to be talking to publishers. Do you think Adobe created InDesign without speaking to Quark users? The reason our system works so well is because it was written by someone who had more than 20 years experience in publishing before starting it. You're never going to satisfy users if you don't know what they need.

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.

Speaking of import/export, is there any news on whether there will be some form of text tags for scripting formatted text?

It's now been about 6 months since Tim France teased with some scripting news. Given Adobe have just announced price increases for Creative Cloud, it would be nice if we could have any sort of update on any progress being made. Even the smallest glimmer of hope of when it might find its way into a beta. It's hard to believe I started this thread over 5 years ago.

That's cool, maybe once we get to see the scripting model there might be an opportunity for you to write a Plugin for general use. When we move data from our editorial system to InDesign, text and graphic frames are created by scripts. We label every frame with a script label which specifically includes the story ID and what type of component it is (Heading, Sub Head, intro, body, captions etc). Formatting is done with tags so a journalist can update the story in the editorial system and our related import app (a front end to a variety of scripts which talk to MySQL) can update stories in situ. This is why I believe script labels (or some sort of tag) for page items is critical. Scripts need to be able to address items by name and I believe this would be similar in your case where you're looking for various text blocks to move to Wordpress.

I see this as a bit trickier and probably in the realm of a Wordpress plugin. There are already a couple of InDesign to Wordpress Plugins so it might be worth contacting the authors to enquire on the viability of writing a Publisher version. It could potentially be done by scripting but would require considerable thought on how you address which page items you want to publish and a decent knowledge of JSON would be needed to handle the Wordpress side. It would not be a trivial undertaking but it could be done if the appropriate hooks were in the Publisher scripting model. I wrote the editorial system at our company and one of the key features was the ability to publish directly to both Wordpress and Apple News. The editorial staff can publish to the web before a story has even been allocated to a page - totally eliminating InDesign from the equation. They write the story, add the standard meta data, allocate the images and then simply click "Export to Wordpress" and it magically arrives online complete with the correct category, publication, tags, feature pic, byline etc. It's truly beautiful to watch

Scripting find/replace would be good but an additional feature request should be the ability to save find/replace searches. InDesign does this and allows you to maintain an extensive list of frequently used changes. Being able to script it would also be good.

I agree, I'd much rather see examples of people's current scripting rather than trying to redesign or expand something which doesn't yet exist. If people would like to speculate on how a scripting engine could be called or which language it should use then they're free to start a new topic or write directly to Affinity. The entire purpose of this thread (which I started) was to enquire if Affinity were going to support scripting and what people are currently using which they would need to 'change teams'. It's frustrating enough having waited this long for a glimmer of hope to see constant divergence to obscure topics and references. As I've said previously, it's fine to want 'everything' but it means it's never released. Tell them what's important - ie: what you're currently doing by script - then by all means submit your dreams once the rest of us are quietly getting their work done.

This is laughably wrong. Ask Apple, Microsoft, Adobe, Google or any other software producer. Going for perfect means a product NEVER gets released. Perfect is a utopian aim, but a naive, unrealistic project path - especially for a company the size of Affinity. InDesign's scripting isn't perfect - but I'm glad we've had access to it for 20 odd years.

Whilst I appreciate everyone wants even the most obscure functions to be scriptable, let's not let 'perfect' get in the way of 'good'. Remember this is a product that currently supports NO scripting at all so I think it's better to keep requests realistic based on where it now sits. Rather than imagining ideas of what could be done in the future, I suggest people start by submitting what they currently script in InDesign or Quark. This way Affinity have a good idea of what people are currently using and actually NEED in the AP scripting model. From reading this entire thread I'm sure there are a lot of people here who have never scripted InDesign or Quark in their life - they're more concerned about pushing their language preference than actually getting print work done. But I digress... Very few of the things I've seen listed are of any interest to us (yes, I know they may be 'important' to others) but we are a publishing company and have a desperate need for the basics of printing and publishing. These aren't things we'd like to do in InDesign - these are things we do literally hundreds or thousands of times a week and need Affinity to support before we'd ever consider changing. Generate pages and documents based on templates Create frames with definable properties (type, geometric bounds, colours, text properties, name etc) I'll reiterate naming of frames as that is vitally important to the way we address target frames in InDesign (script labels) Populate frames with text or images allowing all fitting options Importing of tagged text and RTF - ideally adopting the Adobe model of tagging so existing frontends would 'just work' Create PDFs, jpegs, EPS files with definable presets Iteration through frames and placed images Ability to manage colour spaces Scripted preflighting This is obviously not an exhaustive list but it's the primary functions we need to get a start. Our company simply can't run without automation. AP could be the best page layout product in the world but until we can do at least the basics of automation it's essentially worthless to us.

This is essentially standard behaviour on a Mac so I'm always surprised when I try to do it and it doesn't exist. From a developer's perspective I wouldn't think it would be a huge task.

Maybe, maybe not. Given I was the one who started this discussion almost 5 years ago - and explicitly mentioned things like PDF creation, tagged text, importing into documents etc - I think it's reasonable for me to have an opinion on scripting capabilities. I hope they do bring scripting capabilities to Affinity Photo, but with over 40 years experience in the printing and publishing industry, I have a very good idea of where priorities for automation should lie. As to your point about Affinity information, it's in their best interests to give as much information as possible as early as possible. The last thing they'd want to do is spend many years working on something only to find it doesn't meet the expectations or requirements of users. They're far better off getting feedback before they're fully committed to a wrong direction.

I'm pleased to see some progress but - I'm sorry - a little underwhelmed by the examples. As a publishing company our primary tool is InDesign. Our priority for scripting is Publisher and things like placing and formatting text, importing tagged text, archiving files, creating PDFs, exporting for web etc. Creating grids and designs is 'pretty', but it's of zero interest to us compared to the aforementioned text and document processing which happens every minute of every day and is where the real time savings are. I appreciate others may feel differently, but as a working publishing company I'm focused on the greatest savings we can get. Thanks for the update but I'll reserve any 'excitement' for when you can demonstrate some productivity scripts in Publisher.

I have zero interest in Blender or 3D. I do have massive interest in being able to script the majority of functions of the existing app so I can automate tasks I need today. I'm bemused by the number of comments in this thread saying "do this" or "use that" and it appears they've never actually used or scripted InDesign or Quark. I'm all for expanding the capabilities going forward but right now I'd settle for being able to create an object and place some text in it. Publisher is a print program first and foremost so the scripting functionality needs to focus on ink on paper - everything else is speculative detritus. As Adobe has the market Affinity wants, it makes perfect sense to compete in that market. I suspect if they wanted the Blender market they'd create a Blender alternative.

They chose what they believed was most suitable. As Adobe and Quark use Javascript - and as they're the closest competitors - it makes sense to have a language with which potential users would be familiar. I doubt they care what Blender etc use as they're not the users they're trying to attract. In all the software I use none uses Python, but many support javascript and/or applescript.

It's encouraging to hear this and I want to thank TonyB (and Affinity) for putting it out there. At least we now have some glimmer of hope for the future. I'm happy enough with javascript as the language. It makes sense to have a single, cross platform language and with JS already available in InDesign, it means a lot of active scripters will have a head start. It will be interesting to see the syntax and object model - just imagine if a script which runs on InDesign could run on Publisher with only minor changes (similar to how Affinity works their magic with IDML files). I know it's fanciful, but it really would be magical! I'd love to have a rough time-frame but I expect that's asking too much. As mentioned elsewhere I'd be happy with some basics to get started and then build up the library over time. Having an API is also encouraging. I don't write C but I can imagine there will be an active marketplace for plugins if they keep to the low-cost Affinity model.

If so, you will likely be able to afford hi-end software that can do the job for you the way you need. Right? Yes we can, and it's exactly what we do. You seem to be suggesting Affinity has no desire for our business and the way to resolve the deficiencies of their product is to use a different app. No problem, I'm sure they're happy for you to tell people not to use their software. I'd bet we're not the only media company who'd love to change but won't because they can't do the job we need.

I'm beyond depressed reading this thread. I started it almost 4 years ago and there's been nothing but crickets... For mine there should be a few criteria for scripting: 1) it must be cross platform. I don't care if it's two languages (like InDesign) or one but clearly one would be better. I think the obvious one would be javascript but at this stage I'd be happy with even a basic Applescript library 2) it should be able to access non-Affinity apps (Filemaker, Access, Word, Excel etc). The real power of scripting comes from inter-app data sharing. Virtually everything we do with InDesign involves pulling data from our editorial or advertising databases. 3) it needs to be easy enough for a non-programmer to access. Whilst I'm now a programmer, I started my coding journey writing scripts and scripting should be easy enough for a novice. I can't believe people are suggesting every known programming language for simple scripting - some of which would be a terrible introduction to coding. Given the elapsed time, I think Affinity have given up on the idea of scripting. Sales data probably suggests their market is 'backyarders' so they're largely ignoring the commercial market where scripting is widely used. Ironically, if they had more advanced features they would probably make inroads into the commercial media space. I think not targeting large businesses is vastly underselling Affinity's potential. I believe if Affinity had serious plans for scripting they would announce it in a roadmap similar to how they announced the iPad products. You'd think if there was even an inkling it might be in the future there would be messages/surveys going to users - particularly users in this thread - about what might be desired. No, I think scripting is as good as dead and buried so discussion about languages is moot.

As the OP, I'm amazed that nearly 4 years later there is zero information or progress on this. The second post in the thread suggest Affnity had plans for scripting but after 4 years there's nothing. As I've said before, I expect Affinity are happy for Publisher to be the 'backyarders' publishing program because without scripting it's unlikely to ever supplant InDesign in professional production environments. It's truly disappointing.

I agree. In fact in the very first post of this thread I mentioned that tagged text goes hand in hand with scripting and needs to be supported for automated import of text. I'm not holding my breath for either. I don't think people or companies who use automation are the target audience of Affinity. They seem to be content serving individual users rather than businesses or companies.

I'll add my dismay at not being able to export with a Macro. I'm struggling to see why this isn't considered an important step for Macros. Every time I think I might be able to use AP to replace Photoshop another obstacle steps in my way.

No, it doesn't work similarly for other modes. On the Mac the unit is only available in Resample. It may be a bug, but it definitely doesn't work on Unconstrained as Loukash's screenshot shows. And in Resample you can't do it with a single dimension, the 'crop' is constrained to a two parameter ratio. For people working on a few web images or designing small flyers or posters it may not matter too much but when you're producing hundreds of pages each week and you want standardised widths for all images this sort of thing makes a difference. It's also why the lack of scripting is such an issue for professional workflows. Ironically if scripting was available the cropping could possibly be worked around. AP is trying to compete with Photoshop so it needs to be able to do all the basics. Preferably do them better rather than not at all.