Blake_S

But that's the bug - the word is being broken down when it shouldn't be, and this is causing the error to not show up when it should be showing up. Basically, the "broken down words" warning is pointless and shouldn't exist, because the words should not be broken down after you disabled hyphenation. Text overflow check already exists, no need to add a separate check. Individual text frames do not work in cases where each of the data fields can have multiple lines, and the number of lines can vary. Like if a name has one line, but the surname has two. Or name has two and surname has one. Most clients in that case ask for all 3 lines to be centered vertically, but they won't be if each individual field is its own text box like in the example above. Already tried to do it like this, and had to re-do it in InDesign instead as a result. One text field allows to center things, but then due to this bug in Publisher the text field will break down surnames and names into chunks between lines, ignoring the disabled hyphenation.

Already said why this can't be done. This only works with low variance in record length. Like, for example, most records fit into 15 characters, yet less than 5% require 30+ characters. If you design just after those few % with max length, the rest will look quite terrible.

its a visual representation of what Publisher does when the text doesn't fit the frame, not what I do myself. I don't break text into multiple lines, Text Frame does. If this wasn't clear, I uploaded screenshots here: Even if you disable hyphenation in paragraph settings, Text Frame STILL retains a second from of hyphenation that at the first glance cannot be disabled, without "No Break" setting, but using this setting is undesirable for several reasons, including another bug associated with it.

No. It will break the word between available lines, and thus show no error. Example of this is in the very first post. Donotbreakthis becomes Donotbr eakthis when there are free lines and not enough horizontal space, no error shown

In the particular job I have this is not acceptable. Some names are way, way longer than others, and it doesn't make much sense to reduce font size of everything just because of several outliers. Instead, I need to find the outliers and correct them. Sure, but it will not notify you when a text extends past the frame horizontally, yet there are free lines remaining. In InDesign it does. Anyway, this would not have been an issue if the text frame stopped hyphenation when I disable it.......... like it does in InDesign

How do I do this if I have one Text Frame with 2 lines, and 2000 records to be data merged into it? Editing each line in the merged doc is of course out of the question.

Even when you disable hyphenation, Text Frame will still break down words into pieces. There doesn't seem to be any way to stop this. This presents a huge problem in cases where words being arbitrarily broken down is not permitted, which is pretty much all documents I work with. This behaviour also prevents a text overflow error being shown in the preflight, so in cases of documents with hundreds or thousands of pages, it prevents you from knowing where the problems are. Example: a multi-line text frame where all text fits the frame: a multi-line text frame where text doesn't fit the frame and a preflight error should have been shown: instead, no error, and words are broken down between lines. Imagine if this was a business card or something like that. Hyphenation disabled. And what happens in InDesign if you disable hyphenation: With hyphenation disabled a text overflow error is shown like its supposed to, words are not broken down.

Gotham SSm The bug happens with any font. Types of spaces or characters don't matter. Alignment doesn't matter. What matters is having "No break" selected in Character settings.

Check with "No break" selected in Character settings

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.

v 2.0.3 This is consistent, doesn't matter if program is closed and re-opened, document re-saved, etc. What does this even mean? You can extremely clearly see that the text is overflowing both past its frame and the edge o0f the document itself. And yes, no overflow icon is shown, no preflight error, thus the existence of this thread

Here you can see the overflow error: And this is also shown in preflight, so if I have a data merged document with thousands of entries, I can quickly find the ones where text didn't fit the frame, and not go over all of them one by one, wasting huge amounts of time. This stops working as soon as you extend the text box into multiple lines however, due to above-mentioned issue. Words would be broken down in random places, and preflight would show nothing, so I would have no idea where the issues are. Only single-line boxes work correctly.

It would also show the eye symbol indicating text overflow, and an overflow error would be shown in preflight

the software should show text overflow error, like in InDesign. The purpose of this is being able to find such issues with text overflow via preflight, and correct them. In Affinity this is impossible, since it will arbitrarily break words into chunks, preflight will show that nothing is wrong, and you will get a f***ed-up file as a result.

Furthermore, I just fired up InDesign to check to text frame functions there, and what do you know, it doesn't arbitrarily break words - if the word overflows the textbox and hyphenation is disabled, it will show text overflow like its supposed to, not break it down anyway like Publisher does...

Words being broken into multiple lines is a much, much bigger problem. So you think something like: Kostomarova being broken into Kostoma rova is normal? The program should instead show that a text overflow is happening, not arbitrarily break words. In pretty much none of the data merge jobs arbitrary word breaking that makes no sense is permitted, but breaking by symbols or spaces is needed. Words should not be arbitrarily broken down unless such a setting is selected.

After the data merge I have multiple text frames where text overflows past the frame, and even past the edge of the document. However, preflight shows none of that as if everything is fine, why? Example: text overflows past the frame and past the edge of the document

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 you data merge a PDF file into a Picture Frame, it automatically gets placed with "Page Box: Trim Box" setting, which cuts off all bleed area, making any files with Trim Box defined unusable for data merge purposes. There needs to be a setting allowing you to choose the type of a PDF box in data merge settings, or if should be placed with either "Bleed" or "Crop" boxes selected instead.

If I create a picture frame and then attempt to data merge a PDF into it, the scaling option of the picture frame will be ignored - if scaling: "None" is selected, merged PDF will still be scaled to something other than 100% and placed at the wrong size. This only seems to happen with data merge, when placing a PDF into Picture Frame manually the scaling option is respected.

Sure, but as I said, the only variable data there is a single text field. Its the simplest data merge job possible. Everything else present is the same on all pages, so only exists in one copy with no duplication, it can be 10000 pages and file size would be about the same. I've seen datamerge examples posted on official Affinity site with many data merged text fileds on a page, plus merged images. Yet my job fails with only one text field. And of course there is absolutely no way a program should write dozens of gigabytes to disk to make a merged file that is under 10MB. Exact same problem as in V1

Yep that's how its supposed to be, the file placed into a master page should be linked on all the pages that used said master page, so that only one copy of it would be present in the exported file, and not duplicated.

Its not. I already mentioned that only a single text field is variable, meanwhile all 4000 pages are supposed to be linked, since they use exact same content. Plus as I said, InDesign exported the file in 15 seconds. The number of records shouldn't matter much as long as your only variables are in text and you don't try to merge images or PDFs, which I do not. If you can't even data merge a single text field, what would happen if you try to data merge a brochure with like 10 text fields and several pictures on each page That heavily degrades text quality so not an option.

I tried to do the following: Create a 2-page document 90x50mm Create 2 master pages, on each page place one PDF page to serve as the static content, apply them to respective regular pages. PDF file size is 2.5MB Create a single text field on one of the pages, link it to a data field from a spreadsheet, this will be the only dynamic content present, 2000 records total Data merge -> create merged document, goes fast enough, under 10 seconds Export as PDF -> the export process didn't even move past 25% after 5 minutes. This is completely insane, as the only variable element is a single text field, it should be done in seconds. It also eats enormous amounts of disk space, dozens of gigabytes. At around 33% I ran out of disk space, and the job processing was cancelled with an error. PersonaBackstore.dat was 34 GB at the time the disk ran out of space. Seems like its trying to re-print the background from the linked PDF for every single record, rather than once. _____________________ I did the exact same steps in Adobe IdDesign CS5, and export to PDF for all 2000 records took 15 seconds. No additional disk space was consumed, barely any RAM was used. Same export settings. Didn't need to create the merged file too, export directly to PDF.

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.