You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Glen Mazza <gr...@yahoo.com> on 2003/07/21 19:05:51 UTC
[VOTE] Re: LayoutStrategy
--- Victor Mote <vi...@outfitr.com> wrote:
> 1. In other words, I would
> like to have permission to temporarily treat Driver
> as either a singleton or
> a location for static constructs, which can be used
> to control the
> interaction between the various modules, so that I
> can move that logic out
> of the modules themselves.
+1 Your direction of where you want the processing
logic to be--away from the non-apps packages and into
apps, is the exact *opposite* of where I want things
to be headed! Still, I don't think you should be
hobbled by needing to be worried about multithreading
issues at this time--come out with your best design
as-is.
Multithreading, to my limited brain, appears overrated
for FOP. For single-CPU processing, multithreading
AFAIK isn't going to help. For multiple-CPU,
lotsa-reports-getting-generated-every-minute, that is
where Cocoon and/or Servlet Containers kick in, and it
is *they* who will do the multithreading, correct?
(Would they even *want* us to do multithreading? I
don't know. If both FOP and those services which call
FOP do multithreading, that might have a detrimental
impact.)
>
> 2. I will then proceed to clean up lines between
> modules. Success will be
> measured by the ability to do the following things:
> 1) to build without
> compile errors the control and fo classes, and one
> entry point to Layout
> (for Control) by themselves (i.e. no fo classes
> needing layout or area
> classes), and
Doesn't FOTreeBuilder pipe messages to area tree
processing?
> 2) to build without compile errors the
> control, area, fo (?)
> and rendering classes (i.e. no area or rendering
> classes needing layout
> classes).
>
> Here is my +1.
>
-1. I wouldn't make a commitment at this time that no
object from most packages needs referencing to
another. To accomplish this goal--no area or
rendering classes needing layout classes, etc.--you
may need to rip out so much functionality into the
control classes, make private variables public for
control to access, etc. That will cause spaghetti
code and code bloat. There goes the elegance!
(1) and (2) are noble goals to be strived for, but not
to the point of giving the Control classes inordinate
access to the member variables/functions of all the
packages.
But I *highly* encourage better judgments, i.e. the
other committers, to weigh in on this.
> 3. Create an AbstractLayoutStrategy class which will
> encapsulate the
> interaction between Control and Layout. Make our
> redesign layout subclass
> this. (This may actually get done before item 2, as
> it may make item 2
> easier to do). This supposes that LayoutStrategy,
> and, by implication, the
> possibility of multiple layout engines, is a good
> thing. Although I have
> discussed this before, it has never been canvassed.
> Here is your chance to
> agree or disagree.
>
> Here is my +1.
>
-1 (as stated). I think an AbstractLayoutStrategy
should not have anything to do with the Control, the
Control should be the same for all LayoutStrategies.
The latter is of most value to the user--this LS
prints better, this one prints faster, etc., etc.--not
this LS-CS method doesn't involve the FOTreeBuilder
knowing about Area Tree creation, while this LS-CS
method does, etc. That's irrelevant to the user.
Multiple, pluggable LayoutStrategies work best when
there is a predefined begin and end to them within the
application. Remember that they may also encapsulate
the rendering portion (far right end), so Control (far
left end) is the *only* thing currently we can keep
constant between the multiple layout strategies. (As
we standardize more, perhaps we can even pull out FO
Tree Building creation of our the LayoutStrategies as
well.)
However, from (2) above, if your control classes get
so much into the "innards" of each of the packages,
now you have to bring the control classes into the
LayoutStrategies. That's my current concern.
> 4. Make the layout logic in the maintenance branch
> conform to the above,
> subclassing the AbstractLayoutStrategy. I won't
> check this work into the
> repository until it is complete, as it bears the
> risk of failing. I have
> been amply warned by Joerg that this step will be
> difficult, maybe
> impossible, but I feel obligated to try. I will
> either come back with 1) a
> way to unify our development efforts, or 2) greater
> humility and greater
> knowledge of layout. Neither are bad results.
> An
> affirmative vote here
> implies that retaining our maintenance branch layout
> (at least in the short
> term) is a good thing. I want to make it clear that
> this is not intended to
> derail or distract from the new layout scheme. I
> believe (but acknowledge
> that I am possibly wrong), that adopting this plan
> gets us more quickly to
> the place where we can work on the new layout, and
> gives us many other
> benefits as well. Right now, for example, I need
> some font work done. I
> don't feel free to do it in the maintenance branch,
> but that is the only
> branch I can use to get any output at all for my
> projects. Each of us has a
> similar story. I would like to get to the place
> where one doesn't have to
> feel guilty about working on other aspects of FOP,
> and where our support
> efforts are split/duplicated.
>
> Here is my +1.
>
>
+0. By the time 1-3 are done, we may be very advanced
with 1.0, so even you may not agree with going back
and retrofitting the 0.20 version (i.e. you'll be able
to test your fonts on trunk, etc.). But if it helps
you, go ahead.
Glen
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: [VOTE] Re: LayoutStrategy
Posted by Victor Mote <vi...@outfitr.com>.
Glen Mazza wrote:
> Ideally, that would be mostly it. My current
> design-thinking is that once flow of control leaves
> the apps package, it does not return until has a full
> document finished.
I think we are on the same page here, or at least I see no conflict. I don't
think of the control classes as being part of apps. apps would be one of
several ways to instantiate and access control. The only reason I want to
put anything in Driver is that it *is* control for now. Please, *please*
feel free to refactor the stuff I put in there to better places as you see
fit. I was hoping to get that straightened out before starting the Layout
Strategy stuff, but I think you and Jeremias will do The Right Thing as you
move forward.
> In general, I would then +1 you going ahead with your
> design--providing J, J & P are not shy in opening up
> their mouths when needed (I certainly won't be! ;)--
> If and when it proves more code efficient to place
> certain parts of Control in different packages, we can
> look at doing so later.
I'm counting on getting corrected if I need it. And I definitely don't want
this stuff to live in Driver forever. I just don't see the big Avalonized
picture yet, and probably won't until it is close to complete. Thanks for
the response. BTW, I really didn't mean to press you for the response -- I
just thought I had better get moving. I am very eager to at least test the
idea of getting the main branch working again so that we can start fixing
fonts, graphics, FO tree, etc. in one place.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: [VOTE] Re: LayoutStrategy
Posted by Glen Mazza <gr...@yahoo.com>.
--- Victor Mote <vi...@outfitr.com> wrote:
>
> Hmmm. I'm not sure how to interpret the silence. I'm
> going to press on with
> my proposals unless I get some sort of substantive
> reply.
>
> Victor Mote
>
Victor,
I apologize for the silence--I did read your email on
Sunday and more thoroughly yesterday. I was planning
on adding more to what you wrote tomorrow--I've been
too busy and/or worn out this week to give a useful
response to your proposals. But let me try now:
1.) BTW, I was happy with your explanations to my
concerns I raised while voting--in particular your
assurances that Control will not be getting too much
into each of the classes. We seemed to share many of
the same concerns.
2.) In general, much of the system I am not versed in
yet, so I don't want to stop you with your redesign
ideas--however, I do expect Jeremias, Joerg, and Peter
to open up their mouths when they see something going
wrong. However, for me, I can't beat a plan with no
plan, so I'm not going to slow things down by trying.
3.) Offhand, working on my own, (and before realizing
that I need to change a lot of what I did because of
my mistakes with the parsers, as well as overlooking
several other things), I was able to get rid of the
Driver class entirely, as well as the Starter classes.
The cost was only a slightly expanded apps.Fop class
(200 lines) and a larger (600-700 line) FOTreeBuilder.
Due to the large "handshaking" between FOTreeBuilder
and Driver, I also found that adding some code to the
former usually allowed me to remove much more code
from the latter. All in all, it seems to be pretty
code-efficient.
4.) I'm aware of your horrors of letting an
FOTreeBuilder know the render type, etc. I agree with
you now on that. My thinking now is to switch to a
new fo.XSLFOProcessor class which includes, as a child
class, the full definition of a
fo.XSLFOProcessor.FOTreeBuilder class. Within
fo.XSLFOProcessor but outside of its FOTreeBuilder
definition, is much the same control-type code
currently in Driver (renderer information, etc.) This
way we still get the lines of code efficiency without
breaking so much the OO design in terms of letting
FOTreeBuilder know about everything.
What would be in the apps package if we had such a
XSLFOProcessor class? Hopefully, just something
simple like this in apps.Fop:
XSLFOProcessor xslfoProcessor = new XSLFOProcessor();
bos = new BufferedOutputStream(new
FileOutputStream(options.getOutputFile()));
xslfoProcessor.setOutputStream(bos);
xslfoProcessor.setInputHandler(inputHandler);
xslfoProcessor.run();
bos.close();
System.exit(0);
Ideally, that would be mostly it. My current
design-thinking is that once flow of control leaves
the apps package, it does not return until has a full
document finished.
5.) The drawbacks, however, of what I'm mentioning
above is that your Control is taking care of a lot
more than just tree building--layout, rending, area
tree, etc. Again, though, I don't know much about
those areas yet to comment constructively on them--so
I'm reluctant to stop your full solution just because
I may have different ideas on the first 20%.
In general, I would then +1 you going ahead with your
design--providing J, J & P are not shy in opening up
their mouths when needed (I certainly won't be! ;)--
If and when it proves more code efficient to place
certain parts of Control in different packages, we can
look at doing so later.
Thanks,
Glen
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: [VOTE] Re: LayoutStrategy
Posted by Victor Mote <vi...@outfitr.com>.
Victor Mote wrote:
> Because we are such a small group, I am hoping to get unanimity on all of
> the points. If I have addressed your concerns with the above
> clarifications,
> please consider changing the -1 votes to a zero (or better). If
> anybody has
> serious reservations, I need to think about doing this in a local fork
> instead of in the repository. Obviously, I'd like to avoid that.
Hmmm. I'm not sure how to interpret the silence. I'm going to press on with
my proposals unless I get some sort of substantive reply.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: [VOTE] Re: LayoutStrategy
Posted by Victor Mote <vi...@outfitr.com>.
Glen Mazza wrote:
> --- Victor Mote <vi...@outfitr.com> wrote:
> > 1. In other words, I would
> > like to have permission to temporarily treat Driver
> > as either a singleton or
> > a location for static constructs, which can be used
> > to control the
> > interaction between the various modules, so that I
> > can move that logic out
> > of the modules themselves.
>
> +1 Your direction of where you want the processing
> logic to be--away from the non-apps packages and into
> apps, is the exact *opposite* of where I want things
> to be headed! Still, I don't think you should be
> hobbled by needing to be worried about multithreading
> issues at this time--come out with your best design
> as-is.
OK, I need to clarify this. In general, I do not want a bunch of logic moved
from non-apps to apps. The only pieces that need to be moved are those that
control the flow between the various modules. So, for example, I don't want
the fo module deciding to fire off a layout manager, which is what we have
now. I want the flow of control to return back to Control (for now, this is
Driver), which will then decide, because it knows what LayoutStrategy is in
play, and what renderers are in play, and perhaps what user-selected items
are in play, whether *it* should fire up Layout, continue building more
pieces of the FO tree, etc.
> > 2. I will then proceed to clean up lines between
> > modules. Success will be
> > measured by the ability to do the following things:
> > 1) to build without
> > compile errors the control and fo classes, and one
> > entry point to Layout
> > (for Control) by themselves (i.e. no fo classes
> > needing layout or area
> > classes), and
>
> Doesn't FOTreeBuilder pipe messages to area tree
> processing?
I haven't seen that one, but I have seen some other area tree stuff in the
FO processing. IMO, we should be able to build an FO tree without knowing
anything about layout or area tree, so this is stuff that will be, in the
plan I have proposed, moved to one of those modules.
> > 2) to build without compile errors the
> > control, area, fo (?)
> > and rendering classes (i.e. no area or rendering
> > classes needing layout
> > classes).
> >
> > Here is my +1.
> >
>
> -1. I wouldn't make a commitment at this time that no
> object from most packages needs referencing to
> another. To accomplish this goal--no area or
> rendering classes needing layout classes, etc.--you
> may need to rip out so much functionality into the
> control classes, make private variables public for
> control to access, etc. That will cause spaghetti
> code and code bloat. There goes the elegance!
If there are needed exceptions to this rule, I'll make a note of them, and
explain why they are needed. I can't think of an instance where rendering
should need access to layout classes. It needs access to the area tree. If
the area tree isn't complete, it should be completed by layout before
rendering knows to do anything with the area objects in question. Are you
thinking of something specific? I definitely agree that we don't want to rip
functionality into the control classes (see discussion above), and I
definitely don't want spaghetti. In fact, I am trying to remove what I
consider to be a bit of spaghetti. Right now, for example, the fo module
starts layout. If you go to LayoutStrategy, the only way it can know what to
do at that stage is to carry around information about layout. I don't see a
reason for that. IMO, the FO module should be able to build a PageSequence
object and return it, and not care who or what it will be used for.
If you think of FOP as a pipeline, the stages are as follows:
Control
|
|
--------------------------------
| | |
| | |
Parsing/ | |
FO Tree | |
Building Layout Rendering
| | |
| | |
--------------- -------------- ---------------
| | | |
| | | |
XSL-FO Input FO Tree Area Tree Output
So we have 4 data points, if you will (maybe there is a technical CS term
for this), and 3 processing pipes between them. Each of the processing pipes
needs to have access to the data module immediately before and immediately
after it. Apparently in the past, the processing was along the model above,
but without the Control module, which made it monolithic, i.e. the FO Tree
had to be completed before Layout could start. If I understand Joerg, this
was changed in favor of our current system. I don't want to go back to
monolithic, but I think the right way to handle the concurrency issues (i.e.
trying to lay out and render output before we are entirely through with
parsing the FO tree), is with the Control layer on top to manage the
sequence of processing.
If I get into it & find out it can't be done without making things messier,
I'll be the first to back out.
> (1) and (2) are noble goals to be strived for, but not
> to the point of giving the Control classes inordinate
> access to the member variables/functions of all the
> packages.
I envision the flow to be as follows: Control tells FO to build a
PageSequence object and return it. Control then passes the PageSequence
object to AbstractLayoutStrategy. If the LayoutStrategy subclass processes
eagerly, it will return control to Control as it completes each page, and
Control will tell Render to render it. Control can also decide, for example,
that it doesn't want to Render yet, because the requirement is to render an
optimized PDF which needs to be written in a more appropriate order. At some
point the layout engine says "I have no more pages to send you" and it is
done. This is same order that processing currently occurs, but we can now
add some more smarts to it, while still keeping the modules and concerns
separated.
So I agree that Control doesn't need to be given access to the member
variables/functions of the packages. It just needs to see the high-level
classes in each package.
> > 3. Create an AbstractLayoutStrategy class which will
> > encapsulate the
> > interaction between Control and Layout. Make our
> > redesign layout subclass
> > this. (This may actually get done before item 2, as
> > it may make item 2
> > easier to do). This supposes that LayoutStrategy,
> > and, by implication, the
> > possibility of multiple layout engines, is a good
> > thing. Although I have
> > discussed this before, it has never been canvassed.
> > Here is your chance to
> > agree or disagree.
> >
> > Here is my +1.
> >
>
> -1 (as stated). I think an AbstractLayoutStrategy
> should not have anything to do with the Control, the
> Control should be the same for all LayoutStrategies.
I agree. I hope nothing I said implied otherwise. Now,
AbstractLayoutStrategy has some control features of its own, but those are
invisible to Control. ALS might decide that it follows a patient processing
model, and that it doesn't want to pass pages back to Control until it is
sure it has seen enough of the layout that nothing needs to be changed. The
Control portion of the work is intended to cleanly separate the modules so
that there is only one point of contact.
> The latter is of most value to the user--this LS
> prints better, this one prints faster, etc., etc.--not
> this LS-CS method doesn't involve the FOTreeBuilder
> knowing about Area Tree creation, while this LS-CS
> method does, etc. That's irrelevant to the user.
It is irrelevant to the user, but it makes a huge difference to the
developers, which in the long run is *very* relevant to the user. It hurts
my head to think of implementing LayoutStrategy without first cleaning up
the interfaces between the modules.
> Multiple, pluggable LayoutStrategies work best when
> there is a predefined begin and end to them within the
> application. Remember that they may also encapsulate
Yes, so encapsulating them cleanly is very important.
> the rendering portion (far right end), so Control (far
No, IMO Layout does not need to encapsulate Rendering. It needs to *know*
some things about the context in which rendering will occur, but that is
*only* so that it can find appropriate resources, like fonts.
> left end) is the *only* thing currently we can keep
> constant between the multiple layout strategies. (As
One of the reasons why I wrote the diagram above was to fit your right and
left model (which, BTW, is exactly how I think of it as well). FWIW, I don't
view Control as being on the far left, but rather orthogonal to the others,
so I have drawn it on top.
I strongly disagree that Control is the only constant between different
Layout Strategies. Since only needs to see FO Tree and Area Tree, those are
the only two that need to be addressed. Both of them are entirely useable
with any Layout Strategy.
If done properly, I think LayoutStrategy allows Peter to bring his pull
parsing system in as a LayoutStrategy. It might require a flag in the LS
that turns off FO Tree building, but essentially, he can fire up parsing
directly from his LS, then manage his pull parsing stuff and build his area
tree.
> we standardize more, perhaps we can even pull out FO
> Tree Building creation of our the LayoutStrategies as
> well.)
>
> However, from (2) above, if your control classes get
> so much into the "innards" of each of the packages,
> now you have to bring the control classes into the
> LayoutStrategies. That's my current concern.
Again, that is not the intent.
> > 4. Make the layout logic in the maintenance branch
> > conform to the above,
> > subclassing the AbstractLayoutStrategy. I won't
> > check this work into the
> > repository until it is complete, as it bears the
> > risk of failing. I have
> > been amply warned by Joerg that this step will be
> > difficult, maybe
> > impossible, but I feel obligated to try. I will
> > either come back with 1) a
> > way to unify our development efforts, or 2) greater
> > humility and greater
> > knowledge of layout. Neither are bad results.
> > An
> > affirmative vote here
> > implies that retaining our maintenance branch layout
> > (at least in the short
> > term) is a good thing. I want to make it clear that
> > this is not intended to
> > derail or distract from the new layout scheme. I
> > believe (but acknowledge
> > that I am possibly wrong), that adopting this plan
> > gets us more quickly to
> > the place where we can work on the new layout, and
> > gives us many other
> > benefits as well. Right now, for example, I need
> > some font work done. I
> > don't feel free to do it in the maintenance branch,
> > but that is the only
> > branch I can use to get any output at all for my
> > projects. Each of us has a
> > similar story. I would like to get to the place
> > where one doesn't have to
> > feel guilty about working on other aspects of FOP,
> > and where our support
> > efforts are split/duplicated.
> >
> > Here is my +1.
> >
> >
>
> +0. By the time 1-3 are done, we may be very advanced
> with 1.0, so even you may not agree with going back
+100
> and retrofitting the 0.20 version (i.e. you'll be able
> to test your fonts on trunk, etc.). But if it helps
> you, go ahead.
My needs are such that I will gladly trade performance for better output, so
bringing the old layout along helps me directly only until a better layout
exists. However, I think it will be useful for:
1. demonstrating LayoutStrategy
2. keeping continuity -- when the next release comes out, users can use
something familiar until the are ready to switch to something that may be
better
3. performance -- some of our users won't want to spend the extra machine
cycles & memory for better output
4. quality control -- it is likely that, for a while, our new layout will
need some heavy maintenance -- the old one is a useful fallback for users
during that period
Because we are such a small group, I am hoping to get unanimity on all of
the points. If I have addressed your concerns with the above clarifications,
please consider changing the -1 votes to a zero (or better). If anybody has
serious reservations, I need to think about doing this in a local fork
instead of in the repository. Obviously, I'd like to avoid that.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org