RM f/g

I also noticed, by the way, that an object/layer selected in the layers panel can be deleted without problem or warning.
I would prefer locked layers to be truly locked, so they cannot be deleted without first being unlocked.
Falls within the same category as the original post, I presume.

Just tried X4. Overprinting works well.

Even with the default print preset, which has "Black overprint" activated in its Export > More options AND with additionally using a 100 K overprinting swatch none of the blacks do overprint.
Screenshot AfPub, the middle line has overprinting K assigned:

Export as PDF 1.7 with default preset for print (has ticked "overprint" export option):
None of the 2 blacks do overprint. (K channel disabled in this screenshot) :

 
Whereas it works with PDF/X-3, both with ticked and unticked overprint export option as expected.
Black Overprint ticked (= on): both black swatches do overprint:

Black Overprint off (= unticked): Only the global overprinting black swatch does overprint:

 

Yes, please!
A measure tool of some kind would be welcome as well.
A lot of my work is published at a fixed scale. Measuring a ruler included in the photo and then scaling the dimensions of the photo down to the desired (calculated) size is very common in my workl I can use a rectangular marquee combined with the info panel to take a measurement, but then often I have to rotate the ruler that is in the photo first to set it exactly horizontal. A measure tool is a lot faster.

Also, on this subject, I should add that, for consistency and usability, objects should already snap to their originals when doing Option+Drag duplication operations, which is already their behaviour when performing Command+drag operations.
And I've just realised, while looking at the status bar messages, that apparently Command is [now? Since v.1.6? Since… ever?] the default modifier for duplicating and Option the default modifier for ignoring snapping. This, per Apple's Human Interface Guidelines is completely unacceptable and inconsistent with the behaviour in the Finder and pretty much all macOS apps.
When you click and drag an icon (or an image or block of text in any text editor, like TextEdit or Pages, or any object in Keynote) while pressing Option, you will always get a duplicate, and when you click and drag the same icon while pressing Command, in a window – or the desktop – with “snap to grid” activated, the Finder will ignore the grid (and so will Keynote regarding snapping, if you're dealing with objects). WHY should Affinity behave in such a blatantly inconsistent way with the rest of macOS? It started out as a macOS app, first and foremost, and if you really must have it be consistent across OSes, at least allow the users some degree of finer control as to how modifier keys affect its operation.
You don't want to become the new Adobe (or, worse even, outdo them) when it comes to OS-app UX inconsistency, trust me on that one. Designers do not take that lightly.

Affinity Publisher is a excellent, stable program. I started using it two weeks ago and powered out a 118 page cookbook - one of the more complex books that can be made. Publisher handled it like a champ.
There are some things that would make it better for serious users.
A pre-press function needs to be available. When exporting, Publisher will warn of a text overflow but no indication of where to find it. That involves a lot of scrolling. A page number at the minimum would be nice.
Sending files to the publisher will sometimes kick back the an image is below 300 DPI. That's a lot of looking to find it. The Resource Manager is "helpful" in a small way. It would be nice to be able to sort the DPI list so one doesn't have to look through the whole thing. Something better would be to test and trap low res graphics and at least raise a flag.
Publisher is new and it's a great version 1. I realize this is the start and there's plans for more and better things down the road. I ask the above be considered.

In a document I have two objects, one of which is locked in the layers panel and cannot be moved. As is to be expected.
When I select both objects (in the layers panel), then apply an alignment, the locked object may move, depending on the applied alignment.
The same happens in Publisher.
Not exactly shocking, but not how I think it should be.
 

I can see that there has been mention of this before, but I would like to add my support to the idea of Affinity Photo using the XMP sidecar file for a couple of reasons:
Firstly, IPTC data added to the RAW file is not transferred to the converted tif file as it is stored on the XMP which Affinity Photo doesn't read. This makes for a more complicated workflow to marry up the IPTC data on both RAW and tif files.
Secondly, if the changes made to image by Affinity Photo were stored in the XMP (or even if this were not possible a seperate, Affinity Photo specific sidecar file), this would eliminate the need for a unique Affinity Photo file type, which as far I can see is not recognised by other imaging software. This would mean that (for example), a 16 bit tif could be worked on and simply saved as a 16 bit tif (with all the changes), rather than either having to save it as an Affinity File or exporting it individually as a tif file. This would speed up the workflow as the image being procesed could simply be closed, generating an option to save changes. A batch process could then be run on any number of images later, which would export them to 8 bit files.
Alternatively, provide a save option that simply saves the tif in its updated state and forget about recording the changes made to the file, as quite honestly in most cases you really don't need to preserve all the steps, unless it was a particularly complicated amount of processing. I never for example save an image as a PSD file in photoshop. If I ever revisit an image, I'll start again, but this has almost never happened. There would still be the option to save as an Affinity File for those that require it.
 
Anyway - just a couple of suggestions as I really want this product to work well and replace Photoshop!

Sorry if this has been raised before.
The default setting for ruler measurements in both Photo and Designer is pixels, presumably because the majority use that. However I mainly work in cms and it drives me round the bend have to change the setting each time I open a file.
Please could a future update include the ability to set your own default measurement unit in Preferences?

Part of my work is in the archaeological field. Drawings of finds are 99.9% drawn in ink on paper, scanned and eventually saved as 1-bit, 1200 ppi tiff.
Placed in books, magazines these drawings should output to 1200 ppi, 100% black, high res images. No downsampling, no halftone screening.
Another disappointment.

Exporting files as 1-bit tiff files would do for me, I presume.
Part of my work is in the archaeological field. Drawings of finds are 99.9% drawn in ink on paper, scanned and eventually saved as 1-bit, 1200 ppi tiff.
In Photoshop work on these scans is done in greyscale mode as possibilities in bitmap mode are ever so limited. Then converted to 1-bit and saved. So working on files in APhoto in greyscale mode and exporting the finished image as 1-bit tiff would do for me, I presume.
 

Part of my work is in the archaeological field. Drawings of finds are 99.9% drawn in ink on paper, scanned and eventually saved as 1-bit, 1200 ppi tiff.
Placed in books, magazines these drawings should output to 1200 ppi, 100% black, high res images. No downsampling, no halftone screening.
Another disappointment.

Part of my work is in the archaeological field. Drawings of finds are 99.9% drawn in ink on paper, scanned and eventually saved as 1-bit, 1200 ppi tiff.
Placed in books, magazines these drawings should output to 1200 ppi, 100% black, high res images. No downsampling, no halftone screening.
Another disappointment.

And to further elaborate a bit, this is how I'd like 1-bit stuff to go in Publisher (as I'm sure others have noted also):
1) When placing a 1-bit image into the document, Publisher should render it correctly, making the white parts of the image transparent. 
2) It should be possible to colorize the bitmap image with any single (spot) color (doesn't make any sense to keep them just black, of course).
3) When exporting PDFs, it should be possible to control 1-bit resampling independently.
4) The user should be able to trust the exported pdf to have the correct color values for the bitmap, with no unexpected conversions.
I don't know if this would require just as big technical changes under the hood as full bitmap support in Photo. Probably it would.

Well, I'll unfortunately have to be honest here too: this drops the Affinity suite out of the professional league, at least for now. I wish this information had been public earlier, I would have looked elsewhere right away. But a missing feature is not exactly a selling point, so I can understand the silence.
 
I can't use these apps in my ordinary workflow in their current state, and learning now that they will never work is a pretty big bummer indeed. I have bought the entire suite, after all. Feels like buying a fantastic new sportscar that's more pretty and aerodynamic than the competition, with nice upholstery and all, only to learn that one of the wheels is missing and will not be added in a later update. Now I need to keep riding my old Lada CS5. It gets me wherever I need to go, eventually. Not without technical problems of its own, but it works. Adobe of course only offers pricey taxi services nowadays.
 
1-bit export would be a good compromise. However that is not enough by itself, you'd have to be able to export PDFs from Publisher without downsampling the 1-bit image to 300 dpi, since that quite simply negates the advantages of using 1-bit in the first place. One resolution setting for an entire DTP document doesn't really make sense in many scenarios. 300 ppi for CMYK images, 1200 for line drawings.
 
And since there's always somebody wondering why 1-bit would be a big deal (Who in their right minds would ever want files with no possible color shades?): 
1-bit is a technical requirement when using images (mostly line drawings, like in comic books or logos) in many specialized print jobs. It's also used in a lot of product packaging stuff that's not printed in CMYK but as one or two spot colors. 
Say you're designing a CD or DVD label (which is what I often do) and you want to print a one-color line drawing that is too detailed to vectorize, and you want it to be printed straight on the silver surface of the disc without a white base disc colo (which is what you usually find hidden underneath the prints of disc labels). You can't use CMYK colors, because that's three colors more than you need, so you pick one Pantone spot color to print with. Using a 1-bit image that has been well prepared from a high resolution original you can have the printed result appear just as crisp as a vector drawing would. The image can be 1200 ppi (say 15000 x 15000 pixels, or something) without any problems. The file sizes aren't that big either, because there's just one bit of data to save per pixel. This is old technology, for sure. But it will continue to be relevant as long as physical products are made by applying ink to paper with various different printing methods.
If I design a newspaper ad for a client, why would I be ok with having the client's crisp one-color line art logo turned into 200 dpi mush on cheap paper stock when it could appear as sharp as the text? If I now design a CD cover with Publisher or Designer and send it to the CD manufacturer, their printers will send the file back to me right away with a note saying "please fix anti-aliased barcode". They are very strict about this stuff. Same goes for one-color T-shirt designs – "That's a very nice looking mockup you have there, now please send us the high-resolution final version". If you only ever do CMYK stuff, you'll never even realize that an important piece of the DTP publisher's toolkit is missing. But even then 1-bit has its uses. Illustrators often use 1-bit patterns for texturing vector art, for example, since they can be used for that fake old-timey comic book dithering or distressing patterns, for example.
 
If you can't produce files that your printer can work with, you need to change software. This, of course, is only a problem to people like me who have to struggle to shell out the 700 euros or whatever it costs nowadays to get a year of Photoshop + Illustrator + InDesign. It's not Affinity's or Adobe's fault that I'm just a poor freelancer, stuck with ancient pay-once-use-forever software. I'd much rather get paid for work than pay to work. It's important to note that Serif has no responsibility to cater to my personal needs, and I'm in no position to make demands. I just feel that the product is crippled in a fundamental way, which is frustrating, because Affinity gets so much else right.
Long rant, sorry about that. And like I've said before, Affinity apps are fantastic for their price, Serif is a top-notch software company, and that's before even considering what incredile feats the iPad versions of these apps are. I wish Serif the best of luck, things are looking very promising for the company now indeed. 
I just hope the sportscar gets that missing wheel at some point. Even a battered old spare fished out of somebody's trunk would do. It's a tow truck race for now.
 
Ps. The "Unrivalled compatibility" part of Affinity's sales pitch sounds quite hyperbolic for now, all things considered.

I'll be honest here - we will never implement 1bit document support..
However, we would be happy to implement support for *exporting* 1bit TIFF etc. - would that be enough?
Thanks,
A

Ok here it is as request :-)
 
1-bit bitmaps are used as line art (printed cartoons, illustrations), in silk screen printing and copydot printing systems. They also can (should) be used in coloured comics, where colour plates are overprinted with 1-bit black key colour. Possibly there are other technical purposes also (please list them in this thread!) There is not many apps that support 1-bit but for these uses 1-bit is crucial. 1-bit ensures that black image is NOT rasterized, resulting fuzzy outlines.
 
Technically 1-bit colour space should be easy feat. You can convert greyscale image to 2 tones (b & w) by thresholding image where light areas convert to white and darker to black.
 
Threshold should be adjustable so you can select how black or how white image is. (Scanners can scan directly to 1-bit but I think it is much better scan to greyscale and set the threshold manually.)
 
Alternative to thresholding is dithered image – that is, using something like grain mask or stochastic raster or Atkinson dithering to build the greytones. I am not sure that is so much needed as it is just a special effect (imho). Besides, there is excellent HyperDither app available.
 
There are some angles that are worth considering. Colour images are best at about 300 dpi when printed. 1-bit images display jaggies in that low resolution, optimum res is 1200-2400 dpi. Ideally 1-bit pixels would map 1-1 to device pixels but above 1200 dpi that is academic.
 
Details are not needed in that high resolution range, meaning that true 1 pixel resolution is not needed. Resolution is needed for avoiding jaggies, making lines and shapes smooth and clean. That also means that you can upsample image to smooth jaggies out. It is perfectly ok (even when not really hi-fi) to take 300 dpi greyscale image upsample it to 1200 and convert to 1-bit. In photoshop you can upsample in convert dialog (doing 300>1200 AND 8-bit to 1-bit) but I think Photoshop did it wrong and resulted jaggies. I do not know if they have corrected that bug (I use PS CS5). I hope AP would upsample and convert at one go and do it right.
 
There are some massage you can do to makes 1-bit appearance better. You can play with local contrast to make darker parts lighter so there will be more meaningful black and white areas in image. You can do it manually, or you can use filter (I think high-pass filter is used here?) I am hoping Affinity team would find some quick and easy slider here to apply in convert dialog to reveal more detail in final 1-bit image.
 
Tools: there is not much need for any special tools. (Or is there?) You can paint pixels black or white and that is it.
 
One simple effect/usage mentioned also in Affinity forum is that 1-bit image is placed in page layout app and coloured with front and back colour tools.
 
Last, you might want to consider comix artists' work flow. Old school draw black&white, scan b&w original (1200 dpi) and hand a copy to colour artist for colouring. Colouring is done to separate layer (well, sometimes physical "layer" with brush and paint). Coloured version is set in place in page layout and higher res lineart version is set in register with it and overprinted. Should colour image be CMYK? Or would it better be CMY, resulting brighter colours and less ink coverage, considering there is still black key 1200 dpi image being overprinted? How do you do CMY separation? Also, there are artists that draw with colours so that final artwork is coloured physical art board, and the either take the easy way out and do normal 300 dpi art production, OR filter out the 1200 dpi black key from full colour scanned original (not easy process..). Possibly Affinity can troubleshoot this process to simple and easy colour sep system for comix artists.

Thanks for the tip, Walt. I didn't even know is was possible to find by name.
To be honest: I hadn't noticed the search box and recent glyphs yet. Would expect them to be in the top section of the panel.
The idea to show glyphs in more human categories isn't mine. It's what my beloved InDesign already does.

An ‘ink trap’, that little wedge.

I was invited to a pre-release showcase of InDesign, and remember being blown away by what they said it could do, compared to XPress 3.3. Text layers, improved typography, transparency handling, native PDF export -- so many things that would improve our workflow. (Foreign hyphenation at no extra cost!)  I can't remember if the release lived up to it on day 1, though. 
 
If they already have a PDF rendering library to use, I can't understand why implementing it is such a 'complex problem'. But of course code is never straightforward.
Affinity seems to import EPS and SVG vector files perfectly, outlining the fonts automatically at import. For my needs, that's a workable solution, though not for everyone.

That’s why I posted this suggestion …  
I want to push this topic because it is VERY essential for lots of people.

Scripts can really speed up the process.
Working with large bodies of text, the first thing I do after importing text (in InDesign) is run a script which deals with a lot of sloppy typing. It searches and replaces for example double spaces, double tabs, tab + space, carriage return + tab, tab + carriage return, carriage return + space, space + carriage return, space + ")", "(" + space.
About 40–50 find/replace actions done in a seconds. Imagine having to perform those one by one yourself.

There are two points here:
Firstly, I'm seeing errors in placed PDFs even when I have all the necessary fonts installed. 
Secondly, PDFs can be placed correctly in InDesign, Illustrator, XPress, Apple Pages, MS Word, etc etc, even if the correct fonts are not installed on your system.
 
Affinity's ability to turn PDFs into editable content is welcome, but the ability to place a PDF on a page as an 'image', accurately,  is paramount to a DTP app. 

Hello, is there any function in Publisher that emulates InDesign's "Indent to here" character? I have found the function to be useful in formatting lists but can't find anything similar in Publisher.

In case of a pdf, what COMMAND + I  in the finder shows, is not what the document actually is.
This screenshot attached gives us the information of a pdf document sized A4, containing text, vector drawings and images of 300 dpi.
In case of an image, finder info shows the correct resolution. In case of a pdf, it's allways a resolution more or less like the one shown in the screenshot. Therefore I presume it's the size of the icon that's given.
I think the best way is to open the pdf and examine it in acrobat (for example) if you want to be sure about the correct dimensions.