Peter Werner

I can't seem to find the link right now, but I recall Adobe Photoshop product manager John Nack posting about the possibility of a Linux version of Adobe Creative Suite (at the time) on his blog many years ago.
He stated that the reason why Adobe didn't do a Linux port wasn't the size of the potential market for Linux versions at all.
Their market research showed, however, that offering Linux versions would not get them a significant amount of revenue from new customers, it would instead only shift a large part of their existing customer base to a different operating system.
Serif today is in a very different position – shifting a large part of Adobe's existing customer base to Linux sounds exactly the kind of thing they might be interested in.

By default, all images are set to fit to the viewport when they are opened. For images that are smaller than the viewport, this leads to a zoom percentage greater than 100%.
 
Personally, I usually prefer images not to be enlarged as it gives a wrong impression about the pixel-level quality. It prevents checking if the file is sharp, while not giving any real benefit since enlarging them does not provide any additional information, unlike in the case of larger-than-screen images. So fitting larger files by default is fine, but I find myself routinely pressing Cmd+1 every time I open a low-res file in Photo.

I've once typeset a booklet with mathematical formulas for students in Adobe InDesign for a client. While there are plugins like InMath, they are expensive and clumsy since they rely on hacks like baseline shifts and so on. There was another plugin that can be used an external formula editor like in Word, but it turned out the formulas didn't print properly and there were incorrect characters. Not to mention that these solutions are way too expensive if you only have a one-time project.
 
Back then, I, too, found LaTeXIt! for Mac to be the best solution since it allows you to type out small snippets of LaTeX and save it out to a PDF using XeTeX (XeTeX being a key part since this allows access to OpenType fonts to customize the look to match the text in the publication) or copy and paste it into other applications. But it's not ideal since customizing the fonts, look and kerning of the formulas takes loads of boilerplate code since LaTeX was never meant for lots of customization. Not to mention every formula was basically a linked image and had to be re-built for even the smallest change.
 
I don't think actual LaTeX integration would make a lot of sense. But I do think that built-in formula editing support for Affinity Publisher ("Maths Persona"?) would be a fantastic feature. Additionally, a way to quickly type LaTeX code simply as an input method (without having LaTeX installed, the formula subset would be enough) and a way to import MathML would make it really quick and flexible to create math-heavy documents.
 
It's not just a feature that benefits the few people who are professionally printing math-heavy publications. I'm certain that such a feature would position Affinity Publisher as a really attractive solution for teachers and educators for creating work sheets and the like. This demographic is currently mostly on Word because something like InDesign is just way out of the price range and learning curve that these people would consider. But at $49, I think it would be a no-brainer for every teacher. All it would probably take is a decent math typesetting feature for Publisher and a non-destructive graph plotting tool for Designer. The expressions parser is already there as part of the text input fields…

A designer specializing in layout work who doesn't know or care about separations is an expensive accident waiting to happen. Black RGB text that prints blurry, or black text at 7pt that's not set to overprint, or images with an RGB black background which auto-separates into rich black that are placed inside a CMYK K-only black rectangle in the hope of it looking seamless – the client is not going to be happy.
I routinely check anything that goes to print in separations preview, and one out of three times, I spot a last-minute problem that needs to be fixed. Partly this is because of idiosyncrasies of InDesign's quirky transparency flattener, but still, it's an important step in any software that helps you prevent costly situations like re-printing 500 000 copies of a document because you missed a very small but very stupid problem.
While in my opinion not absolutely essential for a 1.0 release (a software like Acrobat can be used to check the PDFs if need be), it's definitely far from just a "nice to have" feature.

You could just enable the write protection option in Finder/Explorer for a regular publisher file that you want to use as a template, then it won't save over the original by accident.

I think it is worth mentioning that now with that Publisher has shipped with Studio Link enabled, you can just go to the Photo persona and use the Channels panel to check your separations. For some reason, page/spread borders disappear, but it's still a viable workaround. You need Affinity Photo installed in order for this to work.

@mac_heibu, I by no means meant to imply you are not professional, sorry if it came across that way.
Seems like we essentially agree anyway  
I've actually had issues with Acrobat's separations preview not being accurate in the past. And as many designers are looking at Affinity as a way to get them out of an Adobe subscription, I'm sure that eliminating that last step at some point in the future would certainly be welcomed by many.
 

A designer specializing in layout work who doesn't know or care about separations is an expensive accident waiting to happen. Black RGB text that prints blurry, or black text at 7pt that's not set to overprint, or images with an RGB black background which auto-separates into rich black that are placed inside a CMYK K-only black rectangle in the hope of it looking seamless – the client is not going to be happy.
I routinely check anything that goes to print in separations preview, and one out of three times, I spot a last-minute problem that needs to be fixed. Partly this is because of idiosyncrasies of InDesign's quirky transparency flattener, but still, it's an important step in any software that helps you prevent costly situations like re-printing 500 000 copies of a document because you missed a very small but very stupid problem.
While in my opinion not absolutely essential for a 1.0 release (a software like Acrobat can be used to check the PDFs if need be), it's definitely far from just a "nice to have" feature.

These effects should still export as raster images clipped inside of the corresponding paths and not raster images only, so there is clearly something wrong here beyond just the resolution of the effects. Whether this is by design or a bug I cannot say.

Except it would be cool if that grid also allowed for subdivisions in the other direction, i.e. not just columns like InDesign, but also rows.

Running a web server for an API (or a web browser or Flash Player for dialog boxes) is exactly the same type of bloat that we all criticize Adobe for. They, too, are running at least one local node.js web server in the background even if none of their applications are active. You may have noticed it because it occasionally hangs, crashes or blocks system shutdown.
Scripting isn't that performant in the first place, and running single command through a full-blown set of script interpreter, API in that scripting language wrapping and parsing the HTTP communication, HTTP server, system TCP/IP stack and what not is such a colossal waste of resources, not to mention it opens up the entire system to security vulnerabilities.
If you really have a compelling case why you absolutely must automate Affinity applications over an HTTP API, you could easily implement the relevant parts of such an API yourself, either via a native C++ plugin, or even easier, with a Python script and Flask (a combination which by the way could probably replace InDesign Server with a desktop version of Publisher for quite a few use cases).
This is by no means about what is trending, but what makes the moste sense in terms of providing an efficient, robust, powerful, extensible and future-proof scripting workflow. Besides, Python has been a staple of application scripting in the VFX industry (among others) for decades, and for a reason. This is by no means just a "trend" and there is no indication whatsoever that it will go away any time soon. As an established solution, there are a lot of companies invested in it so continued development is pretty much guaranteed for the foreseeable future.
Lua is indeed great for smaller quick and easy scripts and easy to integrate in a C++ program, but not that suitable for more complex solutions (hello, Adobe Lightroom Classic mess) and its object-oriented language features are lacking compared to Python. C is not even a scripting language and does not scale too well, which is why it has been replaced by C++ as the language of choice for larger native software projects decades ago. It is also not true that the complexity of implementing one solution in different languages is always the same – it is true for very, very simple code, but as solutions become more complex, some languages, and their ecosystems, are significantly more powerful than others. As someone who has worked with both Python and VBScript I can tell you that there are some things that would be a nightmare to write in VBScript and a five minute exercise in Python.
We don't need a hundred haphazardly integrated scripting solutions so everyone can avoid spending 30 minutes to learn a few basic new syntax rules, but one great scripting solution that is well thought-out, seamlessly integrated, simple and easy for basic tasks but powerful enough for the most complex requirements that arise, and interfaces well with the outside world (AppleScript/COM, network/HTTP APIs, third party libraries and applications, native code etc.).

I'm a designer in China, and Affinity products are gaining popularity here because of its low price and easy-to-use tools. It would be even nicer if we can get better typesetting results for CJK text, such as dealing with CJK punctuations properly (avoid line start and end while placing punctuations (标点避头尾), as well as aligning CJK characters in grids due to their block-y nature, see example 1), and having true up-to-down, right-to-left vertical text (instead of rotating text and/or squeezing multiline text, see example 2).
Surely I know this is going to be a tough work to figure out all the rules when typesetting CJK text and implementing them, but it would pay back greatly by gaining even more users in eastern Asia (I suppose).
 
Examples:
1.

A paragraph of Chinese text in Affinity Publisher. Notice the square closing quotation mark (up) and full-width comma (down) are not directly after their contents.

The same paragraph in Adobe InDesign. The line feed points and punctuation glyph widths are modified to fit the punctuations in line.
2.

A paragraph of vertical text in Adobe InDesign.

The current workaround to create vertical text in Affinity softwares. Notice the misplaced punctuations and latin letters.
 
To be clear, I'm using Adobe InDesign only for comparison. I'm not saying that it's perfect. In fact, it's the inconsistency of shortcuts and gestures among Adobe softwares that drew me to the Affinity family. Affinity softwares are fantasic, but it can be more fantastic if we get these features.
 
The source of text used in examples above, and also a great reference for Chinese typesetting:
https://thetype.com/2017/11/13290/ The greatest myth in Chinese typesetting: hanging punctuation - Type is Beautiful (Chinese webpage)

I wholeheartedly agree, but someone on the Serif team commented on the forums here a few months ago that this won't be in the initial release and will come later. It's definitely one of the features I'm looking forward to the most.

I've run into a Publisher crash yesterday that somehow involved Apple's JavaScriptCore library – I do wonder if that's an indication of something coming up 
That being said, I'm still hoping for Python instead of or at least in addition to JavaScript. Having written extensions for different software with both languages, I found that writing extensions in Python was always quick, easy, efficient and even fun, and there are tons of great third party libraries available, whereas any kind of JavaScript extensions, particularly for Adobe programs, have consistently been a royal pain. Getting good integration into the user interface of the host applications (like adding custom menu commands or panels) has never been very robust with any JavaScript-based extensions in any application I have come in contact with. And it's so easy to learn the basics of Python that I believe anyone with JavaScript experience would be able to get started in no time.
I realize that's a rather controversial point and everybody has their own personal preference, but I do encourage everyone to have a look at a few basic Python tutorials and form their own opinion.

I've run into a Publisher crash yesterday that somehow involved Apple's JavaScriptCore library – I do wonder if that's an indication of something coming up 
That being said, I'm still hoping for Python instead of or at least in addition to JavaScript. Having written extensions for different software with both languages, I found that writing extensions in Python was always quick, easy, efficient and even fun, and there are tons of great third party libraries available, whereas any kind of JavaScript extensions, particularly for Adobe programs, have consistently been a royal pain. Getting good integration into the user interface of the host applications (like adding custom menu commands or panels) has never been very robust with any JavaScript-based extensions in any application I have come in contact with. And it's so easy to learn the basics of Python that I believe anyone with JavaScript experience would be able to get started in no time.
I realize that's a rather controversial point and everybody has their own personal preference, but I do encourage everyone to have a look at a few basic Python tutorials and form their own opinion.

The full Resolve control panel is $30k, but there are cheaper and less space-consuming panels, like the ones from Tangent, or Blackmagic Design's own recently released Mini and Micro panels, which come in at roughly $3000 and $1000 respectively if I recall correctly.
 
They are all centered around trackballs for a traditional three-way Lift/Gamma/Gain color corrector, which Affinity currently lacks, but it would be a very useful feature even without a control panel, so it would be worth adding anyway.
 
Other than that, in addition to MIDI, DMX (a protocol used to control theatrical lighting) might also be worth looking into.

By default, all images are set to fit to the viewport when they are opened. For images that are smaller than the viewport, this leads to a zoom percentage greater than 100%.
 
Personally, I usually prefer images not to be enlarged as it gives a wrong impression about the pixel-level quality. It prevents checking if the file is sharp, while not giving any real benefit since enlarging them does not provide any additional information, unlike in the case of larger-than-screen images. So fitting larger files by default is fine, but I find myself routinely pressing Cmd+1 every time I open a low-res file in Photo.

By default, all images are set to fit to the viewport when they are opened. For images that are smaller than the viewport, this leads to a zoom percentage greater than 100%.
 
Personally, I usually prefer images not to be enlarged as it gives a wrong impression about the pixel-level quality. It prevents checking if the file is sharp, while not giving any real benefit since enlarging them does not provide any additional information, unlike in the case of larger-than-screen images. So fitting larger files by default is fine, but I find myself routinely pressing Cmd+1 every time I open a low-res file in Photo.

Inkscape is by no means representative of what Python scripting looks like when it is well integrated. Inkscape's Python seems like an extremely crude API that requires you to mess with some SVG DOM, write a bunch of superfluous boilerplate and integrate a bunch of third party libraries to do anything useful. That's by no means the fault of the programming language.
I wouldn't want to use that, either.
See this example of what a basic script for Illustrator in Python (using COM due to lack of native Python bindings) looks like. Not very different from JavaScript, really.
Nothing of the sort would be necessary with a proper embedded Python interpreter. You could of course mess with third party packages if you wanted to.
As an example, I'll attach a simple graphic that I generated with Python (using the interpreter that came pre-installed with OS X). The script can render to PNG using PIL (as attached) or write an SVG for use in Designer or Illustrator. Took me a lot less time than doing something like that as a script compared to doing it by hand. I can use any gradient for colors, use an image texture to modulate the size, birth or position randomization of the particles, color the connection lines, and much more. The result can be manipulated in Designer as if it was created directly with its drawing tools.
@MikeW:
Nothing can be done with a programming language per se except do maths and data manipulation. Scripting always means "extending" the language with an object model. User interfaces (whether on desktop or mobile) are no different than documents, layers, text frames and cat objects in that respect. Some scripting APIs just skip the UI part (or, cough, rely on Flash or HTML), which obviously leads to a rather underwhelming user experience.

Agreed, masks are still quite quirky. I have to admit that as much as I love the software, I was quite surprised back when Photo went from Beta to Release without addressing these.
The Dodge/Burn tools seem to do nothing (or rather, happily operates on the blank RGB data, leaving Alpha alone), the brush tool ignores blend modes, adding adjustments with a mask selected doesn't add them to the mask automatically and requires dragging them into the right place manually and selecting Alpha from the drop-down manually (both things take extra clicks and are almost impossible to discover for a new user/Photoshop convert without research), while some filters work because they affect both RGB and Alpha (eg. Motion Blur), others simply seemingly do nothing since there is no RGB data to operate on instead of treating Alpha like RGB like in Photoshop, layers/adjustments nested into Mask layers sometimes seem to not be displayed in the layers panel (might be a display limit for nesting depth), and even though there can be multiple masks affecting one layer, there is no way to combine them in Pathfinder-type operations since the layers panel only offers the regular layer blend modes that are useless in a mask context. The Photo team also has unfortunately copied Photoshop's nonsensical 1990ies limitation that features like Color Range selection are destructive commands outputting a selection and HSL qualifiers are limited to the HSL dialog box instead of working like non-destructive adjustment layers that can be used as mask layers for any type of layer or adjustment (or in case of the latter at least allowing them to be used to generate selections).
But while I hope we'll see some workflow, feature and usability improvements in these areas in the future, for now, the most essential features are there at least. And while they're far from intuitive, they are at least usable and have the potential to be really powerful. Already, we can do things that are impossible in Photoshop, such as applying non-destructive adjustments to masks, using multiple masks on a single layer and so on.
By the way, in addition to any Channel Mixer workarounds, Grayscale layers can be converted to masks by selecting Layer > Rasterize to Mask, and the reverse can be done by selecting a Mask layer, right-clicking the "Mask Alpha" channel in the Channels studio panel and selecting "Create Grayscale Layer".

You can double click each of the resize handles (horizontal and vertical ones, not the corner ones for some reason) of a text frame to fit its bounds to its contents on that particular axis.
I think it is supposed to work for picture frames as well, but it seems broken/buggy at the moment. The frame snaps to incorrect places (tested with an image dragged in from the Stock panel).

Except it would be cool if that grid also allowed for subdivisions in the other direction, i.e. not just columns like InDesign, but also rows.

@Aammppaa Thanks for the tip with the rotated grids for angled layouts, I'll have to look into those options!
However, what I'm looking for in addition to these settings is a layout grid that allows me to set up guides for text columns and image positioning, such as six columns with an x mm gutter, similar to what InDesign has. It has to work in addition to the regular document grid. Just like the "Margins and Columns" settings in InDesign, but with the additional option to do the same thing also with horizontal divisions, not just vertical ones.
For instance, it would be common for a page layout to have 7 grid columns for a 3-column page. Then text frames, sidebars, image descriptions and so on would be created spanning one or more columns of the layout grid. This can be done manually with guides on master pages of course, but adjustments are rather time consuming.
 

Except it would be cool if that grid also allowed for subdivisions in the other direction, i.e. not just columns like InDesign, but also rows.

Except it would be cool if that grid also allowed for subdivisions in the other direction, i.e. not just columns like InDesign, but also rows.