Bikerbudmatt

We will support a very limited set of platform specific automation functions with one of those exposed functions being able to pass a Javascript snippet that will then have full access to Affinity. 
Hope that makes sense.

Affinity will support Javascript and also have a 'C' based API binding interface that people can use to write plugins. We will also have the ability to create UI to support their scripts and plugins with dialogs and panels. 
We have a team developing this but the amount of work is very large so unfortunately users will need to be patient.

Holy cow.
I just read 11 pages of opinions stretching back 3 years giving Serif all kinds of advice about which flavor of programming language, how proprietary (or not) that language or languages should be, etc. Tip o' the cap to all of you who have brought nuance to that part of the problem.
I have been able to accomplish some amazing tasks over the past 35 years using automation tools. If it wasn't available directly in the application, there were hooks to allow an external tool to accomplish programmatic tasks.
Given that some kind of implementation is needed, and that it involves choices, I want to step aside from that detail and state:
Some form of scripting would vault AP and its suite-mates into the professional tool arena. It's just not there without it. Some form of macro editing/creation, as with Photo, would ease the pain of text manipulation. Some form of saving find/replace expressions for reuse would make it worthwhile to use RegEx/GREP strings. I list those items from most to least difficult (in my naive understanding). In order of implementation priority, I'd reverse the list.
Surely Serif could pick off one or more items from that list and realize a huge gain in adoption (for Serif) and productivity (for users).
 

Yes, and yes. I had to turn back to InDesign CS6 (last version with a standalone license) today to start producing the latest iteration of a long-standing project that requires a RegEx search and replace. First pass to catch all instances of a certain numeric string and reformat it using a character style followed by a non-breaking space to attach it to the next word, then a second pass to catch just the leading instance of that string in each paragraph and reformat it with a different character style. ID has the following features that make this a 1-second task, even on the old iMac that is running it:
Fully supported and documented RegEx implementation Find and replace strings that can be stored and recalled globally Full scriptability Extensible interface to allow the script to be compiled in Java and invoked at will And all of that from software that was released nine years ago. Early CS versions could do the same.
The reason I had to use ID (and had to do it remotely, because the mid-2012 iMac is in another office) is because I can find no other software that will do what I need and bring the results into Affinity Publisher. BBEdit? Only supports text or markup for output, so the amazing RegEx "Playground" is wasted because it can't provide useful output. Microsoft Word? It would seem like an obvious choice, but support for regular expressions (which they call "Wildcards" but which was a reasonable implementation of RegEx) has eroded to the point where it has disappeared from the documentation. And, since AP doesn't seem to support tagging, either, there's no sense in writing a BBEdit text factory to attach markup tags to text.
Lack of tagging support seems especially weird because of all the effort that has gone into the IDML import filter. I'm really hopeful that an LED lightbulb will go off in the developers' heads, because they must be that close to supporting tagging in general.
So again, as @michalmphpoints out, we don't need to solve the "which language" problem for Serif, but I for one would really love to retire that old iMac from its production job so it can serve household files for the next 10 years! 

Holy cow.
I just read 11 pages of opinions stretching back 3 years giving Serif all kinds of advice about which flavor of programming language, how proprietary (or not) that language or languages should be, etc. Tip o' the cap to all of you who have brought nuance to that part of the problem.
I have been able to accomplish some amazing tasks over the past 35 years using automation tools. If it wasn't available directly in the application, there were hooks to allow an external tool to accomplish programmatic tasks.
Given that some kind of implementation is needed, and that it involves choices, I want to step aside from that detail and state:
Some form of scripting would vault AP and its suite-mates into the professional tool arena. It's just not there without it. Some form of macro editing/creation, as with Photo, would ease the pain of text manipulation. Some form of saving find/replace expressions for reuse would make it worthwhile to use RegEx/GREP strings. I list those items from most to least difficult (in my naive understanding). In order of implementation priority, I'd reverse the list.
Surely Serif could pick off one or more items from that list and realize a huge gain in adoption (for Serif) and productivity (for users).
 

Yes, and yes. I had to turn back to InDesign CS6 (last version with a standalone license) today to start producing the latest iteration of a long-standing project that requires a RegEx search and replace. First pass to catch all instances of a certain numeric string and reformat it using a character style followed by a non-breaking space to attach it to the next word, then a second pass to catch just the leading instance of that string in each paragraph and reformat it with a different character style. ID has the following features that make this a 1-second task, even on the old iMac that is running it:
Fully supported and documented RegEx implementation Find and replace strings that can be stored and recalled globally Full scriptability Extensible interface to allow the script to be compiled in Java and invoked at will And all of that from software that was released nine years ago. Early CS versions could do the same.
The reason I had to use ID (and had to do it remotely, because the mid-2012 iMac is in another office) is because I can find no other software that will do what I need and bring the results into Affinity Publisher. BBEdit? Only supports text or markup for output, so the amazing RegEx "Playground" is wasted because it can't provide useful output. Microsoft Word? It would seem like an obvious choice, but support for regular expressions (which they call "Wildcards" but which was a reasonable implementation of RegEx) has eroded to the point where it has disappeared from the documentation. And, since AP doesn't seem to support tagging, either, there's no sense in writing a BBEdit text factory to attach markup tags to text.
Lack of tagging support seems especially weird because of all the effort that has gone into the IDML import filter. I'm really hopeful that an LED lightbulb will go off in the developers' heads, because they must be that close to supporting tagging in general.
So again, as @michalmphpoints out, we don't need to solve the "which language" problem for Serif, but I for one would really love to retire that old iMac from its production job so it can serve household files for the next 10 years! 

Yes, and yes. I had to turn back to InDesign CS6 (last version with a standalone license) today to start producing the latest iteration of a long-standing project that requires a RegEx search and replace. First pass to catch all instances of a certain numeric string and reformat it using a character style followed by a non-breaking space to attach it to the next word, then a second pass to catch just the leading instance of that string in each paragraph and reformat it with a different character style. ID has the following features that make this a 1-second task, even on the old iMac that is running it:
Fully supported and documented RegEx implementation Find and replace strings that can be stored and recalled globally Full scriptability Extensible interface to allow the script to be compiled in Java and invoked at will And all of that from software that was released nine years ago. Early CS versions could do the same.
The reason I had to use ID (and had to do it remotely, because the mid-2012 iMac is in another office) is because I can find no other software that will do what I need and bring the results into Affinity Publisher. BBEdit? Only supports text or markup for output, so the amazing RegEx "Playground" is wasted because it can't provide useful output. Microsoft Word? It would seem like an obvious choice, but support for regular expressions (which they call "Wildcards" but which was a reasonable implementation of RegEx) has eroded to the point where it has disappeared from the documentation. And, since AP doesn't seem to support tagging, either, there's no sense in writing a BBEdit text factory to attach markup tags to text.
Lack of tagging support seems especially weird because of all the effort that has gone into the IDML import filter. I'm really hopeful that an LED lightbulb will go off in the developers' heads, because they must be that close to supporting tagging in general.
So again, as @michalmphpoints out, we don't need to solve the "which language" problem for Serif, but I for one would really love to retire that old iMac from its production job so it can serve household files for the next 10 years! 

I feel you, it was the same for me.
The programming language question used to be a legitimate concern due to specialist availability, but I think it's been solved a few posts ago (recommendation for language-agnostic API).
For some reason people still find it necessary to post their preferred languages. At least the thread gets bumped, I guess.
I'm subscribed in hope that we'll get an update from Affinity about the feature, but I'm not getting my hopes up.
We had a time window at work where we could have started using - or planned for - Affinity apps in the pipeline, but that's no longer the case.
Now I'm just curious if the feature gets released, and if yes, will it'll bring some interesting stuff to the table that I could use personally.

Holy cow.
I just read 11 pages of opinions stretching back 3 years giving Serif all kinds of advice about which flavor of programming language, how proprietary (or not) that language or languages should be, etc. Tip o' the cap to all of you who have brought nuance to that part of the problem.
I have been able to accomplish some amazing tasks over the past 35 years using automation tools. If it wasn't available directly in the application, there were hooks to allow an external tool to accomplish programmatic tasks.
Given that some kind of implementation is needed, and that it involves choices, I want to step aside from that detail and state:
Some form of scripting would vault AP and its suite-mates into the professional tool arena. It's just not there without it. Some form of macro editing/creation, as with Photo, would ease the pain of text manipulation. Some form of saving find/replace expressions for reuse would make it worthwhile to use RegEx/GREP strings. I list those items from most to least difficult (in my naive understanding). In order of implementation priority, I'd reverse the list.
Surely Serif could pick off one or more items from that list and realize a huge gain in adoption (for Serif) and productivity (for users).
 

In the stock panel we list a selection of stock image providers for the convenience of our customers on the basis of it being a free service. Unfortunately in the case of Unsplash they have begun demanding license fees for their API which is the reason they have been removed.
The good news is this  only affects Unsplash, the other options of Pixbay and Pexels continue to be available.
Of course should you wish to use Unsplash images you can download directly from their website using a browser and then import into your Affinity apps by drag & drop or File -> Place, as you would with any other stock library not listed in the panel.

It took me a day to learn how to think in points and picas when I was learning typesetting on a Compugraphic machine in 1981. It properly remains the way I spec and set everything I do to this day. That includes Microsoft Word documents, where setting margins and hanging indents in points is so much easier and faster than doing the same in decimal inches. 
I would probably find metric measurements workable, but they are discouraged in the USA and so they are not a go-to. 
It doesn’t matter, though—Serif provides enough measurement systems (including yards!) to keep everyone happy, and they are all available on the fly with a single right-click.  

Off topic, but picas and points is the traditional measurement system for professional page layout in North America. It's ideal since type is already measured in points.

It's funny, there are other features I'd like such as cross references, multiple indices, and span columns, but a checkbox to turn off hyphenation for capitalized words is my #1 feature request. I'd pay for an upgrade just for this one feature.
The workarounds suggested are great and I'm using them but they're easy to forget.

Apropos Soft in soft hyphen
I really dislike that term, I much prefer the term Discretionary Hyphen. 

For sure.
For example, in another app, I decided to recreate all the technical sheets we send to clients. There's 4 pages, but only the 1st and the 2nd have different text.
So I created a document with 1 base layer for the text that stay the same, and ±25 other layers for the differents datas, named accordingly.
I just had to create a script with different options:
to export the layers' names as a variable in a text file that I completed, to memorize some other datas like the different export paths depending of the opened document (I needed different documents for different categories), and able to hide all the layers but the bottom base one, and in turn, display each layer, export the PDF with the appropriate name, hide it and display the next layer, etc. It was easy then to add new documents for translation, and modify again the script to export all the needed layers of all opened documents at once. I just need to run the script, select an option, and OK, voilà!
With this, I can easily correct typos or datas, add new informations and get new PDF.
 
I hope they thought from the start about adding scripts, since it's a really important feature.

Holy cow.
I just read 11 pages of opinions stretching back 3 years giving Serif all kinds of advice about which flavor of programming language, how proprietary (or not) that language or languages should be, etc. Tip o' the cap to all of you who have brought nuance to that part of the problem.
I have been able to accomplish some amazing tasks over the past 35 years using automation tools. If it wasn't available directly in the application, there were hooks to allow an external tool to accomplish programmatic tasks.
Given that some kind of implementation is needed, and that it involves choices, I want to step aside from that detail and state:
Some form of scripting would vault AP and its suite-mates into the professional tool arena. It's just not there without it. Some form of macro editing/creation, as with Photo, would ease the pain of text manipulation. Some form of saving find/replace expressions for reuse would make it worthwhile to use RegEx/GREP strings. I list those items from most to least difficult (in my naive understanding). In order of implementation priority, I'd reverse the list.
Surely Serif could pick off one or more items from that list and realize a huge gain in adoption (for Serif) and productivity (for users).
 

And with that answered, I searched the Publisher help for this topic, and the closest I came was the discussion of "Object Defaults." This appears to be too particular and misleading, as @Old Bruce's solution also applies to default panel values and, I presume, anything else that is a default in Publisher.
That may suggest a revision or clarification in the Help facility would be in order.
Thanks again!

After searching pretty much every thread that could be related, I've learned the following:
A default "space after" value of 12 pts leading between paragraphs appears to be an intentional choice on Serif's part. There is a school of typographers who believe that this is a good thing for long blocks of text, and I respect that. There appears to be no easy way to change the base style globally (that is, in one's local installation of Publisher) so that the "space after" value is 0 pts, or any other value but 12 pts. I accept the first two points, but want to know if the third point is true. Is there any way to change the base style so it applies globally to every new document that is opened?
Thank you for your thoughts on this matter.

If, like me, you want to have 0 (zero) points after a paragraph as the default then make a text frame and type some text. Now with the text caret in the text get the Paragraph Panel up and set the Space After to 0 (zero) points. Now go to Edit > Defaults > Synchronize from Selection and immediately go to Edit > Defaults > Save. You can use what ever Space After Paragraph size you want, it doesn't need to zero.

I'm not suggesting for a moment they shouldn't do a full and complete library of scripting functions. I'd be disappointed if it was JUST basics.
I'm simply saying a good starting point would be the fundamental functions I detailed above. I would, however be extremely disappointed if scripting was delayed because they were trying to build every obscure and little used functionality in before releasing it. Get some basic functions out early and build upon that.
Getting AP to the level of a genuine ID competitor will take years but I certainly don't want to wait that long for scripting support. We are simply no chance of changing from ID to AP without scripting - it would cripple our workflow. If we could get the fundamentals I stated above we would be half a chance to move quite early.

This is a major update in my book. I have hesitated to commit to Publisher because of my large library of InDesign CS6 files that still need tending. After seeing:
The short work that Publisher made of ingesting an IDML file; and The fact that I can now save that ingested file as a template I am blown away. THANK YOU for this. I have used ID since its initial release in the early 2000s, migrating from PageMaker. I have pushed it close to its limits, and have depended upon it for jobs small and large. I have had to freeze my MacOS version at High Sierra to accommodate it, at the expense of updating other applications.
With this capability, I can virtualize High Sierra, safely move to the latest system, and run CS6 for exports.
For fun I opened an IDML file in BBEdit. After seeing what the IDML package encompasses, I say "hats off!" to the Affinity Publisher team. Well done!

This is a major update in my book. I have hesitated to commit to Publisher because of my large library of InDesign CS6 files that still need tending. After seeing:
The short work that Publisher made of ingesting an IDML file; and The fact that I can now save that ingested file as a template I am blown away. THANK YOU for this. I have used ID since its initial release in the early 2000s, migrating from PageMaker. I have pushed it close to its limits, and have depended upon it for jobs small and large. I have had to freeze my MacOS version at High Sierra to accommodate it, at the expense of updating other applications.
With this capability, I can virtualize High Sierra, safely move to the latest system, and run CS6 for exports.
For fun I opened an IDML file in BBEdit. After seeing what the IDML package encompasses, I say "hats off!" to the Affinity Publisher team. Well done!

I have previously requested this for Designer and Photo, but accepted that pixels/points was possibly adequate for most folks' needs.
But I'm aghast that Publisher does not support Pica & Points as a measurement standard. 
Please implement this in your measurement engine! I understand that picas may not be used in Europe, but in North America it's a very useful standard.
Points alone is not enough.
And, thanks for the public beta release!

I have previously requested this for Designer and Photo, but accepted that pixels/points was possibly adequate for most folks' needs.
But I'm aghast that Publisher does not support Pica & Points as a measurement standard. 
Please implement this in your measurement engine! I understand that picas may not be used in Europe, but in North America it's a very useful standard.
Points alone is not enough.
And, thanks for the public beta release!

hey there (again),
is it, or will it be possible to import a docx-file or maybe a markdown-formatted file? that'll be awesome!
cheers and all the best
mark