Blake_S

Well, its not. On rulers made for humans, a 25mm point would be marked, so you just select a middle delimeter between 25 and 30mm and would be done. But no! Its not marked on the affinity rulers. Instead, the closest highlighted point is 28mm. Why? Who the hell knows. That said, still no progress on this issue?

So, will this be addressed? Or do we just give up on using the Data Merge function in Affinity? Bug is still present in the latest version. Just now tried to data merge a simple ticket with only 600 numbers, which are placed into only one text field. A 1.8 MB PDF is used as the background. Realistically, this should take less than 5 seconds to merge. After one minute and the drive running out of space because Affinity managed to write 40GB of data, I killed it via task manager and went back to InDesign CS5 to do the job instead... As a comparison, InDesign CS5 took 4 seconds to export 600 records, 14 seconds for 3000 records, and didn't write any noticeable amount of data to the disk.

Any progress? No? In multiple years no improvement? Like I right now need to set a guide on 27.5mm, and I can't do it using Affinity rulers, because they are not designed for human use, STILL I can do it in any of the Adobe programs that have rulers, or any programs with rulers in general, but not in Affinity. The half point between 20 and 30 mm, which would be 25mm, isn't even marked! And for some reason the area between 20 and 30mm is split into 20 segments, not 10 There doesn't seem to be any magnification setting where 1 segment = 1mm Having 20 segments between numbered delimeters, with no indication of a central one, and none of them being marked is absolutely f***ed. Stuff like this is why I can't even recommend Affinity programs to anyone - what am I supposed to say when the topic of rulers comes up?

So, still no progress on this? Will we ever get proper rulers that can actually be used for their intended purpose?

Most likely because the PDF files people use for testing don't have a trim box specified. Set a trim box that is smaller than a crop box. Unfortunately I don't have the original files now. My guess is after replacement the file is set to trim box bounds, and then scaled up to the size of the previous box, which is a wrong behaviour. Also file replacement behaviour might be different depending if the original linked PDF is present or missing. All instances of the same file I am replacing. Lets say I have 4 instances of the same file in the document, each set to different pages from 1 to 4. After replacement all of them will be on page 1. No picture frames. Placed directly.

Current Publisher version is 2.2.0, but this was happening since V1 When I replace an already placed PDF document with another one, of the same size/dimensions and DPI, the following happens: 1) Placed PDF changes scaling, from 100% to 103%, so I need to revert it back to correct scaling 2) All placed PDF instances reset their displayed page to page 1, instead of what was selected previously, have to set correct displayed pages all over again 3) All placed PDF instances switch to Trim Box instead of what box was selected previously, have to re-set the correct box again on all of them 4) All placed PDFs are now at the wrong coordinates due to wrong scaling and a different box setting, so have to manually put them all back None of this should be happening. Current experience of replacing a PDF via Resource Manager is horrendous. Layout breaks entirely.

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

I placed a PDF inside a new document and want to change its scaling. It doesn't work. I want to set 156 % scaling. I enter 156 %, click enter, it changes to 152 % I enter 156 % again, click enter, it changes to 160 % Then the cycle repeats. No matter what I do I cannot set the correct % Slider doesn't work either as its not precise enough, it skips from 155 % right to 158%

Happens on the Publisher v2.1.1, this bug was present since V1 Triggering conditions: DPI of placed PDF differs from the DPI of the document How to reproduce: 1) Create a new document, set to 300 DPI 2) Place in it a 192 DPI PDF, size A4. The PDF needs to contain an image. 3) Click "Original size" in scaling options, now our PDF is resized to A5, and there is no way to return it to correct size, unless you manually input the size in mm or whatever measurement units you are using. The logic of "Original size" button appears to be completely wrong. Same thing also happens when replacing an already placed PDF in Resource Manager - if the one you're replacing it with has a different DPI, it will be placed in the wrong size.

So the question is then - why a file exported from Publisher shows a wrong color in preview, despite the fact that object inspector shows that the object has correct color?

attached the color profile which was used here is what I see: PSO Coated FOGRA51 (EFI).icc

What Application are you using? [Publisher] Are you using the latest release version? - yes, v 2.1.1 Can you reproduce it? - yes, can be reproduced 100% of the time Does it happen for a new document? - yes, happens in a new document too OS - Windows 10 Pro 21H2 Steps to reproduce: 1) Create a new document with a CMYK profile 2) Make a rectangle, assign a CMYK color to its fill 3) Export the document as PDF using Press Ready profile 4) Open the exported document in Acrobat Reader, go to Output Preview, select the same CMYK profile you used, and watch as your rectangle has a completely different color, not the one you set Color of the rectangle in attached Publisher doc: 0 / 36 / 59 / 9 Color of the rectangle in attached PDF that was exported from the doc above: 7 / 39 / 62 / 0 I did the same procedure in Adobe InDesign CS5, and it exported the PDF with correct colors, the same that I set. untitled.afpub Untitled.pdf

Something goes horribly wrong when AFP creates a merged file. Just now a merged file with 412 pages, all having the same linked PDF from 2 master pages and a single text field on each page, has a 1420 MB (1.4 GB) size after being saved. I'm not able to export it, errors out every time. This is stupid. It should be under 10 MB. The linked PDF size is 1 MB and it contains 2 pages. Besides the links to that PDF and text fields with personalised data, there is nothing else. This suggests that AFP is doing something stupid, like creating a separate copy of a linked file for each page would be my guess. Looks like its back to InDesign CS5 for good for me until this gets resolved. ___________________ Update - re-created exact same job in InDesign CS5. Export took about 5 seconds, vs. AFP erroring out on export after like 3 or 4 minutes.

I might have figured out why. It depends on PDF content. You likely used only vector content or no content at all, in which case everything functions normally, and placed document would just have the same DPI set as the publisher doc its placed in, and it would be placed at 100% scaling. However, if the PDF has raster content, the behaviour changes, just tested this. Saved a PDF with a raster image at 400 DPI. Placed it into the publisher doc with 300 DPI. Its placed at correct size, but at 75% scaling. Clicking Original Size in this case resizes the placed PDF to 100% scaling and the wrong size in mm.

Example: I have a 216x303mm PDF document, I place it into Publisher doc, initially its placed at the correct size - 216x303mm. When I click the "Original Size" button in scaling settings, the document becomes 288x404mm - which is a completely wrong size. This happens with all PDF documents that have a different DPI than a Publisher doc, making "Original Size" button completely useless in those cases.