Resend: FW: what does "flow" of flow object or flow object tree mean?

["Reynolds, Gregg" <greynolds@xxxxxxxxxxxxxx>]

Tried to post this yesterday but saw no result so I'm reposting; sorry
if the original shows up.

A few points I didn't think to add to my original post:  

"Pouring" a stream of flobs into a receptacle flob (such as a paragraph
or page region) may in some cases cause the dimensions of the receptacle
to change.  A paragraph will expand to hold as much text as possible
within the constraints of its containing area.  A column area will
stretch to hold as many paragraphs as possible.  Etc.  So the fluid
metaphor must be adjusted to account for flexible containers.  The
observation that liquids take the shape of their containing vessels
implies a certain fixity regarding the containing vessel; for our
metaphor we need to imagine containers of a flexible material.
Rectangular water balloons?

Also note the mixing of metaphors: "flow object tree".  We could say
"flow object river system" but that would be a bit much.  Nonetheless,
"tree" as used by the DSSSL spec is clearly a compute-centric term; I
doubt very much if any graphic designer thinks "tree" when pondering a
document design.  A structural term more in keeping with the fluid
metaphor would be helpful, but I haven't been able to come up with one
yet.  This, by the way, is one of the biggest problems with the language
of the DSSSL spec: it often mixes user-centric language (areas,
dimensions, styles, etc) with computery stuff like trees, nodes,
behaviours, and processing.


> -----Original Message-----
> From:	Reynolds, Gregg 
> Sent:	Monday, July 06, 1998 9:41 AM
> To:	'dssslist@xxxxxxxxxxxxxxxx'
> Subject:	RE: what does "flow" of flow object or flow object tree
> mean?
> 
> "Flow" is the central organizing metaphor of the DSSSL spec.
> Unfortunately the language of the spec doesn't always make this clear,
> since it seems (to me, at least) to want the metaphorical aspects of
> its own language go away.
> 
> Actually it might be more accurate to say that "liquid" provides the
> metaphors of greatest explanatory power for talking about typesetting,
> page layout, and document structuring.  Liquid flows, and it takes the
> shape of its container.  Text flows into paragraphs, for example, and
> takes the shape of the container by organizing itself to fit the
> dimensions of the paragraph - it breaks itself into lines
> appropriately, adjusts wordspacing and letterspacing, etc.  One might
> picture this by imagining a vessel of text drizzling its contents into
> paragraph moulds.  A designer should be able to specify a document
> design (I'm referring to the rendition here, not the abstract
> "document") solely by relying on this complex of metaphors.  All the
> procedural, computery stuff, such as line break algorithms etc.,
> should be hidden behind the metaphor.  
> 
> Of course it gets a little more complicated, but the same basic
> metaphor still works.  Not all "things" suggested by the metaphor are
> explicitly modeled in DSSSL.  Text lines are a good example.  The
> DSSSL text repeatedly refers to lines of text, but does not provide a
> textline flow object class.  Instead such lines are implied by
> paragraphs, since paragraph implies line break.  In fact, text lines
> are central to the typesetting model in DSSSL; flow object classes are
> categorized into "inline" and "display" types based on how they flow
> into the "current" area.  Those areas that flow smoothly, as it were,
> into a textline area, are called inline.  Thus in the construction of
> a paragraph flow object (flob), text is flowed into the paragraph,
> meaning, each raw character, in order, is "flowed" into a character
> flow object (which gets us the dimensions, style, etc of the
> character), which in turn is flowed (or appended) into the line of the
> paragraph.  Since character flobs are of type "inline", this flow will
> be "smooth"; the line will not be broken because of the character
> being flowed. Instead the line breaks will be determined by the
> paragraph shape.  If a "display" flob were to be inserted into the
> stream (note the metaphor) of text, it would not flow smoothly into
> the current line; it would instead interrupt the flow, causing the
> line to be terminated and triggering the start of a display area.
> 
> Another key point to remember is that flow is recursive.  Text
> characters flow into character flobs, which flow into paragraphs,
> which flow into columns, which flow into pages, etc.  Also, not all
> flob classes specified by the standard will result directly in printed
> markings on the page.  Some, such as synchronization flobs, are meant
> to express relations.  And some flobs are simple (char, paragraph)
> while others are complex, by which I mean they serve to coordinate
> other flobs.  That is, they serve to direct various "streams" of flobs
> into other flobs.  Examples include the page model and column related
> stuff.  This is where ports and streams come in.  It does get a little
> complicated, but the organizing metaphor still works and actually
> simplifies things, at least for me.
> 
> A good test to determine if you've grasped the metaphor is the
> sideline flow object.  It's a fairly simple concept, but the language
> of the standard is quite obscure IMHO.  If you can figure it out then
> you've got a pretty good handle on how the language of the standard
> works.  I hope.
> 
> Best of luck,
> 
> Gregg
> 
> -----Original Message-----
> From:	Lee, Kyong Ho [SMTP:lkh@xxxxxxxxxxxxxxxxxxxx]
> Sent:	Sunday, July 05, 1998 8:27 AM
> To:	dssslist@xxxxxxxxxxxxxxxx
> Subject:	what does "flow" of flow object or flow object tree
> mean?
> 
> I've read the dsssl specification document.
> Please tell me why a layout construct is called flow object in Style
> language.
> what does "flow" of flow object or flow object tree mean?
> 
> 
> 
> 
> 
> 
>  DSSSList info and archive:
> http://www.mulberrytech.com/dsssl/dssslist


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist