APP: support fixed length leaders

[GarethOakes]

APP supports fixed-length leaders using PI syntax such as <?ul 10mm>. There is no mechanism exposed via JavaScript FOM to provide the 10mm parameter to the leaders feature of APP. Please add support for this parameter to the FOM.

[SimonTaylor]

Thanks Gareth

As I think I responded to you, the PI you provided sets a minimum width for the leader, not an absolute size. Is this really what you're asking for?

Thanks

Simon

[GarethOakes]

Sorry, my description wasn't great. Yes the minimum leader width is desirable, this allows you to avoid situations such as this:

A...B  => leaders OK
Aa..B  => uh oh, running out of room..
AaaaB  => .. now we've butted right up because the leader area is allowed to squish down to zero width

[SimonTaylor]

Hey

Just putting together some requirements for this. Including:

• fLeader.length - a fixed length leader
• fLeader.minLength - a minimum leader length - minLength is assumed to be length if this isn't set but length is
• fLeader.maxLength - a maximum leader length - maxLength is assumed to be length if this isn't set but length is
• fLeader.minRepeats - a minimum number of repeats of fLeader.text
• fLeader.maxRepeats - a maximum number of repeats of fLeader.text
• There are things to iron out around what if things don't fit, etc... For example, if the minLength is greater than the space available what to do?

Any input would be great!

Simon

[GarethOakes]

Sure, I think the use cases we've seen for this are the one I highlighted plus the need for a field of a fixed size. To expand on that:

1. Scenario #1: You are outputting leaders for indexes, ToC, etc. and want to set a minimum leader width such that the page number doesn't bump into the text.
   1. In this case the max width is unlimited and min width would be set to allow say three leader dots, so the minLength should support relative measurements e.g 1.5w.
   2. Also if the minimum width is reached then the following text (page number) should break over the line and also the preceding word should keep with it, e.g., "text1 text2 text3...123" if the 123 should break over a line then the "text3..." should follow with it, respecting any indent or hanging indent
   3. A more complex case is where the page number has multiples (e.g. "text1 text2 text3...123, 456, 789") in that case you allow breaks in the numbering (at the spaces) but need the option to right-align the numbers that break over. Again if the 123 goes over then the "text3..." would follow as per the rule above.
   4. I guess the right-to-left languages would need testing with the above logic too?
   5. I've added a screenshot from one of our index test files below to help illustrate the various scenarios. I'm not sure how much you want to bite off in this piece of work but the context is hopefully helpful.
2. Scenario #2: You want to use leaders to output a fixed width field, such as a signature line or an entry field in a printed form. In this case I guess the min/max width would be the same? We would typically use the <?h> command to insert a fixed width block of space and decorate it accordingly but I think the fixed leader might be the better option.

For the minWidth greater than the available measure issue there are already options in ALD to handle similar circumstances with words, e.g., we used to find ALD locked up if hyphenation was disabled and an unbreakable and lengthy word appeared in a very narrow table column. In this case we have options that allow a last-gasp hyphenation attempt or instead allow the text to overflow the table cell width. I would suggest a similar preference which says you can either shrink the minimum or allow the overflow.

The repeats option is interesting but I'm struggling to think of a case where we would need that.

I hope that helps?

Index test file screenshot: