Copy link to clipboard
Copied
Has anybody had to deal with longish autonumber texts in a narrow text frame [can't use a sidehead due to other issues]? I'm finding that the autonumber string [Facilitator/Self-Study Participant Note: ] doesn't wrap to the next line as shown in this screen capture:
I've verified this happens in FM versions 6 through to 11. Unfortunately, I'm away from my resources for the week but don't ever recall coming up against this before.
Any comments, help highly appreciated.
Copy link to clipboard
Copied
Hi, Arnis:
Does this happen with other autonumber texts about the same length? If this one fails when others do wrap, I wonder if the long string of characters I'm also away from FrameMaker, so I can't test this, but I wonder if perhaps the long string of characters before the first character space exceeds some limit that prevents FrameMaker from choosing a wrap point. Perhaps someone on the forum can test this.
HTH
Regards,
Peter
_______________________
Peter Gold
KnowHow ProServices
Copy link to clipboard
Copied
Hi Peter,
I tried all sorts of different lengths, dropped the backslash, but no difference (it actaully gets worse when the backslash is dropped):
It looks like a bug to me at this point. I'm surprised that it hasn't come up before.
Copy link to clipboard
Copied
How about inserting a conditional hyphen?
Copy link to clipboard
Copied
@Matt,
Conditional hyphen has no effect. It looks like the autonumber is hardwired to stay on a single line (hence one can't use the \r code in it either) with no wrapping of the autonumber contents. BAD (broken as designed?)
Copy link to clipboard
Copied
Hi, Arnis:
Well, if specific fonts cause or don't cause it, then that would be interesting. I did a quick test in InDesign, and Lo! and Behold! the same problem raised by a magnitude: if the text column is too narrow for the long autonumber, it doesn't wrap nor overwrite itself as in your example. Instead it disappears and displays InDesign's text-overflow symbol. In InDesign, text variables cannot wrap across line or container boundaries; they typically overwrite themselves as in your FrameMaker example.
Your example looks like you're using a side-head paragraph format in a side-head pseudo-column. Have you tested the long autonumber in a non-sidehead text frame? Results?
I'm wondering if the limit might be some number of characters equal to or less than the largest-possible number that might need to be displayed in an auto-numbered paragraph format. Perhaps the limit is a combination number of characters that includes text and numbers, digits, decimals, and thousands separators. Have you invested any time and effort in trying various combinations? Results?
You've been the go-to FrameMaker forum resource guy for so long, I'll vote for naming this bug or feature after you, like astronomers name new stars.<G>
HTH
Regards,
Peter
_______________________
Peter Gold
KnowHow ProServices
Copy link to clipboard
Copied
@Peter,
As I mentioned, I'm not using a side-head for this rather an anchored frame with an internal text frame. The content for these marginal notes varies too much with supplemental paragraphs to use a sidehead (there will too large a gap in the content that way).
Also, the same effect happens in the sidehead anyway. I've tried that too.
For now, I've got to call this as a bug and get the client to change the lead-in wording for these notes.
Copy link to clipboard
Copied
How about replacing Facilitator/Self-Study Participant: with Note:?
Copy link to clipboard
Copied
@Matt,
I wish it were that easy.
"Ministry of Silly Walks" types overseeing this...
Copy link to clipboard
Copied
Hi, Arnis:
Ooops. I overlooked your mention of not using a side-head construct. Well, you've done plenty of homework on this, so you need only copy/paste it into a bug/enhancement form and wait a few releases for it perhaps to be changed to something more useful.
I'm sure you've looked into using a variable or cross-reference or text inset as the lead-in text, in a run-in paragraph. Any value in those?
Regards,
Peter
_______________________
Peter Gold
KnowHow ProServices
Copy link to clipboard
Copied
My recollection is that autonumbers cannot extend past the end of a line (which is why they cannot contain forced returns). Back in the dark ages when we were designing the prefix/suffix capability for structured documents, we partially compensated by allowing prefixes and suffixes to contain soft or hard line breaks.
--Lynne
Copy link to clipboard
Copied
Thanks Lynne. Do you happen to recall if it was for a technical reason or just a design decision? This is for unstrucured FM.
Copy link to clipboard
Copied
Arnis,
I first used FrameMaker in 1991, just after version 3 came out. Limiting autonumbers to a single line was in place then. Just a guess, but I suspect that the possibility of a line break just wasn't considered in the original implementation and the capability has never been extended.
When there are no automatically calculated numbers or font changes in the desired string, I recommend using structured documents and inserting the text as a prefix or suffix. While prefixes and suffixes can contain multiple lines, their length is also limited.
--Lynne
Copy link to clipboard
Copied
Xrefs wrap. If the text containing the autonum can reside elsewhere (such as on a Reference Page), an Xref to it in the narrow Body page column does wrap.
If there's room, you could even put the source AN text on the body page, in very small invisible color, right below the Xref.
Copy link to clipboard
Copied
Thanks Error,
However, that approach doesn't help out that much for the perhaps thousand(s?) or so entries in the series (mainly all manual tagging, so keystroke count/mouse-click minimization is paramount). Also, when creating a PDF, it will also create a bogus hyperlink that won't be acceptable to the powers that be [i.e. not my call on most of this]. A scripting solution seems to be th best way handle this.