layout strategy packaging

[Victor Mote <vi...@outfitr.com>]

Optimistically assuming for a moment that I can get the maintenance branch
layout ported into the trunk world (I can almost hear Joerg's "bwahahaha"
all the way across the Atlantic), there are some naming and packaging issues
that need to be addressed. I ask them now because I can save myself some
trouble by doing them right the first time.

Question 1: Naming of the LayoutStrategies. Right now, I have tentatively
named the trunk layout system "layoutmgr" since that is the directory that
it lives in, and the maintenance branch layout system "simple". Since these
are names that users will eventually work with when selecting a layout
strategy for processing, they probably deserve some thought, and I would
welcome comments.

Question 2: I think it only makes sense to have the layout code live in a
package with the same name as itself. For example the "simple" LS should
live in a package called "simple".

Question 3: There are several options for the directory/package structure:

  Option 1
    apps
    area
    ...
    layout   <--------- code shared among LSs
      hyphenation
    layoutmgr
    ...
    simple
    ...
    viewer

Option 2
    apps
    area
    ...
    layout
      hyphenation   <--- shared
      layoutmgr     <--- not shared
      simple        <--- not shared
    ...
    viewer

Option 3
    apps
    area
    ...
    layout  <------- code shared among LSs
      hyphenation
    ls      <------- could be renamed
      layoutmgr
      simple
    ...
    viewer

There are of course other options, but the above seem to make the most
sense. Option 1 has the virtue of leaving layoutmgr where it is, but I
prefer either 2 or 3 in the long run for clarity. I prefer 3 over 2 because
it keeps the LS directories separate from any shared subdirectories (like
hyphenation), but I don't feel strongly about it.

If layoutmgr needs to be moved/renamed, it can wait indefinitely, certainly
until after I can demonstrate the need. All I need right now is a place to
put the code coming over from maintenance so that I can get packages and
imports correct.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: layout strategy packaging

[Victor Mote <vi...@outfitr.com>]

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)
identical.</sarcasm>

> 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
feasible.

> 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
present.

> 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: layout strategy packaging

[Glen Mazza <gr...@yahoo.com>]

Victor,

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
problem with maintaining both a development and a
release version--that's just about how every other
Apache team operates. 
 
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.  

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.

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).

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
1.0 PDF reasonably up to the level of 0.20.x--it's
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.

Glen


--- Victor Mote <vi...@outfitr.com> wrote:
> Optimistically assuming for a moment that I can get
> the maintenance branch
> layout ported into the trunk world (I can almost


__________________________________
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