kimtorch

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Are there any plans to add scripting support?
I notice there is no Applescript library at all but am interested to know if there are plans to add Applescript or perhaps Javascript support. Virtually everything we do as far as creating PDFs, packaging, placing images and text, formatting, proofing, sending pages to print etc is done via script.
Tagged text goes hand-in-hand with scripting so I think this needs to also be supported.

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.

Are there any plans to add scripting support?
I notice there is no Applescript library at all but am interested to know if there are plans to add Applescript or perhaps Javascript support. Virtually everything we do as far as creating PDFs, packaging, placing images and text, formatting, proofing, sending pages to print etc is done via script.
Tagged text goes hand-in-hand with scripting so I think this needs to also be supported.

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.

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 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.

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.

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.

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.

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.