lacerto

Note that you could export PDF/X-3 or PDF/X-4 based Grayscale PDF also from Affinity apps, but you need to have a true grayscale print profile installed on the system (I am not sure but on macOS you might have Generic Gray inherently available [UPDATE: Checked, and Generic Gray Profile is inherent on macOS, but is not available whenever using PDF/X-based method]; on Windows [UPDATE: and on macOS, too] you would need to fetch one from the Internet, or have one that comes with QuarkXP or Adobe available), since the only grayscale profile that comes with Affinity apps (Greyscale D50) is basically a display (Gamma) color profile and not selectable when you have a CMYK or Gray/8 document color mode and convert to Grayscale, and use PDF/X-based export method:
 
If you leave the profile empty (or do not have anything available), all the blacks defined above would be converted to four-color black and have Affinity app default U.S. Web Coated v2 marked as the output intent profile. If you do define a true grayscale color profile as output intent, RGB 0,0,0 and B:0 (Grayscale 0) will be output in ICC-dependent 100% Gray (CalGray/ICCBasedGray), but K100 will have something like a 92% value.
See below a PDF/X-3 with no explicit press-specific grayscale output intent (U.S. Web Coated v2 auto-assigned):
pdfx3_gray_from_cmyk_noexplicit_output_intent.pdf
...and a version where a true grayscale output intent is defined:
pdfx3_gray_from_cmyk_quark_genericgray_output_intent.pdf
UPDATE: The same applies to PDF/X-4 production (and in PDF/X-1a only CMYK color mode is available).
If you do not have to use PDF/X-based export method, but force the Grey color space, the default Greyscale D50 would be available, but then, too, K100 values would have non-100% gray values. So whenever forcing grayscale output, you need to have native color values (text and shapes) defined either in RGB or Grayscale, not CMYK.
There might be point in checking whether the printer truly needs PDF/X-based output in grayscale, or whether they just meant K-only output (but accept any regular non-PDF/X based CMYK-based output, as long as CMY plates are empty).
UPDATE: And if they just meant K-only, then the correct method to produce such PDFs is to choose CMYK document color mode and export to CMYK, and make sure that all native objects have K-only color definitions. There are plenty of other considerations that need to be checked when producing press PDFs from within Affinity apps, so the issues related to grayscale are only one of the concerns (but one of the most frequently experienced, and confusing, probably much because the very different K/Grayscale approach/policy used in Adobe apps within CMYK/press-related production).
In this context, paying Adobe for Acrobat Pro -- still also available as a 32-bit app on a perpetual license, though I am not sure how it is made to be operable on modern macs -- is not money wasted. pdfToolbox by callas software would be an alternative (still more expensive than Acrobat Pro). Free Packzview is not a prepress tool but is useful for decent preflight (it appears to be generally available only for professional use, though).

You cannot produce grayscale (8-bit) PDF/X-based PDFs using Affinity apps. All forms of color definitions (RGB, Grayscale, CMYK) will be converted to CMYK disregarding the target color mode selected at export time, whenever PDF/X-based export method is used. 
Technically PDF/X-3 and PDF/X-4 would allow ICC-based gray to be exported, and this is what happens if you do this from e.g. InDesign. But when done in Affinity apps, your definitions of gray and black will always be converted to rich black (four-color black).
You can produce grayscale PDFs based on Gray/8 document, but then you need to use non-PDF/X-based export method and explicitly export to Grayscale (and define your black/gray either using Grayscale or RGB color model; K100 will basically be converted to RGB and then presented as a converted CMYK value).
If your printer requires a PDF/X-based print PDF, you need to switch the document color mode to CMYK and then specify your blacks and grays using CMYK color model, and K-only values. The PDF output will be basically CMYK, with CMY 0 and with K-only values. Grayscale images that you place, will by default have "K-Only" button (available in context toolbar) applied, and will be exported as grayscale images. 

You cannot produce grayscale (8-bit) PDF/X-based PDFs using Affinity apps. All forms of color definitions (RGB, Grayscale, CMYK) will be converted to CMYK disregarding the target color mode selected at export time, whenever PDF/X-based export method is used. 
Technically PDF/X-3 and PDF/X-4 would allow ICC-based gray to be exported, and this is what happens if you do this from e.g. InDesign. But when done in Affinity apps, your definitions of gray and black will always be converted to rich black (four-color black).
You can produce grayscale PDFs based on Gray/8 document, but then you need to use non-PDF/X-based export method and explicitly export to Grayscale (and define your black/gray either using Grayscale or RGB color model; K100 will basically be converted to RGB and then presented as a converted CMYK value).
If your printer requires a PDF/X-based print PDF, you need to switch the document color mode to CMYK and then specify your blacks and grays using CMYK color model, and K-only values. The PDF output will be basically CMYK, with CMY 0 and with K-only values. Grayscale images that you place, will by default have "K-Only" button (available in context toolbar) applied, and will be exported as grayscale images. 

This looks like a bug...
With the Layer (Capital L) selected, exporting to SVG results in the following output when Area is set to:
Whole Document - Some areas will be rasterised
Selection Area - Some areas will be rasterised
Selection Only - Some areas will be rasterised
With the layers (Small L) selected, exporting to SVG results in the following output when Area is set to:
Whole Document - Some areas will be rasterised
Selection Area - Some areas will be rasterised
Selection Only - Nothing will be rasterised
While this means that selecting all the layers (Small L), with Area set to Selection Only will export @BioWeb's file without rasterisation, it will at the same time strip the Blend Modes since they're not supported...

Blurry SVG.mp4  

Ok thank you Lacerto.  

Hi @Ben in Texas,
In lack of GREP styles in Publisher, you can manually use RegEx in Find Replace and either of these two search criteria:
\<(\s?(\S+)){2}$ or
.\S+?$ and then have "No break" as formatting in Replace field, to force at least two words in the last line.
There was once a longish discussion on the forum of usefulness of this kind of feature (if it could be applied automatically). as there is no paragraph composer in Affinity Publisher that could balance problems resulted from automatically applying this kind of a rule.
Here is a clip that demonstrates the difference of the two RegEx clauses (the latter accepts a hyphenated word as a word on the next line, the former requires two complete words; there was a mistake in the original post). The clip also demonstrates the benefit of having a paragraph composer calculating dynamically changed word wrapping (as far as I know, only available in Adobe apps):

Single_vs_paragraph_composer.mp4  As mentioned, the feature cannot be applied as a paragraph style (in Affinity Publisher), but with the improved Find Change it can be applied selectively to specific scope and confirmed one-by-one, so potentially useful, and at least as an exposer of runts.

I once wished an option that would either require input focus before performing mouse-wheel based value adjustment, or alternatively, e.g. 500ms delay within a certain hover delta tolerance that would be enough to indicate that wheel was scrolled to adjust a value. I have learned to beware of inadvertent value adjustments but it still happens occasionally. It is fine to have it operating as it does now, but this kind of an option would be welcome.

I once wished an option that would either require input focus before performing mouse-wheel based value adjustment, or alternatively, e.g. 500ms delay within a certain hover delta tolerance that would be enough to indicate that wheel was scrolled to adjust a value. I have learned to beware of inadvertent value adjustments but it still happens occasionally. It is fine to have it operating as it does now, but this kind of an option would be welcome.

Yes, that was a right royal pig not being able to search to the bottom! I'm going to really use Libre Office in future, so thanks for the great tip. For now your work on the document saved the day and I've now gone and published.

An afterthought: This was a really interesting problem because Apple Pages could basically fix issues with a broken Word (its ability to autoaccept table changes and control so well Word tracking is a powerful feature and makes Pages a valuable Word document tool). It is also interesting that it seemed to be able to handle numbered paragraphs so well. Without having the original Word document, it is difficult to say what actually caused the numbering chaos in Publisher (e.g., losing the number formatting). As mentioned, InDesign imported the sample Word document better but it was necessary to redefine the heading styles there, too. Yet the .docx file exported by Pages appeared to behave correctly in Word. 
EDIT: I forgot to mention that I seem to have found a bug in the UI of macOS Publisher when trying to Find Replace heading styles. When there are lots of styles, it is not possible to scroll hidden styles visible similarly as it is on Windows where there is an arrow at the bottom of the list and where the mouse wheel can also be used to scroll these kinds of lists. I could not find an alternative method of having formatting style added in Find and Replace boxes so I did this task in the Windows version.

scrollingbug.mp4 EDIT: I realized that it is possible to use arrow keys but it is of course pretty awkward...
UPDATE: Actually LibreOffice Writer could also be used to fix the Word document [accept all changes and stop tracking] and when saved back to Word format, the numbering problem was also fixed [but only when importing to e.g. InDesign; Affinity Publisher appears to have bugs in importing lists]. There was List Paragraph style that had alphabetical list style removing of which fixed the insanely long lists in a snap, but there are probably paragraphs where this list styling was intentionally applied so careful revision job is needed to make this document work as expected. 

@lacerto Good catch! Thank you. I'm on a 2017 MBP using an Intel Processor and I found that rgbtoi works for me too if I turn Metal acceleration off. Just wanted to confirm this is the case with Intel Silicon, so the developers have this info. I haven't retried the Voronoi (cellnoise) function yet, but I may do so. 

@lacerto Thank you, Lacerto. That definitely works.
I came up with an alternative solution until "rgbtoi" and other PT functions are fixed in v2.4. I hard-coded 30%R, 59%G, 11%B into the formulas for each individual channel. As long as the a,b,c and d variables are set to zero, I get a straight BW conversion, since all three channels are identical. This results in a BW conversion which is indistinguishable from Channel Mixer (with CM set to grayscale). The a,b,c,d variables are for toning and brightness control. They allow me to adjust the color of the individual channels (by eye). The "d" variable allows me to control the overall brightness. I made that brightness adjustment "d*2" in the formula to allow for a much wider brightness range when working on dark images. So, this way, I don't have to worry about the position of the sliders to achieve a neutral tone. 
The slider settings of +17R and +20Y below give a warm yellow-orange tone to the image. I created a bunch of "Value Presets" for different tones. I wanted to use the rgbtoi function, but this works okay for now. 
Thank you!! 

I meant that there is same kind of inaccuracy also in VectorStyler native shapes as regards snapping, but typically only at these kinds of zoom levels:

This means that snapping indicators tell that there is perfect snapping (collision of not just arcs and two kinds of ellipses it can draw, but whatever objects...), while there is still this kind of microscopic gap that has no meaning in graphic design.

You’re welcome.
I don’t have VectorStyler so I can’t repeat that workflow but I guess it might depend on how VectorStyler internally handles ellipses.
If it handles them differently to the Affinity applications – e.g. single curve surrounding two focal points, instead of multiple bezier curves –  then that could account for the difference. (I’m fairly sure that this has been discussed elsewhere in the forums, probably a number of times.)
As you say, the difference is usually so small that it doesn’t matter for illustration purposes and, in my opinion, if someone really needs to do precision drawing then they should probably be using CAD software rather than illustration software (although, of course, that doesn’t mean that the illustration software cannot be improved in the future to be as precise as CAD, in this area at least).

Only by using third party software like this one. The good news is that you can relatively easily copy and paste basic vector objects between both apps via the clipboard.

Thanks for posting!
There is one point worth noting mentioned in Blurb instructions:
Some service providers, on the other hand, might use (overly) strict preflight routines that discard a delivered print job for reasons that seem trivial. But they often are not, considering what the print personnel in such services really can do.
Many on-demand-printers targeted for general public e.g. might simply just strip any color management included and if there are transparencies, might flatten them with whatever tool is available for them. Such operations might leave visible stripes or color changes between adjacent (flattened and non-flattened) color areas, which would then become as nasty surprises in printed product if not noticed when checking the drafts (if even available).
Noting users of possible issues as regards use of live transparency, mixed color mode, etc., and recommending "legacy" press standards, are often kinds of safety measures and warnings and recommendations, and they are often given assuming that users have easy ways of applying these changes (i.e., that they do the layout with e.g. InDesign, QuarkXPress, etc.). There is typically no press-specific information available for Affinity apps, and it cannot be assumed that printshops have trained personnel knowledgeable enough to know about specific limitations and workarounds of Affinity apps to give step-by-step instructions for their customers (especially as press-specific development is going on).  

Just to add my 2 cents: I'm mainly using Blurb and Whitewall. Both are providing some help on creating PDFs for their services:
 
Blurb:
A good starting point is this page: https://support.blurb.com/hc/en-us/articles/360044955872-Affinity-Publisher-PDF-Dateien
For Whitewall:
Starting point: https://service.whitewall.com/hc/en-us/articles/4411250880273-01-Advantages-of-the-PDF-upload
When you start at this page https://www.whitewall.com/uk/coffee-table-book creating a book, you will get .idml template files for the content and the cover.

@lacertothis is brilliant! Thanks for everything 
 

Here is basic visual preflight that you can do in apps like Adobe Acrobat Pro that can show separations and check use of transparency, overprint and rich black, and total ink coverage. 

basic_preflight.mp4  You mention newsprint so I wonder if the default CMYK profile you are currently using (U.S. Web Coated v2), which allows up to 300% total ink usage, is appropriate, or if your printer can recommend something with lesser maximum ink usage?  Related to this, please note that if another CMYK profile is recommended, you cannot simply just switch the profile at export time, since Affinity apps do not allow "keeping the color numbers", but instead will recalculate all CMYK definitions, which would result in K100 blacks being converted to rich black. So if you need to change the profile, use File > Document Setup, and Color tab, and when switching the CMYK profile, make sure that you use the "Assign" option if you just want to change the profile without causing change of color values (this would keep you K100 text as K100) -- or, if you want to have Affinity Publisher to translate all CMYK colors for lesser ink coverage, use the "Convert" option, which would cause K100 to become rich black, which you then need to change back to K100 using e.g. Search and FInd, optimally combined with text style definitions. 
 
 

@Jane DK - I'm sorry for my somewhat frustrated words above, but I'll try to be more helpful, even if what I mention here is a bit out of topic considering the original subject.
Producing using PDF/X-1a (or PDF/X-3, and making sure that you check the Convert color spaces option) gives you the closest to the preset you have used in InDesign: essentially, these two export methods are the only way to produce automatically transparency flattened PDF within Affinity apps, which is what PDF 1.3 supported in other page layout apps will do. If this is what your printer truly requires, these two are the only options you have to automatically flatten the transparency (opacities, PNG and other images with transparent backgrounds, etc.)
The bad news is that it does not work well with the kind of job you have at hand, since a newsletter is likely to contain placed PDFs on the layout. If so, you should know that if you export using PDF/X-1a, all non-PDF/X-based PDFs (e.g. logos, ads, etc.) will be rasterized and their colors recalculated, e.g. K100 black will become four-color black -- unless you let Affinity Publisher interpret their content (in which case you should have all fonts used in these files installed on your system, and check that they are correctly mapped; and check that colors are not recalculated: they most certainly will be). You mention above that this is specifically what went wrong with your job, and this is one explanation to this. 
If you export using PDF/X-3, PDF/X-1 and PDF/X-3 based placed PDFs will not be forced to be rasterized, but will be passed through; everything else will be rasterized and colors re-interpreted. If you do not have this kind of placed content (or do not mind having it rasterized and colors changed), I suggest that you try either method, and let your printer have a comment on output. It should be technically pretty close to what they expect. It is true that most printers today accept live transparency so if you want to make your life easier with Affinity apps, you'll do yourself a favor if you look for a printshop that does not have a problem with it. Your job is a kind that allows such a switch, but those depending on low-cost on-demand book print services, might not have that freedom.
You mention that you will try PDF1.4 based method. That will not flatten the live transparency, and is also an export method that allows mixed color modes, which might be something that your printer does not want. Technically the most compatible export method would be the default, PDF (press-ready) that uses PDF 1.7. That will not rasterize any placed PDF content, but would of course not flatten live transparencies, either. [Non-PDF/X-based press exports in Affinity apps, on the other hand, will retain RGB colors in PDFs that are passed through, which is probably something else that your printer might comment...]

Not that I know of. The logo was provided on the web as svg. I then made some changes to the shape, as it should be placed exactly over the existing decals of a bike (plotted vinyl in a different color than stock).
But exactly in the area where the problem point was, I actually added and edited points manually in Affinity Designer.
What I also tried in between was to copy the logo in the form as uploaded here to the clipboard and paste it onto a new worksheet in Designer.
There suddenly "expand stroke" worked. Pasting it back into the original worksheet, however, "expand stroke" again did not work.
Yes, I could have carried out the action on the other worksheet and pasted the finished logo back, but I constantly have to adjust the outline thickness in the process and this would have been too tedious for me, especially as I found the situation to be a hair-raising experience.

The ICC profile would be important if it is embedded in the PDF (as it is when using the default press ready CMYK PDF export preset of Affinity apps), and when using a viewer like Adobe Acrobat Pro, which in the Output Preview dialog allows the user to pick an ICC profile to simulate when interpreting the shown (calculated) color values.
However when using a custom color profile, like the one I used in my demo, which is based on US Web Coated SWOP v2 but just has Dot Gain value increased to 30% using Photoshop, and the profile then extracted from a TIFF file where it was embedded using EXIF tool, the resulting ICC profile is not one that Adobe Acrobat Pro lists (I thought that it lists all that are placed in the system color profile folder, but obviously it does not). That means that I cannot select the correct simulation profile to match with the ICC profile embedded in the file, and would accordingly see misleading color values in the Output Preview window, as demonstrated in the video below:

icc_preview.mp4  The video also shows (in the PDF viewed on top right) how selection of simulation profile is irrelevant (does not have any effect) on a job that it "DeviceCMYK" (not ICC-dependent), and how PDF/X-based job has an obligatory output intent indicating the target CMYK profile of the job, and automatically selected as the simulation profile. Here the actual ICC profile used in the job can be used by Acrobat even if it cannot list it in jobs where the color intent is not included. The files used in the video also demonstrate how grayscale 0 and RGB 0, 0, 0 black (virtually identical color definitions) will result in the kinds of even builds of CMY values, and 100K when converted to a CMYK-based PDF, so one possible explanation to what OP might have experienced is having originally defined black as a grayscale value, and expecting it to be handled as K100 values, similarly as e.g. in InDesign, while in Affinity apps gray values in a CMYK color document are treated as RGB values that always result in four-color blacks. [UPDATE: Note though that grayscale images that are placed in a CMYK document have the "K-Only" option automatically applied on them, forcing the gray values being handled as K-only values; so if the unexpected color values are only related to TIFF and other placed black images, this does not explain what happened; so it might have been "view-only" kind of issue.] 
 blacks_pressready_icc_embedded.pdf
blacks_pressready_icc_not_embedded.pdf
blacks_pdfx1a.pdf
Here is the ICC profile that I created, perhaps somebody can have Adobe Acrobat Pro show it in its list of simulation profiles
USWebCoatedSWOPd30.zip

Hello @lacerto thanks for all this info! Very helpful. I'm using Publisher 2.3.1 - to give more background on the issue, the PDF is for a CD printing project and I already received print proofs that had incorrect colors while printed. The CMYK values are resulting from a conversion from RGB, where there very rich dark browns. My designer is using Acrobat (I believe) to verify color values.
 
Would you say that a good course of action moving forward would be to try using TIFF files that have no color profile embedded? The main reason I have ended up in this situation is because I'm trying to fix a print color issue that already occurred (though this issue was with the colors, not the ink levels). The reason the TIFFs have embedded profiles is to fix the washed out colors that I received with my first print proof.
 
@stokerg I just sent the color profile for you to take a look at. Is it possible that using Adobe programs to check the PDF for errors is actually producing the errors? And if so, what program do you suggest I do color checks with? Is it possible to do this with Affinity Publisher?

Hello @thoy,
My first question is: which version of Publisher are you using?
I have been reviewing Affinity color management related issues for a few years, and do not expect rapid changes, but it seems (and I hope I have not just made some stupid mistake) that the recent 2.x versions finally show some development and improvement -- at least in perspective of users with some experience of using other professional page layout apps. Namely: it seems that Affinity apps (at least Publisher) now, similarly as e.g. InDesign, discard embedded CMYK profiles from TIFF and JPG files, meaning that placing a raster image with an embedded CMYK profile that conflicts with document CMYK color profile, or with the CMYK profile selected at export time no longer results in conversion of CMYK values of these images. I am not sure if this is optional (e.g. is or will become a color profile policy setting, but possibly -- and hopefully -- so, since needs are different in the three apps of the suite).
Native CMYK color values (of shapes and text) will, as they basically should be (without an option available that would explicitly prevent this), as will be color values of .aphoto and .PSD files with a conflicting embedded CMYK profile, probably because of their potential complexity, as they can hold vectors/text/etc., be complex jobs.
Anyway, to keep things simple when placing CMYK images, it is advisable, if at all possible, to use TIFF or JPG images with no color profiles embedded, in which case they will be assigned with the document CMYK profile and their native colors will be passed through, also when changing the CMYK profile at export time (something that normally should not be done if CMYK definitions are used in text and other native objects). As mentioned, you can now (at least in recent 2.x versions) also place CMYK TIFF and JPG images with embedded and conflicting profiles because they will be ignored and native colors of images will be passed through. Note though that in version 1 apps JPG and TIFF CMYK images with conflicting profiles will have their native colors recalculated.
Along with this change many issues with K100 definitions becoming inadvertently converted to four-color blacks at PDF export will be avoided.
The attached PDFs demonstrate how K100 definitions are translated and retained in different situations. The first PDF is exported using the document color profile, the second is exported to a different CMYK profile.
 webcoated_dg30.pdf
isouncoated_yellowish.pdf
Note that the Publisher document in these examples uses pretty much the kind of a CMYK profile you mentioned, based on SWOP Coated with max 280% TAC and 30% dot gain, as will some of the placed K100 images. As can be seen, the only problematic images are .aphoto files, which are recalculated when there is a profile conflict. RGB black and K100 and 400% black in native shapes and text, when there is conflict, will also be converted, as expected. 
The second big question is: which app are you using to verify the color values of exported PDFs? The 30% 30% 30% 100% build especially sounds dubious, not something that would appear as a result of an ICC profile based conversion of CMYK values (but rather a CMYK representation of an RGB/Grayscale black). Anyway, it is good to notice that Affinity apps by default embed the document ICC profile when exporting to press-related PDFs, which is in many ways problematic, because it often makes an all CMYK (already fully resolved) file ICC-dependent, and when such a file is viewed in e.g. Adobe Acrobat Pro, the displayed color values in Output preview depend on the selected simulation profile, and the correct profile will not be automatically selected (unless in PDF/X based exports). This means that inherent values are recalculated ad-hoc on display if the correct document color profile is not activated (in Output Preview). Most PDF viewers do not support selection of a simulation profile and do not suffer from this issue, but this confusing default export method (which in other page layout apps can be done, too, in case the default and recommended settings are deliberately rejected and changed) continues to trouble both users of Affinity apps and production personnel, and may actually result in inadvertently converted (or unnecessarily changed) print jobs. 
There are also other related issues -- though not relevant in your situation -- in Affinity produced PDF exports (e.g. so called PDF "version incompatibility rules" dealing basically with transparency flattening), which may cause inadvertent rasterization, which in context of K100 objects results in translation of mere black to four-color blacks.
These kinds of problems cause much insecurity, and in lack of proper preflight / prepress tool, it might be a good idea to open exported PDFs in Publisher (or another Affinity app) and examine the color values. In most situations (but not always) an opened PDF file shows colors accurately and at least helps making correct production decisions.  

Color management within Affinity apps can be quite tricky and results are dependent on what kinds of images (possibly with embedded profiles), in what kind of a document (RGB or CMYK, which document color profiles are involved), which color profiles have been defined in the app settings (this would be important especially if importing PSD, Photo or other files treated as documents within Affinity apps, or if you have e.g. RGB document and you have an implicit CMYK document profile) and how you export it, and which viewer you are using to examine the results, so an example or more information would be needed.
As a general advise, you are going to get most likely what you expect if your document CMYK color mode matches the target CMYK color space, and you either place TIFF files without an embedded color profile, or TIFF files with an embedded profile that matches your document CMYK color profile, and you then export to PDF by using the document color profile (and do not change the profile at export time). Then, depending on the viewer, you might also need to make sure that the viewer simulates the correct target profile and does not perform recalculations of actual color values saved in the viewed file.
PS. Welcome to the forums!