--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> The problem is that text justification and leader
> expansion
> is a layout task, not a renderer task.

Absolutely, much of the logic needs to be in the
layout objects, which interface with the Renderer
classes, indeed activate them.  That's fine, normal
processing, makes rendering easier.  (In 0.20.5,
LineArea is a layout package object, but in 1.0 the
InlineArea subclasses are Area objects, not LM package

> And text
> justification
> can't be done during the normal layout pass because
> of
> page number references, it has to bedeferred until
> the
> references are resolved.

Either the LM classes do this processing, or the
Renderers do it.  Either way is fine for me--I'd just
rather keep the *Area* objects inert--but if they *do*
do the processing, have them do it, not just a
one-line immediate bounce-back to
now-gotta-make-public  LM or Renderer methods.  This
is torture trying to trace.

> There is a reason why the maintenance code is as it
> is.

We can always go back when needed/beneficial.  Right
now, I'm trying to fix the layout bugs (where our
example FOs render fine in 0.20.x but not-so-fine in
1.0--I'm currently focusing on the extra-space issue
in 1.0) and the bouncebacks between classes is causing
my brain to overheat.  This simplification, even if
temporary, drops the average IQ needed to understand
the Renderer classes perhaps 30 points, more into my
range*, hopefully opening the door for more developers
to start filling out these renderers.


*That of a house plant.

Reply via email to