RE: Floating footnotes, tables, anchored frames on double-spreads [was "Re: footnote misconceptions"]

[KMcLauchlan@xxxxxxxxxxxxxxxxx]

hedley sez:
 [FRAMEMAKER SHOULD 
> REALLY LET YOU
> WORK IN DOUBLE-SPREAD AND ALLOW GRAPHICS AND TABLES TO CROSS 
> THE GUTTER, AS
> PAGEMAKER, INDESIGN, AND QUARK DO. HOW ABOUT IT ADOBE?]

My first reaction to this suggestion is "of course". 
But then, on sober second thought, I find myself saying "OF COURSE!!!"

Ahem...
 
> @  Feather the text lines sufficiently on a double-spread to 
> push ref onto
> same page as object (as this increases line spacing, MUST be done on
> double-spread so reader does not see an unfeathered page opp 
> a feathered
> page).

Again, yes.  In general I'd like the ease of control that comes 
from seeing pages aligned side-by at decent magnifications.
I don't have a 50-inch monitor, darn it. 
Sometimes it works to fiddle with my inserts and illustrations, 
to make facing-page body text line up the way I want it to. 
Other times, the ability to feather would be very helpful...
say, at times when I use different fonts and sizes on one page.
 
> @  Combine previous two stratagems.

OF COURSE!!!     (oops! excuse me for shouting again...   :-)
 
> @  Normally ref and object should be on the same PAGE but in 
> extremis they
> can be on the same SPREAD.
> 
> @  Let object be placed after the ref., so tables and figures 
> can be placed
> on successive pages after the ref page with suitable xrefs at 
> the anchor
> point.
> 
> @  Let footnotes only split over successive pages.

The footnote text stream should probably be continuous, so that 
the next page's new footnotes could begin immediately following the 
spillover text.
 
> @  Let footnotes split over successive pages in strata.  So, 
> if you have
> eight large footnotes within a half page, each begins on the 
> L page of a
> double-spread (whether ref on L or R page) but continuations 
> are in bands
> on opp page.
> 
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    xxxx 5 xxxxxxxxxxxxxxxxxxxxx
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>     xxxxxxxxxxxxxxxxxxxxxxxx 4 x    xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    xxxxxxxxxxxxxxxxxx 6 xxxxxxx
>     ___________
>     4 nnnnnnnnnnnnnnnnnnnnnnnnnn    
>     nnnnnnnnnnnnnnnnnnnnnnnnnnnn  [4 cont]
>       nnnnnnnnnnnnnnnnnnnnnnnnnn    nnnnnnnnnnnnnnnnnnnn
> 
>     5 nnnnnnnnnnnnnnnnnnnnnnnnnn    
>     nnnnnnnnnnnnnnnnnnnnnnnnnnnn  [5 cont]
>       nnnnnnnnnnnnnnnnnnnnnnnnnn    nnnnnnnnnnnnnnnnnnnnnnnnnnnn
>       nnnnnnnnnnnnnnnnnnnnnnnnnn    nnnnnnnnnnnnnnnnnnnn
> 
>     6 nnnnnnnnnnnnnnnnnnnnnnnnnn    
>     nnnnnnnnnnnnnnnnnnnnnnnnnnnn  [6 cont]

Oooooo! Nice.  What he said. At the very least, such a layout 
should be an option... and the option should be chooseable 
per instance, not just once per doc... maybe threshold settings 
for what size/number of footnotes triggers the two-page arrangement, 
rather than the usual bottom-of-current-page function.

> @  Let lenghty tables split over successive pages in a SINGLE stratum.
> That means the narrative text can continue underneath.  In the present
> model, a massive table interrupts the flow of the narrative, 
> so that the
> reader has to page forward to pick it up AFTER the table.

Indeed. I've wished for that one for years.

I also have longed and pined to create multi-column tables 
that could spread luxuriously across facing pages.
(Can we do that now, and I've just not sorted out how to?)
I hate cramming a bunch of tall, skinny columns onto one 
page-width of a small-format book. 

I want to be able to split a cell across the gutter AND 
have the horizontal table lines extend a little into 
the gutter, to enhance visual continuity --- the text 
should probably stay within the margins, and out of the 
gutter, though.  In other words, the same idea as the 
current feature where you can disable the bottom line 
of a multipage table, until the final page.

> @  Allow graphic objects to bleed off top or bottom of page, 
> or at least
> top or bottom of photo or diagram aligns with header or 
> footer and hides
> them (gains no of lines between text margin and header/footer).
> 
> 
>     hhhhhhhhhhh                     +--------------------------+
>                                     |                          |
>     +--------------------------+    |                          |
>     |                          |    |                          |
>     |                          |    |                          |
>     |                          |    |                          |
>     |                          |    |                          |
>     |                          |    |                          |
>     |                          |    |                          |
>     +--------------------------+    +--------------------------+
> 
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    xxxxxxxxxxxxxxxxxxxxxx 4 xxx
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    ___________
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx    4 nnnnnnnnnnnnnnnnnnnnnnnnnn
>     xxxxxxxxxxxxxxxxxxxxxxxxxxxx      nnnnnnnnnnnnnnnnnnnnnnnnnn
> 
> 
>     fff                                                      fff
> 
Another nice one.  I think you are asking, here, for 
controllable interaction between master-page and 
body-page elements.

While we're at it, I want some more *basic* controls 
over layering on the page, and within complex objects. 
If we can have "Bring to Front" and "Send to Back", 
why in the world can't we have INCREMENTAL "Bring forward" 
and "Send/push back".  GAWD, it's tedious to have to go 
through the "selection jump dance" just to get to an 
object that's in the middle of the stack, only so you can 
move it up or back one layer... by moving *all* the other 
objects to front or back, in *just* the right order so that 
the offending object moves *one* layer forward or back.
Sheesh!

I just *dare* anybody to try to make it sound reasonable 
that they can "Bring to Front" and "Send to Back", but 
"it's just too, too *ha-a-arrd* to implement single step 
forward and backward; it's so *ha-a-arrd* that we haven't 
been able to toss that feature in for [how many] product 
revisions".   Yeah.  Right.

Ok, so I'm ranting away from the footnote and double-page 
theme. Sue me.  Much steam has built up.   :-)

Did I miss (or snip) where you suggested letting table 
footnotes appear at the bottom of the same page as the 
reference, in multi-page tables?  I know somebody else 
had suggested that recently.   Needless to say, I concur.


Has Adobe ever put up a long list of such wish-list 
items and allowed us to vote and prioritize them?

If not, why not? I've got a hundred metric bucks here that 
says certain big corporate customers get to do exactly 
that...    (okay, okay, it's only 65 bucks in real 
dollars -- don't rub it in).

/kevin

kmclauchlan@chrysalis-its.com
somewhere in Ottawa, Ontario, Canada... 

PS: I dropped techwhirl from the cc: list. Eric would probably get touchy.

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