Is it possible to break text by spaces and symbols only, but do not break words?

[Blake_S]

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.
 

[Blake_S]

16 minutes ago, GarryP said:

The text needs to be contained within the Frame Text layer boundary so any overflow of the text beyond that boundary would be a problem.

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.

[laurent32]

1 minute ago, Blake_S said:

The program should instead show that a text overflow is happening, not arbitrarily break words

I agree with the above 100%, I would even consider it a bug, something to change…

[Blake_S]

2 minutes ago, laurent32 said:

I agree with the above 100%, I would even consider it a bug, something to change…

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...

[GarryP]

Note: I hid my earlier post because I think I was thinking of something completely different to what you were asking for, and people reading it could have been confused by it, making the discussion more difficult to follow.

Can you specify what you think the software should do if the text cannot fit within the frame?

For example, in your sample, if the word “test” does not all fit within the width of the frame, where should the word, and the text following it, go?
If the word cannot fit in the width of the frame then none of the text in that frame, from that word and the text after that word, will be displayable, since that word can never be displayed in that frame at that size.

[Blake_S]

2 minutes ago, GarryP said:

For example, in your sample, if the word “test” does not all fit within the width of the frame, where should the word, and the text following it, go?

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.

[laurent32]

It would just show :

Like it already does for "general" overflows…

For this example I just changed the text's color to white.

[Blake_S]

Just now, laurent32 said:

It would just show :

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

[GarryP]

Blake_S: We must have posted at pretty-much the same time there.

Now that I know what you want that makes more sense than what I was thinking of earlier. (I thought you were suggesting that the text should be drawn outside of the text frame, which would have been bad.)

At least I know what the request is about now, and it seems quite reasonable to me.

[laurent32]

Here you go !

[Blake_S]

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.

[MikeTO]

Publisher does work a bit differently than InDesign but I don't think this is a bug but a design choice. If the next word in a story cannot fit in the last frame, Publisher will show as much of that word as it can. This is how many programs work - Microsoft Word and Apple Pages do the same thing. The reason programs were designed this way is that a truncated word + the overset icon is a better visual indication that text is overset than just the overset icon itself. I realize that InDesign doesn't work this way and perhaps that's preferable, but Serif has chosen a very common approach.

But Publisher needs to show the overset text icon and raise the preflight flag and it does for me on macOS, regardless of whether I've typed just a word, inserted a field like Section Name, or inserted a data merge field. I can't find a way to not get the overset text icon to show up like you're experiencing. Can somebody else using Windows draw a small text frame and type a word into it and see if the overset icon appears when the word is truncated like this?

I also replied to your other thread about the overset text icon not appearing with data merge and overset text.

Cheers

[Old Bruce]

Can you not use Art Text text frames instead?

[laurent32]

6 hours ago, laurent32 said:

If you have 2 words and only 1 fits in a block, then you don't have 1.5 words that show up so I guess that if you have 0 words that fit in a block then you wouldn't have 0.5 word that would show up either…

In the above picture, I think the red marks are already alerting something is going wrong…

Considering :

The above picture make me think it might be some Spanish sentence, "te amo" for example.

Of course, I believe we can have different opinions…

[PixelEngineer]

15 hours ago, MikeTO said:

Can somebody else using Windows draw a small text frame and type a word into it and see if the overset icon appears when the word is truncated like this?

 

Yes it appears when the word is truncated on my Windows machine. And also appears past the edge of a page.

 

[Blake_S]

17 hours ago, MikeTO said:

The reason programs were designed this way is that a truncated word + the overset icon is a better visual indication that text is overset than just the overset icon itself.

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.

[carl123]

On 1/18/2023 at 7:43 AM, Blake_S said:

Enabling "No break" attribute disables all line breaking entirely so it can't be used.

"No break" only disables all line breaking if applied to the entire text

You can apply it just to whole words, specific (long?) words and not apply it to "spaces" if you want line breaking to occur at "spaces"

But between this and your other thread, without a sample document/page that shows the issues you are having most people are just guessing at solutions for you

[Blake_S]

8 minutes ago, carl123 said:

"No break" only disables all line breaking if applied to the entire text

You can apply it just to whole words, specific (long?) words and not apply it to "spaces" if you want line breaking to occur at "spaces"

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.

[PixelEngineer]

On 1/18/2023 at 2:43 AM, Blake_S said:

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

The word will break up when it does not fit the maximum character length design of the given text box. Design the text box width to accommodate the word that contains the most characters in the database for that field. When this is done, your words will not break unless you break this rule. To accomplish this you will need to go into your database and find the largest word that exist in that field and then plan your design.

I ran some simulations and the words did not break when following this method. Preflight will also notify you if the text extends below the base of your text frame. You can check 'preview with record' and look on the bottom left of your screen to see if there are any errors before compiling.

[Blake_S]

6 minutes ago, PixelEngineer said:

The word will break up when it does not fit the maximum character length design of the given text box. Design the text box width to accomodate the word that contains the most characters in the database for that field. When this is done, your words will not break unless you break this rule.

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.
 

Quote

Preflight will also notify you if the text extends below the base of your text frame.

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

[carl123]

1 minute ago, Blake_S said:

Sure, but it will not notify you when a text extends past the frame horizontally

But surely it only does that when you enable "no break"

If not then we need to see a sample document to see what is happening!

[Blake_S]

3 minutes ago, carl123 said:

But surely it only does that when you enable "no break"

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

[PixelEngineer]

8 minutes ago, Blake_S said:

"it will not notify you when a text extends past the frame horizontally"

It will not extend horizontally because you planned your design. 

[carl123]

2 minutes ago, Blake_S said:

No. It will break the word between available lines, and thus show no error. Example of this is in the very first post.

Your first post shows you reducing the text horizontally and at no point does the "text extends past the frame horizontally"

Text extending past the frame horizontally and text breaking are two different issues

Still need that sample document/page uploaded!

[PixelEngineer]

12 minutes ago, Blake_S said:

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

When you design your text box to fit Donotbreakthis the word will be pushed to the next line. It will not break unless you break that rule.