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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
