Blake_S

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.

In V2 I have no problem with data merge speed, that is fast. I have problems with: disk space / RAM consumption during data merge and while merged document is opened (can be multiple dozens of GB) disk space / RAM consumption during Export process - can exceed 100 GB depending on the project Export speed - dozens of time slower than Adobe InDesign with about the same settings

attached both the PDF and the afpackage with it already embedded data_merge_test_.zip

Linked the files. I am unable to export that example at all, as merged file by itself writes 10-20GB to disk in a bout 1-2 minutes, and then Export function continues to write gigabytes of data to disk until all space is taken and then export fails. Also here are export settings: data_merge_test.zip

Also just noticed - don't even have to Export the file - Affinity starts writing dozens of GB of data to disk just from having a merged file open. Right now It had written 23GB to disk after merge with about 500 records. Insane. And all this is to make a 2MB PDF in the end...

Yes, rasterizing PDFs is a bad practice as it will degrade text quality significantly. Rasterised version prints way worse. Also its not 2000 copies, its 1 copy which should be linked on all pages, or 2 copies in case of 2-sided print with different sides. There should be almost no difference in the number of records, as all of them should link to the same background PDFs.

Still having constant problems with this on nearly every data merge job, export takes minutes and writes dozens of GB to disk. Just now export failed because Affinity consumed all disk space and then crashed. I'll setup a test file and link it here later.

Then I get hundreds of false positives, rendering this method entirely useless. Increasing the number means errors are no longer found. In this case I still get a document where no overflow errors are reported, even if this stops the words from being broken down. Thus the issue is not solved, still have to use InDesign or other software.

The issue here is that the current way the text box works prevents me from being able to use it at all. Like I cannot use Affinity programs for jobs I planned to use them for. I need the words to remain intact and not broken. That is a requirement. Current text box doesn't allow that, so its unusable. Normally you would achieve this by disabling hyphenation. But its not just that word, if the column is too narrow then it may be 10s, or 100s of words broken. If you're fine with it, then its useful, but I'm not. Its would be an error in my case. And I wouldn't even know where these cases are, thus I cannot use the software at all. As it stands, in any case where a Text Box that is more than one line in height is involved I cannot use Affinity Publisher, since there is now way to guarantee that the word will remaining intact and will not be broken down.

Just tested this, and it is not a good or reliable solution. First of all, you need to calculate this number on every text field on every job, since it will change depending on the font attributes. However, even if you do that, it still cannot be used reliably - letters have different widths, so depending on what letters are used, there can be either more or less of them fitting in the line. Just now I've seen cases where 12 letters fit in the line with space to spare, yet 10 letters did not fit, simply because of the difference in which letters were used.

No it won't, it is way different. I even provided examples, did you not see them? If you reduce the width of a text frame, it will break words into pieces even with hyphenation disabled. Its in the second screenshot. No it won't... again, did you not see the example in the first post? It reports an overflow error in this case, it doesn't break down the word, its the 4th screenshot Because you didn't test it... the issue is when the text frame don't have enough horizontal space to display the word, but has free new lines, then it starts breaking down words in Publisher, ignoring disabled hyphenation. In your example, you didn't reduce the text frame width, it can still show the first word without breaking it. Reduce text frame width below the width of the word.

Where did you get all of this? Its not in the documentation. Like I want to use text frame to align multiple lines, and warn me when the line goes outside of the bounds of the frame, and this goes directly against your assumptions above. Also, currently "No break" is the only way to maintain word integrity. If I disable it, Text Frame will start breaking words into chunks and placing them on multiple lines even after disabled hyphenation - any way to prevent this besides "No break"?

Well in that case there is no overflowing text indicator. To me it seems like selecting "No break" disables overflow check.