--- "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 ones.) > 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. Glen *That of a house plant.
