Glen Mazza wrote:

> I'm inclined to keep 0.20.x out of 1.0.  There's too
> much a risk that merging the two apps into one is
> going to create a bunch of mush.  I don't have any

First, this part of it is a settled issue. If the layout logic can
successfully be extracted into a Layout Strategy, it will be. I hate mush
more than most, and if it turns out to be mush, I won't commit it. If I
commit it, and you think is is mush, we'll talk about it then.

> problem with maintaining both a development and a
> release version--that's just about how every other
> Apache team operates.

Well, at least this is consistent with our discussion on the other thread.
<sarcasm>Why write one modularized application that can be used 2 (or more)
ways, when you can maintain two sets of code instead? Never mind that the FO
Tree, Area Tree, Renderers and Control are all (or should be made so)

> Having studied both the PDF Renderer in the old and
> the new architecture, and the AWT Renderer in the old
> (so I could implement some of it in the new)--the
> layout is incompatible with the Area Tree and the
> Renderers.  You'd have to bring those in as well.

I am familiar with the problem. I will never consider bringing in the old
Area Tree or Renderers. (Actually, I will, only on my machine, as a first
step in the refactoring process, but that will never be committed. By the
time it gets committed the layout code will be refactored to use the new
classes.) The bottom line is that there is some layout logic in there that
should be extractable, and that should be conformable to the new
architecture. I know this is possible. My only concern is whether it is

> Also, it is clear that the inventors of the 1.0 layout
> system were quite knowlegable of the 0.20.x
> system--they improved on it--for the 10% of it I
> understand, it appears to be in every way a better
> architecture (indeed, I would call *it* the 'simple'
> package)--it just needs more work to be complete.

I agree that the new architecture is better (primarily because it is more
modularized :-) ). OK, so offer a better name. I actually started out with
"naive", but thought that was unnecessarily pejorative.

> IMO multiple layout strategies have a value in two
> cases:
> (1.) Where (a) layout strategies follow different
> philosophies, say one LS is for ultra-detailed
> graphics, while the other is fast document generation,
> and (b) these strategies are so significant that they
> can't be handled by compiler switches.
> or
> (2.)  To allow/encourage committers like Peter, on
> their own, to come up and test alternative designs
> that may be better without needing to recode an entire
> app.
> 0.20.x isn't satisfying these cases--because 1.0 is
> designed to be better than it--(although, if/when
> Peter returns, Alt-Design might).

Answer 1: There may be more than these two cases, but I agree that both of
these are valid.

Answer 2: I am not eager to introduce compile-time changes into the mix, but
there are possible runtime configuration options that may be useful here.

Answer 3: IMO, 0.20.x falls into the first of these cases.

> Like you, I want to get more people--both developers
> and users--into 1.0.  Perhaps another way of doing
> that would be for you to sink your teeth into the 1.0
> renderers--PDF, and feel free to lend me a hand in
> AWT.  PDF might be 70% of our audience.  If we can get

I cannot begin to tell you how eager I am to jump into renderers, layout,
fonts, etc. At no time have I been free to do that. When I started into this
project 15 months ago, I was pretty soundly slapped down for trying to make
improvements to the maintenance branch. Well, if you are trying to get work
done, and the impediment is layout, then working on the redesign layout is
the way to go. But if your problem lies in some other place, it is pretty
frustrating to not be able to improve that other area. I am convinced that
we have lost developers simply because of this ugly dilemma. So my efforts
are bent on getting a usable release from the trunk as quickly as possible.
I view my current path as being the best way to do that.

> 1.0 PDF reasonably up to the level of 0.20.x--it's

Well, I think Jeremias and Keiron need to respond to this. They have both
objected to my use of the term "merge" to describe what needs to happen
here, but I have pointed out repeatedly that there are several areas where
our maintenance branch is better than the trunk, and those improvements have
to be brought forward. Configuration bit me a few weeks ago. You are
right -- we have some places other than layout where work is needed before
we can release out of the trunk. If I can get the (old) layout brought
forward, I'll go to work on the other pieces that are needed as well. In the
mean time, anything you and Joerg (and any others) can do on the other
modules will get us there faster. And I don't mean to discourage anyone from
working on "layoutmgr" -- that is the future, if we can get past the

> maybe halfway there already--we will then have a
> pretty good 1.0 user base.  Also, the work that you
> do for the PDF renderer--bouncing back and forth
> between layout, the area tree, and its renderer--also
> helps me with AWT because much of it is the same code.

I don't understand what the last sentence is saying.

Victor Mote

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to