-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 these
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
--- 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
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
snip /
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:
quote
The 'more correct' design, I believe, ...
after which he can _buy_
--- 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
references are
-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, but
--- 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 (the
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
snip /
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
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.
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
+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...
snip/
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
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.
13 matches
Mail list logo
