Text and Index Frames split numbers - have danglers

[thetasig]

Posted April 23 in mac bugs. Using AFPUB 1.7.1, OS X 10.13.6.

I have noted that both text frames and index frames will wrap around entire words and will not split a word into two lines and will not put a dangling comma starting a next line (keeps the word and the comma together always) and will not allow a dangling space to start a next line. 

 
However, numbers are being split across two lines both in text frames and in index frames and a comma or a single space (such as found between index page numbers) may end up starting a next line both in text frames and index frames.

I believe that these are bugs or broken features; that numbers (with commas and spaces) that wrap around to another line should be treated the same as alphabetic characters (and not split between lines ever) and commas and spaces should not be starting a line that has wrapped around. I have not found any way to control this from the UI.

Here is one example that I have in an index (and confirmed that it has a similar problem when formatted separately in a text frame with the default "body" style).

Example shows 1) the split page number "60" on the first line of page numbers, and 2) the dangling space starting the next to last line before "126" and 3) a dangling comma starting the last line of page numbers.

Photo 
ii, 5, 18, 20, 21, 22, 29–31, 34, 40–42, 44, 45, 56, 6
0, 66, 67, 70, 71, 73, 78, 98, 99, 115–117, 119, 123,
 126, 155, 173, 189, 190, 191, 193–195, 197, 200, 206
, 207, 212, 221

A quirk that is unusual to me: if the number of pages for an indexed item are few, then the Topic Name and the page numbers are all on the same line. If the number of pages is larger than will fit on the first line, then all of the page numbers start on the line after the indexed item (as shown above). I would think it more efficient and consistent-looking to always start the page numbers on the same line as the indexed item (as is possible if the indexed item itself is not too long) and then wrap around to the second and subsequent lines as needed. Is there a compelling reason for this inconsistency between a short page number list and a long page number list?
Thanks for any information on how to control the formatting or confirm if these are bugs.

[Pauls]

Would it be possible to get a sample file exhibiting the problem. I'm not seeing the behaviour you describe.

[thetasig]

Hi Pauls,

Just the other day, I uploaded a large file for you to check out - it has problems of lagging and "Not Responding" for about 8-10 minutes after opening. That file shows the large index and all of the split numbers, dangling commas and spaces, etc. I still haven't found a way around the problem, except to manually make changes (too extensive to do). If you are not seeing the behaviour, then it may be some of my index settings, styles, etc.?

[Pauls]

This appear to be because the index field is using en-spaces and then the wrapping is treating it as one long word. I've logged the issue

[thetasig]

Note that this happens with numbers in a standard Text Frame (with "Body" style) - split numbers, dangling commas, and spaces. I tested that earlier by manually typing fake page numbers (not a copy/paste) into a "normal" text frame. I think it is not just the index field per se.

[walt.farrell]

3 hours ago, thetasig said:

Note that this happens with numbers in a standard Text Frame (with "Body" style) - split numbers, dangling commas, and spaces. I tested that earlier by manually typing fake page numbers (not a copy/paste) into a "normal" text frame. I think it is not just the index field per se.

If you can do it again, and provide the file, I'm sure that Pauls would like to have it. As would I

I have only one very artificial case, attached below.

If I make a Text Frame narrow enough, I can turn a line of numbers and commas and spaces into something like this:

Making it just slightly narrower drops the 8 to the next line.

Making it slightly narrower again drops the comma after 1025 to its own line.

ps: I'm on Windows.

odd-flow.afpub

[Pauls]

If you turn on Text, Show Special Characters - you'll see if different space types are causing the issue as the icons are slightly different

[walt.farrell]

4 hours ago, Pauls said:

If you turn on Text, Show Special Characters - you'll see if different space types are causing the issue as the icons are slightly different

That may be the case with the file thetasig was using in the first post, but it is not the case with the one I attached, Paul. All mine were standard spaces, though as I noted it was a very artificial test.

[Pauls]

yes - that will happen when there is no horizontal space left.

[thetasig]

A workaround is to (Show Special Characters) copy the enspace from one of the index entries and then perform a Find of that and Replace with a standard "space bar" space. Then the index entries do not split numbers or dangle commas and spaces. It's an extra step but fairly quick to do (Replace All - as long as you do not have enspaces anywhere else in the document. Otherwise just Replace one at a time through the index).

[thetasig]

I noted that this problem has been "logged." Does this mean that a fix is slated to be applied to the application? Is there some sort of schedule - when might I expect that this will be done? thank you.

[walt.farrell]

10 minutes ago, thetasig said:

I noted that this problem has been "logged." Does this mean that a fix is slated to be applied to the application? Is there some sort of schedule - when might I expect that this will be done? thank you.

It simply means that a problem report has been created in the formal system that the developers use to track problems.

Serif doesn't tell us how many problems exist in that file, nor what the priority of fixing them may be, nor when they're being worked on, nor when a fix might be delivered.

[thetasig]

OK - thanks, Walt.   ...waiting for Godot... :-)