Re: More FM Enhancement requests (Sub Flows w/diff num of cols.)

[Jay Smith <jay@xxxxxxxxxxxx>]

Jim,

Thanks for your input.

Unfortunately, I may not have explained clearly enough that is is *FLOWS* and
*FLOWING* that is needed.  These various frames need to be ANCHORED and to
FLOW with the document, growing and shrinking as their own content grows and
shrinks, AND moving as other content in the flow grows/shrinks, AND splitting
and growing/shrinking as they hit page boundaries, etc.

I appreciate your suggestions, but what you describe, in an environment of
changing, developing content requires constant and extensive tweaking every
time there is a change.  There is also the possibility of overflowing the
frames and not realizing it, thus ending up with "non printing" content in the
overflow.

It is really a mess!

While it may not immediately seem as if my need is in line with Frame's
function and goals, I propose that it is in line with a very legitimate need
and should be within Frame's capabilities.  

The following illustration shows *ONE* "main" flow.  The text in the "A"
region cannot intrude into the "B" or "C" regions.  Same for the others. 
Growth or shrinkage in any of the three regions pushes/pulls the content along
(as it would if "B" where a typical anchored frame, but anchored frames cannot
span a page break).  Furthermore, as the content of "B" grows and shrinks, it
must flow down B1, then down B2, then down B3, and then B4.  The size of "B"
must grow/shrink as pushed/pulled by "A" and as its own content changes size. 
There is a page break in the middle of "B", such break must be "managed"
(widow/orphan, etc.).

   Page 1                  Page 2

   AAAAAAAAAAAAAA          3BBBBB  4BBBBB
   AAAAAAAAAAAAAA          BBBBBB  BBBBBB
   AAAAAAAAAAAAAA          BBBBBB  BBBBBB
   AAAAAAAAAAAAAA          BBBBBB  BBBBBB
   AAAAAAAAAAAAAA          CCCCCCCCCCCCCC
   AAAAAAAAAAAAAA          CCCCCCCCCCCCCC
   1BBBBB  2BBBBB          CCCCCCCCCCCCCC
   BBBBBB  BBBBBB          CCCCCCCCCCCCCC
   BBBBBB  BBBBBB          CCCCCCCCCCCCCC

Our books are highly structured (within the context of FM556, Win95) -- we do
everything possible to avoid exceptions, handwork, fiddling, etc.  Yet we find
that we have to deal with such situations over and over again.

Please note that the "B" region CANNOT be a TABLE because: 

a) The flow from left column to right column would mean that the table would
have to be "one text column" wide and in one or more 2-column frames [spanning
the page break, but the location of the page break keeps changing as content
changes].  

b) Such 2-column text frames would be inflexible in size.  

c) Such a 2-column text frame cannot be anchored unless it is drawn in an
anchored frame [and it must be anchored so it is not overprinted by growth or
shrinkage of "A" and "C" content. 

d) Frame does not allow text to flow from one Anchored frame to another [I
think because Frame assumes that such content will be an image which, by
definition, cannot flow between frames].

You cannot get there from here!   :<

Jay 

-- 
Jay Smith

e-mail: jay@jaysmith.com

The Press for History(tm), The Press for Education(tm), 
The Press for [Your Industry](tm), The Press for....(tm)
  On-demand printing and binding of hardbound books.
  Minimum run one copy.

P.O. Box 650
Snow Camp, NC  27349  USA

Phone: Int+US+336-376-9991
Toll-Free Phone in US & Canada:
        1-800-447-8267
Fax: Int+US+336-376-6750



Jim Drew / Ciao! Publications wrote:
> 
> Jay Smith <jay@jaysmith.com>
> 
> >ALLOWING "SUB-FLOWs" WITH DIFFERENT NUMBER OF COLUMNS THAN MAIN FLOW.
> >
> >What is needed is the ability to change from one quantity (main flow) of
> >columns to another quantity (sub flow) and back again (main flow).  Text in
> >the first part of the main flow flows and fills/balances up to the point of
> >change, just as it would prior to a page spanning illustration.  Additions to
> >the first part pushes the point of change down the book.
> 
> This is mostly doable in the current version:
> 
> 1. Create your two-column tframe
> 2. At the point on the page where you want it to change to 3-column,
>    put the IP and select Format>Customize Layout>Split Text Frame
> 3. Where you want it to change back, do the same thing again
> 4. Select the middle tframe, Graphics>Object Properties, and change the
>    number of columns
> 
> It's even easier if you a given entire page to have the odd layout, of
> course -- no splitting needed.
> 
> Now, if you want this special tframe setup to move *with* your text, there
> you're out of luck.  That seems an extreme example of override formatting,
> quite contrary to the way Frame thinks of pages (layouts into which text
> and objects flow; the flow doesn't carry the layout along with it).
> 
> Top of Column para anchoring will help somewhat.  May some kind of master
> page setting based on the first para tag in the main flow on a page could
> be done, but I can't imagine it being pretty.
> 
> >TAG APPLICATION BASED ON TEXTUAL CONTENT.
> >
> >An enhanced find/replace function.  We current write this in FrameScript.
> >Find all occurrences of ("xxxitalicon" and "xxxitalicoff") or "xxxheadline"
> >(i.e. some 'unique' character string) and apply either a character tag
> >(between the 'on' and 'off') or paragraph tag, as desired.
> 
> Most of what you want is in the current ability to search for a text string
> and then paste a previously Edit>Copy Special>Character Format (or
> whatever).  Still, since that pastes the format rather than the tag -- and
> thus makes overrides -- there's definite room for improvement.
> 
> ------------------------------------------------------------------------------
> Jim Drew                                                ciaopubs@earthlink.net
> B3(v)h+ t e cd s k g+(p) rv q p                            Secretary, IAGLCWDC
> ------------------------------------------------------------------------------
> Marc Lynx .sig Quote (01/18):       http://home.earthlink.net/~cfmdesigns/Sig/
> ------------------------------------------------------------------------------

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