Issue with drop cap on numbered list

[garrettm30]

I recently encountered an issue in one of our documents that made use of a paragraph style that combined drop caps and numbered list. It worked in most occasions, but it appeared Publisher had some issue calculating when to break for the next line if the line was at a certain length. I was able to work around the issue for our publication, but I have copied one of the problem paragraphs and reduced a lot of the formatting choices to narrow it down.

Attached is a sample document with this problem paragraph in cut-down form pasted multiple times. For comparison, here is what I expected the cut-down example to look like:

And below is a brief video of what I am actually seeing. In the video, I first try changing the text-frame dimension, and then I try changing the horizontal character scaling. In both cases, I can find combinations that work and do not work. Sometimes when it doesn’t work, it is just a wrong indent, while other times, we have a collision of two lines in the same space.

 

 

Here is the file from the video: drop cap numbered list.afpub

Tested in Publisher 2.1.1 on macOS 13.4. I have also tested in beta 2.2.0 build 1931 with the same results.

 

[MikeTO]

I see the same issue. That's a good test document for it.

[Oufti]

Setting a tab stop in the Paragraph > Bullets and Numbering panel seems to help… (And then redefine the style.)

(I don't really understand how this bullet tab stop interacts with other ¶ tabs…)

[Edit] Since there is a Left indent of 12 mm  for the paragraph, the tab stop should be placed a little bit on the left (most precisely at a maximum of 11,928 mm). Setting it at exactly 12 mm is a trigger that makes the line reflow. 

Edited August 2, 2023 by Oufti

[Dan C]

Hi @garrettm30,

Thanks for your report and file provided, this is certainly appreciated!

I can confirm that I've been able to replicate this issue here and I've logged it with our development team.

I hope this helps

[Old Bruce]

22 hours ago, garrettm30 said:

I recently encountered an issue in one of our documents....

 

5 hours ago, Dan C said:

I can confirm that I've been able to replicate this issue here and I've logged it with our development team.

It appears to be triggered by the Language. If I change it to None for the Hyphenation (and maybe the Spelling) then things work right. English (UK) seems to solve it as well.

 

 

[Oufti]

8 hours ago, Old Bruce said:

It appears to be triggered by the Language. If I change it to None for the Hyphenation (and maybe the Spelling) then things work right. English (UK) seems to solve it as well.

Well found! The problem seems effectively to rely on hyphenation.

I think a better solution would be to allow a little more tolerance in the Hyphenation settings in the Paragraph definition. Setting there a minimum hyphenation score of 2 (instead of 0) solves the problem and permits to keep the language and hyphenation set for French or Auto. 

[garrettm30]

11 hours ago, Oufti said:

I think a better solution would be to allow a little more tolerance in the Hyphenation settings in the Paragraph definition. Setting there a minimum hyphenation score of 2 (instead of 0) solves the problem and permits to keep the language and hyphenation set for French or Auto.

Hyphenation is surely part of the line-width calculation that Publisher contends with, and it is probably involved here. But turning minimum score to 2 all but turns off hyphenation. In the actual document of 8 pages, a setting of 2 results in exactly one hyphen through the whole document and tons of unsightly gaps that could have been solved by hyphenation.

Minimum score of 0 is a legitimate setting and in itself not the cause of lines overlapping. Turning off hyphenation does cause the problem to not manifest in this case, but so does turning off drop caps, or turning off the numbered list. I suspect it is somewhere in the combination of those things. As I said, I have already worked around the issue for this document; I am just reporting of the issue to Serif, and Dan C was right to log it.

[Dan C]

23 hours ago, Old Bruce said:

It appears to be triggered by the Language. If I change it to None for the Hyphenation (and maybe the Spelling) then things work right. English (UK) seems to solve it as well.

Thanks for pointing this out Bruce - good catch! I'll get the development log updated with this info now