Disappearing anchored frames: strange FrameMaker bug

Steve Rickaby srickaby at wordmongers.demon.co.uk
Tue Dec 1 01:48:09 PST 2009


As a prefix to this, I've only this week discovered that the reason my posts have been going into digital limbo for a while is that the mail list address has changed. That's a relief: I thought I'd been blacklisted ;-)

At 18:06 -0600 30/11/09, Peter Gold wrote:

>Have you tried selecting an anchor and applying a 100% black border of several points width to display the a-frame?

No: that's a good idea. Or a solid black fill. I'll try it: need to get to the bottom of this.

At present I'm working hard to get this book complete, and I've worked around the anchored frame problem, more by luck than judgement. I'll put some time in to setting up a test file and messing with it, hopefully today. I don't know why the problem 'went away'- which is worrying in itself - so it might take a bit of time to replicate it.

>If the frame has the float property, it's possible that it's moved to the next connected text frame in the text flow.

Yes, but it still shouldn't have disappeared. In this case the following few pages have a stack of tables and both anchored and floating frames.

The last time I saw this sort of behaviour was in Word 6 for the Mac in about '95, in which figures would float off the bottom of a page and fail to appear at the top of the next one, as if there was some sort of digital netherworld beneath the page foot. A call to M$hate support elicited the response 'It sounds as if you're trying to do something too complex for Word: have you considered using FrameMaker?'! But the client mandated Word.

> If View > Show Borders is on, you can look for the black line at the bottom of a text frame that indicates overflowed content that has no place to go - i.e, no next frame in the flow.

Yup, but in this case the vanishing frames were only about one third of a page.

As an aside, I think a special torment in Hell should be reserved for software textbook authors who insist on including code samples that are longer than a single page. If they fall in the text flow there's no problem, but for some books we set these in shaded call-outs, in this case with figure titles, and the only vaguely adequate way I know how to do this in Frame is to use single-column tables. Messing with rows/page breaks during final pagination is a real pain, and all the cutting and pasting it involves increases the chance that something will get lost. If anyone knows of a more elegant way I'd be interested. This is, probably, completely unrelated to the anchored frame issue, except that it means that a book has a *lot* of tables and anchored frames.

As another aside, I just noticed that FrameMaker doesn't increment autonumbers if the autonumbered paragraphs lie in disjoint text frames that are themselves within an anchored frame. This is true even if both frames belong to the same named flow. I wonder if this classifies as a bug, or whether it's intentional?

It's an odd thing: after years of completely reliable hard-core service from FrameMaker, this particular book is throwing up quite a few issues I've never seen before, including some crashes and freezes. Maybe it's jinxed.

-- 
---------------------------------------------------------------
Steve Rickaby, WordMongers Ltd     http://www.wordmongers.co.uk



More information about the framers mailing list