> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
> 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 th
--- "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, no
Glen Mazza wrote:
That hasn't changed; for 1.0 that work is still done
in the renderers (as opposed to 0.20.x which had
extensive rendering business logic in the layout
objects, the 1.0 InlineArea.renders() just made a
one-line command to a "renderInlineArea()" method in
the renderer objects).
The
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]
>
>
> BTW I don't think it's good style do ignore a veto and
> commit a change even before the discussion is resolved.
>
One of my points also:
The 'more correct' design, I believe, ...
after which he can _buy_ _som
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Question: in the maintenance branch, leader
> expansion and
> text justification is done just before a line is
> rendered
> in the LineArea.render() method. The reason for this
> is
> that it's only the renderer which knows when page
> number
> refer
Glen Mazza wrote:
But the InlineAreas aren't coupled to the
Renderers anymore--they don't make a reference anymore
to Render objects in their code.
Question: in the maintenance branch, leader expansion and
text justification is done just before a line is rendered
in the LineArea.render() method.
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> But the nice thing about our system is that they don't
> have to follow AbstractRenderer. AR implements an
> interface called Renderer, which is the bare minimum
> of methods needed to implement a FOP-compatible
> rende
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
> Does any package other than the renderers really
> *need* access to the
> renderInlineXXX methods?
No, they're now protected--furthermore, whether or not
such renderInlineXXX methods even exist within a
Renderer is now up to the renderer (th
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
>
Taking your pros into account:
on 1.) +1
Now that you mention it, I have a vague suspicion that this is somehow
related to the bug WRT basic-links I pointed out earlier (for which I was
going to send some test file, bu
2.) (This I'm less sure on) After reverting, I'd like to remove the
"render" functions within the InlineArea objects in favor of direct
function calls within AbstractRenderer:
-1
Remember one of the three basic OO principles: use
virtual methods instead of switch according to a
class marker.
T
Glen Mazza wrote:
1.) Remove the serveVisitor()
+0
2.) (This I'm less sure on) After reverting, I'd like to remove the
"render" functions within the InlineArea objects in favor of direct
function calls within AbstractRenderer:
-1
Remember one of the three basic OO principles: use
virtual meth
+0 if you feel this simplifies things.
On 22.02.2004 23:41:03 Glen Mazza wrote:
> Team,
>
> To simplify the Area Tree<-->Renderer interaction somewhat, making this
> section of the code easier to follow, I'd like to make two changes to
> the code:
>
> 1.) Remove the serveVisitor() methods...
Glen Mazza wrote:
Team,
To simplify the Area Tree<-->Renderer interaction somewhat, making this
section of the code easier to follow, I'd like to make two changes to
the code:
1.) Remove the serveVisitor() methods in AbstractRenderer.java [1], and
return to what we were using last year, that
13 matches
Mail list logo
