RE: Figure numbering out of sequence with floating anchored frame s

[Esmond Pitt <esmond.pitt@xxxxxxxxxxx>]

Dan

I haven't actually advocated a method, although you keep alleging I have and 
then demolishing your own straw man. I mentioned in passing a week ago a couple 
of the  methods I *use* according to circumstances, often using an explicit 
anchor paragraph as you advocated both before and, at considerable length, 
after I said so. Neither requires me to back-fill pages manually, which I don't 
like, or forces me to make top-of-page (i.e. page-breaking) decisions myself, 
as you suggested on 21/11, which I also don't like. Neither of them is perfect. 
I haven't claimed otherwise. You did so for yours on 23/11. Now you've recanted 
on this, so we agree. There is no perfect solution. I really wish there was.

Regards

EJP

On Tuesday, November 27, 2001 12:27 PM, Dan Emory [SMTP:danemory@primenet.com] 
wrote:
> At 09:17 AM 11/27/01 +1100, Esmond Pitt wrote:
> >Dan
> >
> >You can't have it both ways. Either you are using floating frames & floating
> >tables, in which case we agree, or you aren't, in which case the trouble
> >with
> >non-floating tables and frames is that they don't float.
>
> Okay, non-floating frames flow rather than float, but either way they move
> to the top of the next page. When floating is turned on, two additional
> things happen:
>
> 1. The anchoring paragraph (or possibly a portion of it if it contains
> text) stays on the preceding page.
>
> 2. Text that appeared below the anchored frame before the float action
> occurred may up-float to the preceding page, in which case it appears
> between the anchored frame and its anchoring paragraph.
>
> >This proposition is a
> >logical tautology. Calling it "absolutely wrong" is merely absurd.
>
> The phrase "you are absolutely wrong" was in direct reply to the statement
> below, which appeared in Esmond Pitt's 11/19 email on this thread:
>
> >The problem with Dan Emory's scheme of explicit anchor paragraphs is that
> >you are forced to make the page-breaking  decisions yourself.....
>
> I said you were wrong because you stated that the problem with my scheme
> "of explicit anchor paragraphs is that you are forced to make the
> page-breaking decisions yourself." That is false. Page-breaking decisions
> for anchored frames are completely independent of using "explicit anchor
> paragraphs." They occur automatically, with or without floating turned on,
> based on whether the vertical height of the anchored frame exceeds the
> available empty space on the current page.
>
> Below , you quote from my earlier post:
>
> > > There is no way to "lose" the Float function for a table, because there
> > is no
> >such
> > > thing as an Anchoring Position of At Insertion Point for tables.
> >
> >Now *this* is absolutely wrong. There are five ways to lose the float
> >function
> >for a table, and one way to float it. You are very confused on this point.
> >'Flow' is what text does; 'float' is what frames & tables *can do* if
> >enabled,
> >otherwise they flow too. Tables float if and only if their Start: is set to
> >Float; anchored frames float if and only if the Floating checkbox is visible
> >and selected.
>
> Unlike an anchored frame, none of the Start options for a table changes the
> anchoring position. Tables are always anchored Below Current Line,
> regardless of whether that position leaves the anchoring paragraph behind
> on a previous page.
> Obviously what I meant was you cannot permanently "lose" the float function
> for a table. You always have the option to change the Start option to any
> of the other available choices, unlike when you select At Insertion Point
> for an anchored frame. Once you choose that option for an anchored frame,
> you "lose the float function" (your phrase not mine, I was just trying to
> interpret it as I thought you and Fred Ridder were interpreting it) until
> and unless you change to a different type of anchoring position, at which
> point (for some options) you can turn Float on or off.
>
> >but most of us would consider that empty
> >bottoms of pages are at least as bad a spacing problem as what you're
> >trying to fix, and fixing *that* lands you with your convoluted
> >3-steps-per-affected-frame cut&paste post-process. Taken together, they
> >strongly suggest that you're on the wrong track. Wasted page depth is a
> >problem in itself; having to do automatic processes manually to fix it is
> >another
> >problem.
>
> Is it any more convoluted than the procedure I outlined (you cite step 3
> above from that procedure) for dealing with filling up a column or page
> when the anchored frame (and its anchoring paragraph) flows to the top of
> the next page is far less onerous than trying to standardize the white
> space gap above/below the graphic by fiddling with the graphic's vertical
> position and the anchored frame's vertical height every time the anchored
> frame floats or unfloats.
>
> By using an anchoring position of At Insertion Point, the empty anchoring
> paragraph always stays with the anchored frame no matter how it moves, and
> always establishes the white space gap above/below the anchored frame.
> Also, the Figure Title below the anchored frame always stays in that
> position because anchored frames are not allowed to float, which may cause
> paragraphs (like Figure Title) below the anchored frame to up-float to a
> position above it.
>
> My method also absolutely prevents what often happens when an anchoring
> position of Below Current Line is used. Namely, some idiot other than the
> original author deletes the anchor symbol while deleting text in the
> anchoring paragraph, or types additional text after the anchor symbol in
> the anchoring paragraph, or deletes an empty anchoring paragraph because
> s(he) is unaware that the anchored  frame is anchored to that paragraph.
>
>
> >There is no perfect solution. Otherwise we'd all be using it and there
> >would be no discussion. Obviously we will have our own preferences and
> >priorities among the various imperfect solutions which exist.
>
> There is no perfect solution to anything in the real world. What one should
> do, therefore, is assess the advantages and disadvantages of each available
> option, and choose the option with the fewest negative consequences. I have
> recited several times now the advantages of the method I advocate, as well
> as the disadvantages of the one you advocate.
>
> My method solves all the disadvantages of your method, and has several more
> advantages besides. The only advantage of your method is that text
> automatically floats up from below the anchored frame to fill the column or
> page preceding a page containing a floated anchored frame. And, of course,
> the Figure Title paragraph, the first paragraph below the anchored frame,
> is always the first one to upfloat, which is a serious problem..
>
> Standardization of the white space above/below tables is an important
> feature that is implemented by the Table Designer. But there is no such
> built-in counterpart of that feature for anchored frames. The only viable
> way to implement that feature for anchored frames is with the method I
> advocate. The alternative to my method is to create those white space gaps
> within the anchored frame, which increases the frames vertical height,
> making it even more susceptible to floating.
>
> So, Esmond, using your method, how do you deal with the following issues:
>
> 1. Do you just ignore the need for white space gaps above/below the
> graphic, and shrink the anchored frame to the size of the graphic?
>
> 2. If you try to create the above/below graphic white space gaps within the
> anchored frame, do you attempt to precisely make those gaps consistent
> (within say plus or minus 2 points) for all graphics, and if so, what
> procedure do you follow to achieve that? Also, what do you do about the
> situation when the anchored frame floats to the top of a page, which
> eliminates the need for the white space gap above the graphic? Similarly,
> what do you do when the anchored frame gets pushed down so it is the last
> thing on the page, and the white space gap below the graphic is no longer
> needed?
>
> 3. If you don't create the white space gaps within the anchored frame, do
> you create them outside of it? If so, explain your method, including what
> you do when text up-floats to the preceding page between the anchored frame
> and the anchoring paragraph, in which case the anchoring paragraph can no
> longer establish the white space gap below the graphic, which is now on the
> next page.
>
> 4. How do you assure that a Figure Title paragraph always appears below the
> anchored frame, and is always kept on the same page as the anchored frame?
> In particular, explain how you deal with the case where Floating is turned
> on, the anchored frame floats to the top of a page, and the Figure Title
> paragraph up-floats to fill the preceding column or page, and thus it now
> appears below the anchoring paragraph on the preceding page. Isn't that why
> you are forced to put the Figure Title paragraph into a text frame that is
> below the graphic and inside the anchored frame, because that's the only
> way you can assure that the Figure Title stays in the right place? And, if
> you will look again at the title of this thread in the subject line above,
> wouldn't you agree that your solution cannot solve this problem, hence it
> is not relevant to this thread?
>
>
>
>
> ====================
> | Nullius in Verba |
> ====================
> Dan Emory, Dan Emory & Associates
> FrameMaker/FrameMaker+SGML Document Design & Database Publishing
> Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
> 177 Riverside Ave., STE F, #1151, Newport Beach, CA 92663
> ---Subscribe to the "Free Framers" list by sending a message to
> majordomo@omsys.com with "subscribe framers" (no quotes) in the body.
>
>
>
> ** To unsubscribe, send a message to majordomo@omsys.com **
> ** with "unsubscribe framers" (no quotes) in the body.   **

** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **