Blake_S

8 months later, program version 2.2.0, rulers are still not designed for humans.
When, if ever, this will be fixed? New features don't mean much when existing ones do not work and existing bugs aren't getting fixed

Visual indication doesn't matter that much compared to preflight error. If the program decides to break down the word into multiple lines all by itself, no preflight error is shown, but this is an enormous problem, as you absolutely do not want those words to be broken into chunks. So now you have a document with hundreds, maybe even thousands of pages and you have absolutely zero idea if there are any problems with it. Preflight shows all clear.
All of you are posting an example of a text box with one line.
I already stated that one-line boxes work fine, the issue is with multi-line text boxes.

Example: I have the following line in a text box:
"test text"
If text box is shortened, text would be broken into multiple lines:
test
text

However, if I shrink text box even further, rather than showing text overflow, it will break the words themselves, it becomes:
tes
t
tex
t

and then
te
st
te
xt

This is an extremely undesirable outcome that breaks data merge. How do I prevent word breaking but keep breaking by spaces / symbols?

Enabling "No break" attribute disables all line breaking entirely so it can't be used.
This issue makes multi-line text fields completely unusable, due to the aforementioned word breaking.

This behaviour "hides" text overflow erorrs by breaking down words instead and pushing a part of the work into a new line, which can have extremely bad consequences.
 

When selecting measurement units as mm, the rulers are mostly unusable, they don't seem to be designed for human use.

Example - I want to set content at 5 and 10 mm from the edge.
I was not able to easily do so by using a ruler.
Neither 5mm nor 10mm are marked on it.
Instead, the following values are highlighted:
4mm, 8mm, 12mm, 16mm
Instead of being divided into 4 segments, its divided into 5, which results in the wrong values being highlighted.
This makes absolutely no sense.

In order for 10mm highlight to appear, I had to zoom for over 300%, which is ridiculous. It should be visible at default zoom.

Here is a reference of how a mm ruler designed for humans looks like (from Adobe Illustrator):

and here is whatever it is that Affinity is doing:

I might have figured out what caused this - it only happens if you take a document made in Publisher V1, open it in Publisher V2, and attempt to place a PDF there, then Publisher will freeze.
If you save the document right after opening it, it should work fine.

Well today I can't recreate the issue either using the same files, so now uploading files would be pointless.
This is however after PC restart, so something might have changed in the system.
As far as I could tell when the Publisher was freezing I still had both free RAM and disk space, so its not that.
If I encounter the same issue again and it will persist after PC restart then I'll upload the files for testing.

When selecting measurement units as mm, the rulers are mostly unusable, they don't seem to be designed for human use.

Example - I want to set content at 5 and 10 mm from the edge.
I was not able to easily do so by using a ruler.
Neither 5mm nor 10mm are marked on it.
Instead, the following values are highlighted:
4mm, 8mm, 12mm, 16mm
Instead of being divided into 4 segments, its divided into 5, which results in the wrong values being highlighted.
This makes absolutely no sense.

In order for 10mm highlight to appear, I had to zoom for over 300%, which is ridiculous. It should be visible at default zoom.

Here is a reference of how a mm ruler designed for humans looks like (from Adobe Illustrator):

and here is whatever it is that Affinity is doing:

When selecting measurement units as mm, the rulers are mostly unusable, they don't seem to be designed for human use.

Example - I want to set content at 5 and 10 mm from the edge.
I was not able to easily do so by using a ruler.
Neither 5mm nor 10mm are marked on it.
Instead, the following values are highlighted:
4mm, 8mm, 12mm, 16mm
Instead of being divided into 4 segments, its divided into 5, which results in the wrong values being highlighted.
This makes absolutely no sense.

In order for 10mm highlight to appear, I had to zoom for over 300%, which is ridiculous. It should be visible at default zoom.

Here is a reference of how a mm ruler designed for humans looks like (from Adobe Illustrator):

and here is whatever it is that Affinity is doing:

First of all, the scale shows the main numbers in increments of 20, which is already quite wrong - it should be in the increments of 10 for default zoom level. To get to increments of 10, you need an extreme level of zoom, more than 300%, which is ridiculous.
You can't really work at that zoom level.
Second bug, the hashes between main numbers are marked wrong.
On a normal ruler, between numbers 0 and 20, the longer hash marks would indicate 5, 10 and 15mm positions.
This doesn't happen in Affinity. Instead it highlights numbers 4, 8, 12 and 16 with longer hash marks.
This doesn't make any sense.
As a result, if you need to see where numbers like 5, 10, or 15mm are located, you can't. They aren't marked.
Here are many examples of how the correct mm ruler should look like
And here is how mm ruler looks in Affinity
Here is an example of Adobe Illustrator ruler at 200% zoom
 

After about a minute more, it actually unfroze.
Export completed successfully, about in the same time it took InDesign.
Resulting merged PDF file is 235 MB, so absolutely nothing had changed after converting to sRGB.

So nope, didn't help either.

No.
Typically you would have an "Image" component right next to the "Link", so that you could put an url of the image there, and it would be displayed.
Or a "Link" component would display an image if it was linked, which doesn't work here.
Attaching files is for your local files.

There is no "image" component when making a post, only link. So I didn't even know you could do this here.
Also other forums can preview the images that are linked directly, but here it doesn't work for some reason.

Hi @Blake_S,
Thanks for your report - I can confirm this is a issue in Publisher currently, whereby when placing a 'wholly vector' PDF document, it is placed at 72DPI, and not the DPI that was used when the PDF was generated, as there is no 'raster' data for Publisher to infer a DPI value from.
This is logged with our developers and we hope to have this improved in a future version, whereby the placed PDF would assume the Publisher documents DPI, should no raster data be found.
In the meantime, if you wish to return the placed PDF file to the size it was when it was first placed, you can use 72DPI in the Scale dialog (rather than a percentage value) and this should return to the expected size.
My sincerest apologies for any inconveniences caused in the meantime!

The Preflight Profile you select specifies the PDF output level to check against. Edit the profile and you'll see it, and can change it.

no, they don't have any crop marks or any other kinds of marks

I can confirm that I can no longer fix the issue with the test project that I sent by just clicking Update button.
However, I've run into this bug again on a new data merge job, with different files.
First data merge went nearly instantly for 500 records.
However, replacing a PDF on a master page with a new one via Resource Manager triggered the bug, resulting is slow merge and huge memory consumption.
When I deleted said PDF from the master page, and just placed the new PDF file there manually, not involving Resource Manager, this fixed the issue.

If not with 1-click, an Asset could at least shorten the workflow. – But how can I make it snapping as needed?  CropMark-Constraint.afassets

cropmark constraints asset.m4v

Yep, I can't get it to work
However, import into Inkscape, save as pdf, perfect on a document using CIDFonts which are not installed
Bit of a pallava but needs must.....

If its for web, use sRGB.
Here is an example of what can happen with AdobeRGB:
https://www.kenrockwell.com/tech/adobe-rgb.htm
For print it depends, you should ask the place where you will be printing.

If its for web, use sRGB.
Here is an example of what can happen with AdobeRGB:
https://www.kenrockwell.com/tech/adobe-rgb.htm
For print it depends, you should ask the place where you will be printing.

Sent the files. I tried to package it, but AP failed to do it correctly - resulting file instead of a linked PDF on a master page has just an image frame with an extremely low res raster of said PDF. You would need to delete that image frame and place the PDF itself on the master page.