New architectural ideas - galley slaves, etc.

["Peter B. West" <pb...@powerup.com.au>]

Karen,

I like the sound of these ideas very much.  A few things have occurred
to me arising from your posting.

The galley thread you write of can be thought of as a flow server, or
perhaps as a galley slave.  You mention the need to control the feed
from this thread.  It seems to me that the flow server should be
governed by specific layout related requests within some context or
contexts.  That context may require a third actor, rather than a
function of the layout manager.  The configuration of pages with their
hierarchy of reference-areas seems a relatively uncomplicated activity
which might usefully be thought of as a process in its own right, in
addition to the flow server and the layout process.

You wrote also about the flow thread returning, in the case of a two
column layout, a single column sufficient to fill the page.  I have
thinking along the same lines.  In this case, at some point in the page
layout thread, a request is issued for so many column inches of
formatted flow.  Where would such a request originate?  It is
page-specific, and it has to happen at some point after the region-body
and subsequent span-reference area has been defined.  The
span-reference-area provides the context for the
inline-progression-dimension of the galley, for the duration of this
span-reference area.

Once this is defined, a specific column can be requested of the flow
server; specific in terms of i-p-dimension and total length required to
fill a page.  This request can be fully met, or it can be partially met
because the flow is exhausted, or because the flow server has
encountered a changed span condition.

The change in span specifier is interesting because it occurs as a block
trait, and yet it generates a new span-reference-area almost back at the
page level, and forces a column balancing act.

Is the area.split operation "free"?  I.e., can the galley splits that
you are talking about occur without impact on the preceding and
following galley flows?  In one obvious case, no.  When the split is
effectively a column break on the last column of a page, and therefore a
page break, hyphenation would in general be precluded.  If a hyphen
occurs at the split point, the changes propagate both backwards and
forwards.

The forward changes are simple enough - restart the galley slave at a
new point in the fo tree.  The extent of the backward changes is
unpredictable, and depends on the complexity and precision of the layout
that is being attempted.  In the most simple-minded case, the last line
of the current column must be re-laid with, potentially, a lot of white
space.  In the most complex case, involving the fine-tune character
spacing properties that are available, the whole page is relaid to
distribute the extra white space as unobtrusively as possible.

Such operations look like variations of the normal galley slave
processing, with a different set of parameters, or traits.  If
necessary, FOP could define its own traits for internal use in the
trickiest of these format tuning operations.  The virtue of that
approach is that, if some such proved useful in specifying finicky
formatting preferences, they might eventually make their way into the
specification for use by page designers.

In any case, the basic division of labour is maintained.  The galley
slave lays out chunks of the flow according to the parameters passed in
requests from some page-level actor; region manager or layout manager.

Peter
-- 
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org