Vosje

Not currently available in V2 but may appear in a future update to V2 or an upgrade to V3, V4 etc

On Windows. at least, I could not see any change in behavior between the release and the latest public beta v2. Now that I tested the feature more thoroughly it has become significantly worse in version 2. Only trimmed design (of Designer document) can be placed in Publisher, and if that document has bleeds defined, the trimmed area is shown all wrong. Even placing the design as a document does not work. In version 1 Designer artboards were shown correctly in Publisher (even if bleeds were cut off), and any artboard could be used with bleeds if placed and positioned in Publisher as a document. Now it is a complete mess. I have not checked yet how this works on macOS.
EDIT: I later had a test run on macOS (Ventura, M1), and release version 2 (not beta) and it is similar there, or even worse. I could not e.g. select which artboard to show of a placed Designer v2 file containing multiple artboards (the first one is always shown). Also, even Designer v2 files with bleed defined but not having any artboard at all could not be shown correctly.
Beta testing is kind of nightmare at the moment. I had version 1, version 2 release and version 2 public beta running concurrently (both Designer and Publisher so 6 apps), and additionally Photo version 2 release. They all became non-responsive after one of the version 2 apps became (even if no longer shown to be non-responsive in Task Manager) simultaneously, and after having been killed, none of Affinity apps, even version 1 ones, would relaunch properly without rebooting the computer. This would certainly be the foremost bug to tackle! 

That's the very purpose of public beta tests.  

Thank you very much for your replies! You're right, @loukash, using PDF/X-4 or PDF Press Ready fixed that, the line is now perfect! And @lacerto, thanks for your comment, I did indeed use PDF/X-1a:2003 the first time, because for whatever reason sometimes Affinity fails to export to PDF/X-4 (couldn't figure out why yet) and PDF/X gives more consistent results color-wise compated to PDF Press Ready when you need to keep a certain color profile... So I figured it's easier to just use PDF/X-1a:2003 for most stuff, but now I see that it also has its limitations!

It may be that the so called "PDF compatibility rules" that are applied within Affinity apps (and as far as I know them only when we are talking about professional page layout apps), ignoring of which results in rasterization (and typically total ruin of placed PDF content to adhering to those rules, e.g. rasterization of embedded fonts, translation of color values, K100 turning to four-color-blacks, loss of overprint and spot color information), are PDFLib based.
But I see no reason why Affinity apps could not try to preprocess the job and flatten the transparencies by using Boolean operations so that rasterization would not be needed. Or at least develop this feature in the UI so that the user could apply it where needed. One good reason probably is that Affinity apps still struggle, also in version 2, with basic Boolean operations, even if e.g. Division, that is useful in transparency flattening works now much better than in version 1 apps. Having transparency flattening as an app feature, like in Illustrator (or Adobe Acrobat Pro) would be very useful, as it would work around library based limitations and would basically allow you to produce 100% compatible DeviceCMYK PDF 1.3 compatible production PDFs that can be printed anywhere.
I am not an expert in printing but I have understood that live transparencies are still out of reach of many print shops. See this related discussion and what is mentioned by David Milisock on CorelDRAW (which also cannot, even in version 2022, do transparency flattening library based, nor does it have direct/assisted support for it in the app) forums:
https://community.coreldraw.com/talk/coreldraw_graphics_suite_x7/f/coreldraw-graphics-suite-feature-requests/65825/exporting-complex-transparencies-and-gradient-designs-from-coreldraw-2020-to-pdf-and-losing-gradient-colour-definition
But if it is available, it is definitely advisable not to use PDF/X-based production methods because of mentioned internal issues [in situations there is placed content to be passed through]. ALL other export methods support live transparency as they are PDF 1.4+ based. PDF 1.3 [besides PDF/X-1 and PDF/X-3] is the only level that does not allow them, and as this method is not supported by Affinity (PDFLib), this causes issues that many have with PDF/X-1a:2003, as it is based on 1.4 while many preflight apps might check version 1.3 as a sign of guaranteed transparency flattening, and accordingly might discard files that are technically perfectly printable. 
As mentioned, Affinity apps are not alone with this problem. As far as I know only Adobe apps and QuarkXPress can handle this well.

In fact, here's my own analysis of Affinity's PDF export problems with transparencies:
As it seems though, this is likely primarily a shortfall of the 3rd party PDFLib that Serif is using. It's rather pathetic compared to Adobe PDF Library even a decade ago.

I'm not sure about whether they make the image larger on exposure, but they do cut a few mm off when making a book. Strangely enough their specifications required no bleed at all - maybe because it's not a PDF and the only thing they care about are total dimensions. However, my question about proper export sizes wasn't as much about this certain photo printer (they accepted my files without issues) - but for possible future stuff where it *may* have been an issue, I just thought that it was strange that the sizes didn't match. But now I know that they will never match anyway and even if I see 60 x 30 mm it's rounded. 😆

But when they post something that can't work, mathematically, you could tell them and show them the math.

I guess yo don't need to know this. If 60 cm are requested / required the delivered 60.01 cm aren't really wrong … unless 60.00 cm would have been requested. But if 60.00 cm at 300 dpi would have been requested they will notice soon that this condition can't be fulfilled.

It is arithmetic plus the fact that we cannot have a fraction of a Pixel (AKA as the d in dpi).
300 mm  = 11.81102362206 inches. And that means 3543.307086618 pixels. Note the decimals. We can't have that with TIFF, JPEG, PNG, GIF, etc.
Here is 300 mm with a pixel grid and the ruler set to pixels.

Thanks for your reply! You're right in the fact that rasterizing the whole image makes the line exactly the same for the whole object. However, rasterizing it makes it pretty burry at the zoom level that I've used to produce the screenshots. 😆 I guess the difference won't be noticeable if you print it anyway...

One more thought on accurate page sizes though:
Given that crop marks alone are usually 0.25 pt = 0.09 mm, in the print domain (where else would you want to use metric units?) a difference of 0.1 mm is usually negligible.
I have now tested this exact scenario you're describing.
I can't see anything wrong with it.
It is exactly as I have described above: Rather than cutting a pixel off, Affinity rounds up to the next full pixel based on document resolution. Hence when you place the exported "600×300" mm (rounded up to full pixels = 7087×3544 px) back on your exact 600×300 mm spread, the image will slightly overlap at 100 % size. That's a Good Thing™ in my book. In the bitmap domain, only an integer amount of pixels can exist.

The pale green lines are my custom pixel grid of the spread to illustrate that 600×300 mm ≠ integer amount of pixels.

It's unavoidable in any apps that need to convert from metric units to the pixel domain:
1 px = 1 pt @ 72 ppi, and 1 pt = 0.352778 mm
Similarly, a DIN A4 PDF will never be exactly 210.000000 × 297.000000 mm.
Affinity attempts to round to full pixels as it seems.
Even an exported DIN A4 PDF from InDesign will not be exact 210.000000 × 297.000000 mm, even though ID has handled the metric system pretty well, unlike Illustrator.
Haha, I hear you. That's why I used to nickname Illustrator "Ill-Frustrator".
Affinity is actually more predictable here.
If you need mm precise dimensions of a bitmap image, you must increase the ppi resolution.
That's why e.g. for precise bitmap graphics you would use resolutions of at least 1200 ppi.

This seems to be due to the rounding of decimal fractions of pixels with Affinity export versus units such as millimetres or points. Unfortunately it is a known issue for years and appears still unavoidable in Affinity. It is especially problematic if an automated print pre-press process rejects PDF because of exceeded page sizes.

I confirm the poor alignment on the bottom of the form.

bottom.mp4    

I've revised my original post 🙂
I've gone ahead and logged this with the developers to pass judgement since there is a difference between V1 and V2 on a layer with identical settings.

I also agree, it's not about the lines being clearer, it's just that there's too LITTLE contrast between the lines in V2 as opposed to V1 (where the active border is MUCH darker - or lighter - compared to the border lines that are inactive).

@Old Bruce and @rvst, of course by resources I don't mean actual artwork, but what @PaulEC named: palettes, brushes etc. Things you use when you make your own artwork. I do agree it's time consuming to ask the original poster whether using them for commerical work is OK, and also, some of them are long gone and won't reply anyway. I would also assume it's OK to use resources freely if people share them, but it's only an assumption and they actually always can say that that it wasn't their intention and they actually didn't want people to use them for some purposes. A general Affinity policy would make things easier, but since it doesn't exist things that have been posted previously still have an uncertain status. It would definitely help if everybody said whether it's OK or not to use something for commercial work as you say, @debraspicher! But, I guess, for all things that have been posted in the past the safest way is to ask the owner...

I think it's fine to ask (time permitting), just as a general curiosity and nod to the poster. I know now though to put in my own uploaded resources "commercial work" OK as a time-saver. That's what important.

I fully agree with what has been said about copyright concerning the use of other peoples images etc that are posted in these forums, or found on the web in general. But I would have thought that if someone posts something, such as brushes, palettes, assets, styles, LUTs, macros, templates etc in the resources section of the forums, then they are expecting other people to download and use them. After all the whole point of resources is that they are shared with others! Obviously these should not be used in any way that is illegal, but if the owner/originator of the item wants to restrict the usage to non-commercial only, then I think it is reasonable to expect them to say so when they make the post.

AFAIK there's no common Affinity policy, or any general permission rules, for offered/shared resources. So you have to check/find out individually.
Can‘t speak for other peoples offered resources, but mine are mostly freely reusable for personal & commercial usage, just with the exception of a few ones, which then explicitely indicate „…for personal/private usage only…“.

@4dimage, oops, yes I do, haha, sorry, don't know why I mixed that up, gonna edit the post! 😆 You're right, it's not normal that Affinity offers an option to create an overprint swatch but there's virtually no difference that you can SEE, you cannot do color separations to check whether everything is right etc. It's not a bug, maybe more like a missing function, but a very VITAL missing function in my eyes... This has been reported multiple times and I believe they don't even assign a "bug" number to such threads (like they do with other found bugs), so I guess is that they view it as a function that Affinity suite just doesn't offer at the moment and it's not known whether they plan to actually do something about it.

I did some testing, it looks like the vertical centering does have a glitch, and it occurs even with the leading set to default (in both v1 and v2). Some particular leading values will trigger the bug immediately.

You use a Leading Override of 18 pt (Character Panel), whereas your paragraph leading is 12,393 pt. I do not know what leading you need. 18 or 12,393? If 18, change it too to 18 in Paragraph panel or use Auto in Character panel if you want 12.393.
Baseline Grid: See icon at top toolbar. An A on blue lines. In addition to this, Align to baseline has to be checked in your text style.

Another workaround is to simply group a callout shape with an ellipse containing the text.