Seneca

The developers have already announced that JavaScript is the language they are going to provide for scripting the Affinity Apps. The also said that they are going to provide an SDK written in C/C++. If anyone wants to implement another scripting language on top of that it will be able to do so without any problem. As a matter of fact, their JavaScript implementation is on top that same C/C++ SDK. So no need for language wars.

As you well know Character Styles are meant for local overrides. We already have a way to define Paragraph Styles that appear in both Character Menu and Paragraph Menu by selecting "Show in Both Panes" when defining Paragraph Styles. If we could do the same thing when defining Character Styles then that problem would be kind of solved. Unfortunately, Character Styles don't allow us to use decorations, which is a bummer, but, if memory serves me well, there was a discussion about that in the forum already. If that was possible then at least one level stacking would become possible. In a way we are half way there already. The only program that has paragraph stacking facility, if I remember it well, is VivaDesigner.

The only way to avoid duplicating styles while copying text from one document to another is as follows. Let say we have 2 documents with same style names, that differ in font size or font name, etc. and we want to copy some text from document-2 to document-1. What needs to be done is as follows: 1. Open document-2. 1. Import styles from document-1 to document-2. Any styles with the same names in document-2 will be updated to the styles in document-1. 2. Copy text from document-2 to document-1. 3. Close document-2 without saving. The copied text will not create duplicate styles. It's important to note that the text in both documents should be clean, no manual overrides. I've been using this workaround for years but I hope that this bug/misfeature will be fixed soon as this slows down my work tremendously.

I think Apple decided to buy Pixelmator and Photomator to show off its AI capabilities and M4, or future 5, or 6 processor speeds. There was a big backlash here in our forum regarding the use of AI in Affinity products. So in a way it's a good thing that the purchase of Affinity products was never on the cards (but what do I know).

This would be a very welcome addition to the search/replace capabilities of Publisher. The ability to find and replace with the contents of the clipboard has been available in inDesign for a good while now. Something similar was shown by Tim France in one of his scripts so it should not be that difficult to code.

One thing that bothers me a bit from the UX standpoint is that if you select a page or pages on a given spread, this selection is be reflected in the Properties Dialog. At the moment the Dialog defaults to spread but really it should switch to selected pages when it opens. EDIT: Sorry, this was already mentioned by @MikeTo upthread. spread.mov

I don't think this would happen. I think a lot of people would welcome the fact that one could export design elements or files into Affinity products for further processing and then send it back to Canva. Nobody would force anybody to use Canva and those who want it will have a way of doing it. This is very similar to what Affinity has done with AI. It's an opt in feature. So those who want to use Canva will have a way of sharing files with Canva and those who don't want to have anything to do with Canva will simply not use it.

Image banks will not replace EPS format saved by AI overnight. This will take years to do and will most probably remain there for a long time. What is possible though is to collaborate on OpenSource projects that do support that format very well. In fact, Inkscape comes to my mind. They even support vector patters created in Illustrator. Bringing that level of support to Designer would be a big win for Affinity. Collaborating with InkScape on this OpenSource project would allow quicker iteration and better support of the Proprietary AI format. I don't see any downsides to that but of course I can only speak form the sidelines.

I'm not sure. I think this is a very powerful feature and I for one would make extensive use of it and would be sad if this was removed. I agree, that it would be great to hear more from the Affinity team regarding this. EDIT: A number of people complained that the slug area is still not there. A bottom panel could be used as a slug and saved as a template to solve this. There is currently a bug that doesn't display crop marks properly on layouts like the one below but once fixed it could work very well.

Patrick suggested: On Mac, we would advise anyone using an Intel based Mac, to set Inference to CPU Only. Otherwise you may get unexpected results and slow behaviour. Who knows, maybe this is the cause of your crashes.

On MacOSX Ventura cancelling the Print Dialog in Publisher will bring up the Print Dialog again. The same if you OK it, the Print Dialog will show up again. This doesn't seem to happen in Designer and Photo.

I'm not sure how that will be possible in practice. The internal folds in some arrangements need to be slightly smaller than the other folds and I don't see an option to modify page sizes.

Great thanks. This is how it should have been implemented from the start. 🙂

Your document opens for me without any issues.

Yes, this is a major problem with Affinity apps. The order of the documents you open in is not guaranteed to be respected when you peruse them. Usually, when you close the frontmost document the next frontmost document will be the last tab on the right. I work on 8 opened documents at a time and it's extremely annoying to be constantly monitoring what document I find myself in when I close the frontmost doc. The community asked to maintain the order you open the documents in a number of times but so far this has not been implemented.