Peter Werner

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.

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.

I see, fantastic, thank you! Great to be able to do this non-destructively as well.
 
But to be honest, I think this feature would be much easier to discover and also much faster to use if the Curves layer was added in the correct nesting position automatically if a mask is selected in the layers panel. Thus the workflow would be as simple as Select layer mask and press Cmd+M. Ideally, the user would even be presented with the drop down in the Curves dialog set to "Alpha" already.

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.

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.

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.

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.

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.

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.

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

Most professional publishing software actually have a counterpart for text editing that is intended for the editors in an editorial workflow, like for newspapers and magazines. For InDesign, there is InCopy, for Quark XPress there is Quark CopyDesk. Editors can write their articles while accessing paragraph and character styles and seeing the text in context of the layout, including accurate text wrap. There are also locking mechanisms so people don't overwrite each other's work. Collaboration happens either via a file server or via something like Dropbox. These programs actually make fairly decent word processing programs, though they are of course not optimized for it, hence tasks like placing images, setting margins, and other layout operations are very limited.
 
As Affinity is going to be a professional suite, I expect that at some point in the future, there will be such a software that will take what I imagine would be a text editing persona from Publisher into a separate application, intended for editors collaborating with the layout department.
 
From my perspective, I think this should be a free or at least extremely low-cost program (say, 4,99€). That way individual designers could have clients or copy writers install that program, allowing these people to work on text inside the layout before the designer then makes final formatting touches. Much better than getting new Word files every day and manually re-applying all formatting in situations where there are a lot of frequent copy changes, but work has to start on the layout.
 
It could also serve as a free viewer for Affinity file formats that would allow people who don't have Designer/Photo/Publisher to display, export and print Affinity file formats.
 
I think a system like this could have one other really important use. For instance, many Designers are in the situation that the client has to come back to them for every single copy edit. Say, you are designing a brochure for a car company, and you want every dealer to have their address and their individual prices in there. With such a copy editing/viewer program, the designer could mark the corresponding text boxes as free to edit in the copy editing software. And then every single dealer could easily print or export customized versions every time their prices change (or address). There are solutions for InDesign out there, but they usually involve complicated and expensive server-based solutions that only make sense for large enterprise workflows. If Affinity Publisher/Designer/Photo were to provide a simple solution for that, that would be a godsend for many smaller workflows.

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.

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.

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.

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.