Jump to content
You must now use your email address to sign in [click for more info] ×

Publisher for Windows 1.8.3: Attaching paragraph style causes text to run outside its frame


Recommended Posts

Experimenting with how to use style groups, I created a new group, defined its characteristics, and then a made a new paragraph style based on it ("Body-text" — see the screen shot). The screen shot I've linked below shows what happened when I applied the new paragraph style to a line of text. It runs completely outside the frame. (If it matters, the frame was created with the Text Frame tool, not the Artistic Text tool.) I can replicate this with other new text frames.

But a paragraph below it, set to "No style," wraps within the text frame as expected.

If I style the problematic paragraph "no style," it immediately behaves — line-wraps as expected. If I re-style it "Body-text," it runs outside the frame again.

•  What paragraph settings that I've set incorrectly, or failed to set, could cause such a problem?

https://drive.google.com/open?id=1w5nYg37JBJbYnMoed3MaC0YikOUuhrbn

_________
(Question for any admin reading this post: I still can't successfully attach screen captures to forum posts or comments. Is there any ETA for when this problem with the forum will be fixed? I'm also not able to get the "insert link" feature to work. At least inserting a link by pasting it from the clipboard works, as above.)
 

Affinity Publisher and Photo 1.8.3 (Windows). Lenovo laptop with decidedly sub-optimal monitor. At least it works.
“The wonderful thing about standards is that you can have as many of ’em as you want.”
– Anonymous cynic

Link to comment
Share on other sites

That document (for convenience here I'll call it document "A") began as a new one based on one of Publisher's built-in presets. After creating its first text box, I told the program to remove all unused styles. With no style having been assigned to any text, that wiped out everything but the two "no style" settings. Then I created the Group style on which I based the one referred to in this post.

Next I made a new Publisher document (call it "B") from the same built-in preset. On creating a new text box, I did not remove any existing styles. Instead, I made a new paragraph style created from "Base" and made a few changes. In that case, the text did NOT misbehave by running outside the text frame. It wrapped within its frame as expected.

With both "A" and "B" opened, I clicked with the text cursor inside A's misbehaving paragraph and B's normally-behaving paragraph. Then I opened the Paragraph panel and switched back and forth between the two open documents using Control+Tab. Each time I switched I kept an eye on different parts of the Paragraph panel to see there were any obvious, glaring differences. Then I repeated the process with the Character panel.

I'm not seeing any differences between the two documents that would explain immediately why document A's text is running outside the frame. (My not noticing anything amiss might not mean much — I've missed plenty of obvious things before. : -)

Affinity Publisher and Photo 1.8.3 (Windows). Lenovo laptop with decidedly sub-optimal monitor. At least it works.
“The wonderful thing about standards is that you can have as many of ’em as you want.”
– Anonymous cynic

Link to comment
Share on other sites

Maybe upload Document A and B and maybe someone can work it out, this will also see if the documents behave differently on a different system.

 

iMac 27" 2019 Somona 14.3.1, iMac 27" Affinity Designer, Photo & Publisher V1 & V2, Adobe, Inkscape, Vectorstyler, Blender, C4D, Sketchup + more... XP-Pen Artist-22E, - iPad Pro 12.9  
B| (Please refrain from licking the screen while using this forum)

Affinity Help - Affinity Desktop Tutorials - Feedback - FAQ - most asked questions

Link to comment
Share on other sites

5 minutes ago, firstdefence said:

Maybe upload Document A and B and maybe someone can work it out, this will also see if the documents behave differently on a different system.

A good idea, thanks. I've uploaded a .zip file to Google Drive named Text-frame-issue.zip available at the link below. The two documents in the .zip file are Text-runs-outside-frame.afpub and Text-DOESNT-run-outside-frame.afpub.

https://drive.google.com/open?id=1HEqgJ9FpEwvIEK3NDemjRoWHrvQxdlg6

Typefaces used are Cambria and Arial, which as far as I know are available on all Windows machines.

Affinity Publisher and Photo 1.8.3 (Windows). Lenovo laptop with decidedly sub-optimal monitor. At least it works.
“The wonderful thing about standards is that you can have as many of ’em as you want.”
– Anonymous cynic

Link to comment
Share on other sites

I wonder if "No break" is a new setting in character styling (in version 1.8.3)?

Typically this is only used manually to mark specific words to not break from one line to another, but it should not appear in context of defining a paragraph style as it would then cause this kind of anomaly. 

Link to comment
Share on other sites

30 minutes ago, GarryP said:

The “Body text group” style has “No Break” (in Position & Transform) set to ON.
Setting it to OFF seems to fix the problem, but I can’t find anything about it in the Help.

Excellent sleuthing, thank you. I noticed No Break when I was creating the Group "parent" style but couldn't find any information about it, either.

I'm still a bit perplexed by how Publisher is assigning the attributes. The first time I un-checked the No Break checkbox in the parent (Group) style, that fixed the problem by changing the setting in the "child" style. Since then I've been checking the settings on and off in both the parent and child styles to see what would happen—and now changing the setting in the parent style is NOT affecting the child style. I suppose it must mean that at some point, altering the child style overrides settings in the parent style to the point that editing the parent style no longer has an effect on the other one. That's just a guess. The styles' interactions remain a bit mysterious.

 

Affinity Publisher and Photo 1.8.3 (Windows). Lenovo laptop with decidedly sub-optimal monitor. At least it works.
“The wonderful thing about standards is that you can have as many of ’em as you want.”
– Anonymous cynic

Link to comment
Share on other sites

8 minutes ago, Lagarto said:

Typically this is only used manually to mark specific words to not break from one line to another, but it should not appear in context of defining a paragraph style as it would then cause this kind of anomaly. 

I looked within the Paragraph settings palette and could not find it. Then I thought to check the Character palette and the "No break" checkbox is there — consistent with its location in the style-editing dialog.

If you place the insertion-point in a paragraph with no text selected, then check No Break in the Character palette, nothing happens.
If you highlight a word in the paragraph — somewhere in the middle of a line — then check No Break in the palette, nothing happens.
If you highlight the entire paragraph and check No Break in the palette, then the entire paragraph extends as a single line outside the text frame.

Whether Serif would consider the reported behavior a bug when the check-box is checked during definition of a style, I don't know. They might consider it to be working as designed. It's a bit perplexing, especially in light of its non-appearance within the online help.

If the purpose is to mark specific words not to break, I wonder what the setting's purpose would be as a "global" (meaning, set via the style-editing dialog).

Affinity Publisher and Photo 1.8.3 (Windows). Lenovo laptop with decidedly sub-optimal monitor. At least it works.
“The wonderful thing about standards is that you can have as many of ’em as you want.”
– Anonymous cynic

Link to comment
Share on other sites

Just now, Lagarto said:

It does not make sense in paragraph context as it basically makes it impossible to wrap text

Do you suppose it might be intended to enable the page designer to make text extend across columns, when it would otherwise be constrained within the columns? (I recall seeing someone here or in one of the Facebook groups wishing that "across columns" feature were available in Publisher.)

Affinity Publisher and Photo 1.8.3 (Windows). Lenovo laptop with decidedly sub-optimal monitor. At least it works.
“The wonderful thing about standards is that you can have as many of ’em as you want.”
– Anonymous cynic

Link to comment
Share on other sites

4 minutes ago, Lagarto said:

I doubt it, since it would not wrap text on an adjacent column downwards as a genuine "span" feature would

Quite right. Good point.

Affinity Publisher and Photo 1.8.3 (Windows). Lenovo laptop with decidedly sub-optimal monitor. At least it works.
“The wonderful thing about standards is that you can have as many of ’em as you want.”
– Anonymous cynic

Link to comment
Share on other sites

"No break" is documented (kind of) in the Help for the Character Panel:

Quote

No break—tick this checkbox to ensure lines will not be broken at the ends. Soft hyphens will still be honoured.

Basically, the text will only wrap where you manually wrap it (Shift+Enter), or where soft-hyphens allow, I think.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

If the purpose is only to keep words such as "co-operation" within the same line, then this "runs outside the text frame" behavior might be a bug. You're right that it isn't proper "span" behavior. I don't know what's the advantage of having the text go wandering outside the bounding box.

Affinity Publisher and Photo 1.8.3 (Windows). Lenovo laptop with decidedly sub-optimal monitor. At least it works.
“The wonderful thing about standards is that you can have as many of ’em as you want.”
– Anonymous cynic

Link to comment
Share on other sites

@Lagarto: What is the source of your knowledge about what "no break" is supposed to do? I don't think it's from any Affinity documentation; at least not any that I found :)

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

To add, ID & QXP would hide the affected line and all text in the same text flow, but both applications have a Story Editor where one can remediate the problem. As Affinity applications do not have a Story Editor what does happen seems prudent to me.

Link to comment
Share on other sites

1 hour ago, Lagarto said:

The feature is really meant to bind selected text together on one line.

Glad to have run across this while only playing with test files.

Affinity Publisher and Photo 1.8.3 (Windows). Lenovo laptop with decidedly sub-optimal monitor. At least it works.
“The wonderful thing about standards is that you can have as many of ’em as you want.”
– Anonymous cynic

Link to comment
Share on other sites

On 4/5/2020 at 10:10 PM, Lagarto said:

e.g. if you want to keep a single article "a" and the related noun together. 

In CSS, you have no wrap (white spaces property) and no hyphen options. It would be nice to have the 2 in our layout apps or more options in the Hypention settings, since "no break" seems similar to "no wrap".

In French, we have a lot of compound words, and the CSS hyphen: manual option for them would be usefull, instead of manually using "no break" on the characters (and not the hyphen itself/themselves).

And APub doesn't seems to work like ID, the previous character before the selected ones on which you applied "no break" isn't breakable too, so you need to select porte-manteau instead of porte-manteau.

 

No hyphenation in the paragraph style = CSS Hyphen: manual (Default. Words are only hyphenated at ‐ or ­ (if needed)).

2020-04-07_100432.thumb.png.440212e354864cdd04aeb182744ebf4f.png

 

With Hyphenation enable:

If we select a full word, the precedent character get the propriety "no break" too (the hyphen character in this case):

2020-04-07_100403.png.d33ad72c89944fc3a970c38c10112870.png

 

What we need to do to get the expected result:

2020-04-07_100242.png.995cdd5bce247505be457ebbd00c34d9.png

 

I don't know if I should report  this as a bug because it's different than other apps…

 

 

 

Link to comment
Share on other sites

1 hour ago, Wosven said:

And APub doesn't seems to work like ID, the previous character before the selected ones on which you applied "no break" isn't breakable too, so you need to select porte-manteau instead of porte-manteau.

I made a text frame containing text similar to what's in your example and found that it worked just that way here as well. For this to work properly, the selection had to be porte-manteau when the check-box was afterward selected within the Character palette.

That affected only the one word I'd highlighted. Making the lines break differently that way caused other occurrences of the incorrectly hyphenated word to appear. Fixing those caused other such problems to appear when the lines re-wrapped. If this is a one-word-at-a-time sort of "fix," I can imagine the complete fix for a long document requiring a very long time to complete. I see that manually adding a soft hyphen (Control+Shift+<hyphen> in the Windows version) immediately after the hyphen in "porte-manteau" also seems to accomplish the task. But still — manual labor. I see that it's possible to insert that character via Find/Replace — but considering how many possible such compound words there might be and with no way to automate a solution via scripting — egad, what a lot of extra work it could involve. I used to cope with such things in QuarkXPress (we were using XPress Tags) by running scripts on plain text before importing it into the program. The scripts would add all of the necessary special characters. It's very fast and relatively easy to correct if you make an error and have to re-run the scripts and re-import the text.

Affinity Publisher and Photo 1.8.3 (Windows). Lenovo laptop with decidedly sub-optimal monitor. At least it works.
“The wonderful thing about standards is that you can have as many of ’em as you want.”
– Anonymous cynic

Link to comment
Share on other sites

55 minutes ago, MikeA said:

but considering how many possible such compound words there might be and with no way to automate a solution via scripting — egad, what a lot of extra work it could involve.

Depending of what I'm working on, I usually do it manually in articles, and sometimes too in long texts, since in long text (books), I usually check page by page that there's not the same word/hyphenation, etc. occuring twice or more than twice at the begining/end of a line and I can check bad hyphenation too this way. Of course, it depends of the work: if I've got only few short chapters at a time and time, I'll do it manually, for longer books no.

2020-04-07_124028.png.426c3e5ed04700e204a4cfe5ddd13c50.png

With compound words with capitals in French, like towns or people's names, it can be tricky if you don't want them hyphenated, since adding an article in some will add a lower case to the word: "d’Abergement-Sainte-Colombe".

1 hour ago, MikeA said:

I see that manually adding a soft hyphen (Control+Shift+<hyphen> in the Windows version) immediately after the hyphen in "porte-manteau" also seems to accomplish the task

It seems to work correctly in the new version, last time I tested 2 hyphens appeared (it keeps on if you insert it at the wrong place—before—, but it's normal).

 

Automating this with scripts can be usefull, but when having small width columns or left align text, it can be tricky, and you need to allow hyphenation sometimes, again, checking manually…

Link to comment
Share on other sites

4 hours ago, Wosven said:

And APub doesn't seems to work like ID, the previous character before the selected ones on which you applied "no break" isn't breakable too, so you need to select porte-manteau instead of porte-manteau.

The No Break should be applied to "porte-manteau", I think. That's what you don't want broken across the lines.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

1 hour ago, walt.farrell said:

The No Break should be applied to "porte-manteau", I think.

No, because there's an hyphen and it can break after: porte-
manteau. (but to avoid confusion we'd rather not have hypen in other parts of a compound word than the one(s) already here, like in por-
te-manteau).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.