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 Victor Mote <vi...@outfitr.com> on 2003/04/23 10:53:46 UTC
toward reunification
FOP compatriots:
I shared more than a little of Joerg's frustration in his recent posting
about trying to get going in trunk development again. I have been able to
spend some quality time walking through code with my debugger, and my work
on the doc has helped some of the design concepts sink in better as well, so
I am getting more confident about being able to jump in and help for real.
Here are some issues for discussion.
Issue 1 -- Project Focus
I think I jumped into this project just as serious efforts were being made
to discourage new development on the maintenance branch. This was rightly
perceived as a dilution of resources. It has taken me nearly six months to
see another dilution of resources -- new development on the trunk! The only
thing that the redesign is really supposed to touch is the layout. So my
thoughts about working on fonts are misplaced. Fonts and Avalonization might
need to be done before 1.0, but AFAIK, they don't need to be done before
reunification. This difference is so important to this project, that I offer
it as a proposition to be voted upon:
Resolved: Rather than focusing on a 1.0 release, our efforts should be
focused on a 0.21 release from the trunk that is as good as 0.20.5. New
features, whether in the maintenance branch or the trunk, whether for the
user's benefits or for our's, should be abandoned unless they have an
immediate payback toward a 0.21 release. Only after stabilizing 0.21 so that
our users can safely move to it should we start adding features. This
implies that, whenever possible, we should be working on trunk layout code.
Issue 2 -- Unstable Code
We know that we are working with unstable code, which presents some risks.
First, with stable code, if a hacker like me messes it up, it will be
obvious almost immediately, and can easily be rolled back. That won't be
true in our situation. Second, unstable implies that some of the code might
be working well or finished. Most of us don't understand what is going on
the layout code as well as Keiron. I've spent a little time in there, and I
frankly don't have a clear idea of what works and what doesn't, what is
stable & what is not. So I really have two choices: 1) wade in and start
hacking away, perhaps at cross-purposes of the big picture, or 2) have a
"manager" pass a task off to me that is reasonably well-defined, and that
fits well into the big picture, then, when that is done, give another, etc.
I can do either one, but the second one makes more sense to me. I would
naturally look to Keiron for this, if he is willing. I am not looking for
something like "get line justification working", but more like "take class
Xyz.java and make method abc() return the correct word-spacing to justify
the input line -- here is a test file."
The good news is that it is probable that after a couple of cycles of this,
I would be able to find the next task on my own.
I guess what I am saying is that I am willing to follow if someone is
willing to lead.
Victor Mote (mailto:vic@outfitr.com)
2025 Eddington Way
Colorado Springs, Colorado 80916
Voice +1 (719) 622-0650
Fax +1 (720) 293-0044
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Eclipse was Re: toward reunification
Posted by Eric Galluzzo <eg...@einnovation.com>.
J.Pietschmann wrote:
> Also, none of the available free XML plugins can beat Emacs+PSGML
> yet. Editing FOs or XDocs with the plain text editor just sucks.
> Has anybody already evaluated the most promising project which
> attacks this problem?
The best XML editor plugin that I have found is:
http://www.xmlbuddy.com/
It is free but not open-source. Also, I haven't noticed a whole lot of
activity on the web site recently....
- Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Eclipse was Re: toward reunification
Posted by "J.Pietschmann" <j3...@yahoo.de>.
J.Pietschmann wrote:
> Sun JDK 1.4.1_1
Ouch, should be
1.4.1_02 (<- the _02 seems to make a noticable difference)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Eclipse was Re: toward reunification
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Peter B. West wrote:
> I am in the process of commissioning an XP 2200+ system with 1Gb of
> memory, on which I will finally be able to run an environment like
> Eclipse in real time.
Eclipse runs without problems on my P3-533/256MB at work, using
Sun JDK 1.4.1_1 (<- the _1 seems to make a noticable difference).
Actually I think Eclipse is the greatest thing in IDEs since the
invention of sliced bread. I took much of the last two days to
get up to speed with it, and you'll probably see the result, a
simple XInclude processor, committed to xml-commons this weekend.
The main risk running Eclipse is that I get distracted by the
idea of implementing the FOP viewer as plugin :-)
Also, none of the available free XML plugins can beat Emacs+PSGML
yet. Editing FOs or XDocs with the plain text editor just sucks.
Has anybody already evaluated the most promising project which
attacks this problem?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: toward reunification
Posted by "Peter B. West" <pb...@powerup.com.au>.
Jeremias Maerki wrote:
> On 23.04.2003 10:53:46 Victor Mote wrote:
>
>>FOP compatriots:
>>
>>I shared more than a little of Joerg's frustration in his recent posting
>>about trying to get going in trunk development again.
>
>
> That makes three of us when it comes to layout. It's a very complicated
> matter I have not been able to dive into, yet.
>
>
>>I have been able to
>>spend some quality time walking through code with my debugger, and my work
>>on the doc has helped some of the design concepts sink in better as well, so
>>I am getting more confident about being able to jump in and help for real.
>>Here are some issues for discussion.
>>
I am in the process of commissioning an XP 2200+ system with 1Gb of
memory, on which I will finally be able to run an environment like
Eclipse in real time. I hope to be able to do some of the above
code-stepping myself, in association with the integration of the
alt.design FO front end.
>>Issue 1 -- Project Focus
>>I think I jumped into this project just as serious efforts were being made
>>to discourage new development on the maintenance branch. This was rightly
>>perceived as a dilution of resources. It has taken me nearly six months to
>>see another dilution of resources -- new development on the trunk! The only
>>thing that the redesign is really supposed to touch is the layout.
>
>
> ...plus:
> - better API
> - refactoring of all ugly static constructs
>
>
>>So my
>>thoughts about working on fonts are misplaced. Fonts and Avalonization might
>>need to be done before 1.0, but AFAIK, they don't need to be done before
>>reunification.
>
>
> I dread that term. There has been a lot of effort to clean up code in
> the trunk. The SVG and PDF and other subsystems have been improved.
> Peter is working on the improved FO handling. IMO there's not much in
> the maintenance branch that is worth keeping after the layout has been
> brought to a good level in the trunk.
>
I have shamefully neglected this in the past few months, for reasons too
numerous to mention here, but including a certain amount of burnout. I
have also received a couple of emails from developers who have expressed
an interest in alt.design, and a guy who is working on an FO based
WYSIWYG editor. These approaches I have also shamefully neglected.
I intend to approach these guys again to find out how they feel about
surfacing in fop-dev.
One of the things that has been on my mind is the impact of the
integration on the layout. There is some commentary about this in the
wiki. I will post again with some specific questions about the
representation of unresolvable percentages in the FO tree, with a view
to firming up the requirements in the wiki. I have some troublesome
questions about the model of layout as well.
...
>
> So what is this "unification" that you don't mention in this last
> paragraph but in the subject?
>
>
>>Issue 2 -- Unstable Code
>>We know that we are working with unstable code, which presents some risks.
>>First, with stable code, if a hacker like me messes it up, it will be
>>obvious almost immediately, and can easily be rolled back. That won't be
>>true in our situation. Second, unstable implies that some of the code might
>>be working well or finished. Most of us don't understand what is going on
>>the layout code as well as Keiron. I've spent a little time in there, and I
>>frankly don't have a clear idea of what works and what doesn't, what is
>>stable & what is not. So I really have two choices: 1) wade in and start
>>hacking away, perhaps at cross-purposes of the big picture, or 2) have a
>>"manager" pass a task off to me that is reasonably well-defined, and that
>>fits well into the big picture, then, when that is done, give another, etc.
>>I can do either one, but the second one makes more sense to me. I would
>>naturally look to Keiron for this, if he is willing. I am not looking for
>>something like "get line justification working", but more like "take class
>>Xyz.java and make method abc() return the correct word-spacing to justify
>>the input line -- here is a test file."
>>
>>The good news is that it is probable that after a couple of cycles of this,
>>I would be able to find the next task on my own.
>>
>>I guess what I am saying is that I am willing to follow if someone is
>>willing to lead.
>
>
> It all comes down to our resource problem. :-(
This is an excellent idea, and, if it were working, a guaranteed way of
getting FOP up to compliance and efficiency very quickly. I think the
basic problem is that no-one has a developed idea of where the layout is
going. That is something we need to address as a matter of urgency.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: toward reunification
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 23.04.2003 23:01:59 Arved Sandstrom wrote:
> So, let us be bold. (I say "us", because I have recently started a
> consulting business, and have some time. :-))
:-) Serious again: Not the best of times to dive into it. Good luck!
> I would say *shut down* the maintenance branch. Leave the version as it is,
> try to answer users' questions, but stop doing any coding on it. Let people
> use FOP as it is, for the moment.
>
> I've been in open-source for quite a while now. It is not useful to ask
> Keiron where to start. The best thing to do is just to get aggressive, while
> still being cooperative, and start committing code. If Keiron doesn't like
> what you submitted or committed, he'll modify it or complain about it -
> that's the way it's supposed to work.
Yep.
> I believe I will be able to assist also.
Good to hear. How's your C impl?
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: toward reunification
Posted by Jeremias Maerki <de...@greenmail.ch>.
Don't worry. We'll do that 0.20.5 release.
On 23.04.2003 23:49:09 Clay Leeds wrote:
> As long as you're/we're saying "Let's stop development on the
> Maintenance Branch *after* 0.20.5 is released, then I'm in total
> agreement. However, if you're/we're saying "Let's stop work on the
> maintenance branch immediately, then the message of earlier today RE:
> not using FOP because it's about to be abandoned takes on different
> meaning for me.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: toward reunification
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
> -----Original Message-----
> From: Clay Leeds [mailto:cleeds@medata.com]
> Sent: April 23, 2003 6:49 PM
> To: fop-dev@xml.apache.org
> Subject: Re: toward reunification
>
> Whoa there. I just want to get clear here.
>
> Arved Sandstrom wrote:
> >>-----Original Message-----
> >>From: Victor Mote [mailto:vic@outfitr.com]
> >>Sent: April 23, 2003 3:11 PM
> >>To: fop-dev@xml.apache.org
> >>Subject: RE: toward reunification
> >
> >>Jeremias Maerki wrote:
> >
> > [ SNIP ]
> >
> >>>It all comes down to our resource problem. :-(
> >>
> >>Our resource problem is self-inflicted. We made some bad
> choices along the
> >>way. Right now the success or failure of this project hinges on Keiron's
> >>ability to either get the layout done himself or help us help him get it
> >>done. If Jeremias and Joerg don't know how to get productive in
> the trunk
> >>layout code, we will never, NEVER (yes, I am shouting a bit) get
> >>anyone else
> >>to. If you count me as .05, we have 2.05 developers ready,
> >>willing, and able
> >>to help punch this thing forward. Keiron, can you show us where
> to start?
> >
> > So, let us be bold. (I say "us", because I have recently started a
> > consulting business, and have some time. :-))
> >
> > I would say *shut down* the maintenance branch. Leave the
> version as it is,
> > try to answer users' questions, but stop doing any coding on
> it. Let people
> > use FOP as it is, for the moment.
>
> Some of us are using the maintenance branch. Perhaps I'm just confused
> not understanding and blinded by my desire to start playing with
> 0.20.5rc3 (not to mention 0.20.5). I've been waiting since mid-March for
> the fabled 0.20.5rc3, since the current "Release Candidate" is not
> useful to me (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17472).
>
> As long as you're/we're saying "Let's stop development on the
> Maintenance Branch *after* 0.20.5 is released, then I'm in total
> agreement. However, if you're/we're saying "Let's stop work on the
> maintenance branch immediately, then the message of earlier today RE:
> not using FOP because it's about to be abandoned takes on different
> meaning for me.
>
> We've (my company) been waiting for v0.20.5 since before 0.20.5rc was
> released 10-Dec-2002 08:50. I'm foaming at the mouth for the thing, can
> you tell? Hopefully, I'm misunderstanding things here, and we're not
> really talking about *shutting down* the maintenance branch before the
> release of 0.20.5...
I understand you. I know there are things that have been promised to users
in the near-term; it's only right to get that out the door.
*Everybody* is using the maintenance branch. :-)
I am in total agreement with what you just said, and I should have been more
clear in my earlier post.
Arved
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: toward reunification
Posted by Clay Leeds <cl...@medata.com>.
Whoa there. I just want to get clear here.
Arved Sandstrom wrote:
>>-----Original Message-----
>>From: Victor Mote [mailto:vic@outfitr.com]
>>Sent: April 23, 2003 3:11 PM
>>To: fop-dev@xml.apache.org
>>Subject: RE: toward reunification
>
>>Jeremias Maerki wrote:
>
> [ SNIP ]
>
>>>It all comes down to our resource problem. :-(
>>
>>Our resource problem is self-inflicted. We made some bad choices along the
>>way. Right now the success or failure of this project hinges on Keiron's
>>ability to either get the layout done himself or help us help him get it
>>done. If Jeremias and Joerg don't know how to get productive in the trunk
>>layout code, we will never, NEVER (yes, I am shouting a bit) get
>>anyone else
>>to. If you count me as .05, we have 2.05 developers ready,
>>willing, and able
>>to help punch this thing forward. Keiron, can you show us where to start?
>
> So, let us be bold. (I say "us", because I have recently started a
> consulting business, and have some time. :-))
>
> I would say *shut down* the maintenance branch. Leave the version as it is,
> try to answer users' questions, but stop doing any coding on it. Let people
> use FOP as it is, for the moment.
Some of us are using the maintenance branch. Perhaps I'm just confused
not understanding and blinded by my desire to start playing with
0.20.5rc3 (not to mention 0.20.5). I've been waiting since mid-March for
the fabled 0.20.5rc3, since the current "Release Candidate" is not
useful to me (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17472).
As long as you're/we're saying "Let's stop development on the
Maintenance Branch *after* 0.20.5 is released, then I'm in total
agreement. However, if you're/we're saying "Let's stop work on the
maintenance branch immediately, then the message of earlier today RE:
not using FOP because it's about to be abandoned takes on different
meaning for me.
We've (my company) been waiting for v0.20.5 since before 0.20.5rc was
released 10-Dec-2002 08:50. I'm foaming at the mouth for the thing, can
you tell? Hopefully, I'm misunderstanding things here, and we're not
really talking about *shutting down* the maintenance branch before the
release of 0.20.5...
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: toward reunification
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
(even though inactive as a committer, I'd like to put my 2 cents in to
show support for what's happening)
Le mercredi, 23 avr 2003, à 23:01 Europe/Zurich, Arved Sandstrom a
écrit :
> ...I would say *shut down* the maintenance branch. Leave the version
> as it is,
> try to answer users' questions, but stop doing any coding on it. Let
> people
> use FOP as it is, for the moment.
Agreed - and as Victor mentions, this means getting the layout working
from the trunk code as soon as possible, putting all efforts towards
this. No one will use trunk code in production unless the output
documents are usable, regardless of how good or bad or Avalonized the
code looks inside (not to downplay Avalonizing or refactoring but
user-oriented priorities have to be set IMHO).
> ...I've been in open-source for quite a while now. It is not useful to
> ask
> Keiron where to start. The best thing to do is just to get aggressive,
> while
> still being cooperative, and start committing code...
Also agreed - IMHO people who have been elected as committers are fully
trusted to work on any part of the code, provided they're also ready to
fix whatever they might break. CVS is your friend anyway, even the
worst failures can be reversed if needed.
However, this requires measurable tests of one's success.
Automated tests would be hard to implement for FOP I think, but
semi-automated tests using self-describing documents or an existing
test suite (NIST?) are much easier to implement, for example by someone
creating a test document before fixing a problem, to show the
difference once it's fixed.
The quality of the test documents is decisive here, one must be able to
evaluate the results precisely simply by reading the generated document.
Having reliable tests will certainly help those who are afraid of
jumping in (provided there are such people, but it seems so) to get
their feet wet.
Hope this helps!
--
Bertrand Delacretaz (codeconsult.ch, jfor.org)
XML, java, XSLT, Cocoon, FOP, mentoring/programming/teaching
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: toward reunification
Posted by Victor Mote <vi...@outfitr.com>.
Arved Sandstrom wrote:
> > to help punch this thing forward. Keiron, can you show us where
> to start?
>
> So, let us be bold. (I say "us", because I have recently started a
> consulting business, and have some time. :-))
>
> I would say *shut down* the maintenance branch. Leave the version
> as it is,
> try to answer users' questions, but stop doing any coding on it.
> Let people
> use FOP as it is, for the moment.
>
> I've been in open-source for quite a while now. It is not useful to ask
> Keiron where to start. The best thing to do is just to get
> aggressive, while
> still being cooperative, and start committing code. If Keiron doesn't like
> what you submitted or committed, he'll modify it or complain about it -
> that's the way it's supposed to work.
All right, I can live with that, but it does seem less than ideal. Perhaps I
have been too timid. We shall see if you sing the same tune after you've
seen me at work for a while. :-)
> I believe I will be able to assist also.
That's the best news I've heard all day. Good luck on the consulting
business.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: toward reunification
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
> -----Original Message-----
> From: Victor Mote [mailto:vic@outfitr.com]
> Sent: April 23, 2003 3:11 PM
> To: fop-dev@xml.apache.org
> Subject: RE: toward reunification
> Jeremias Maerki wrote:
[ SNIP ]
> > It all comes down to our resource problem. :-(
>
> Our resource problem is self-inflicted. We made some bad choices along the
> way. Right now the success or failure of this project hinges on Keiron's
> ability to either get the layout done himself or help us help him get it
> done. If Jeremias and Joerg don't know how to get productive in the trunk
> layout code, we will never, NEVER (yes, I am shouting a bit) get
> anyone else
> to. If you count me as .05, we have 2.05 developers ready,
> willing, and able
> to help punch this thing forward. Keiron, can you show us where to start?
So, let us be bold. (I say "us", because I have recently started a
consulting business, and have some time. :-))
I would say *shut down* the maintenance branch. Leave the version as it is,
try to answer users' questions, but stop doing any coding on it. Let people
use FOP as it is, for the moment.
I've been in open-source for quite a while now. It is not useful to ask
Keiron where to start. The best thing to do is just to get aggressive, while
still being cooperative, and start committing code. If Keiron doesn't like
what you submitted or committed, he'll modify it or complain about it -
that's the way it's supposed to work.
I believe I will be able to assist also.
Arved
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: toward reunification
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote:
> On 23.04.2003 10:53:46 Victor Mote wrote:
> > FOP compatriots:
> >
> > I shared more than a little of Joerg's frustration in his recent posting
> > about trying to get going in trunk development again.
>
> That makes three of us when it comes to layout. It's a very complicated
> matter I have not been able to dive into, yet.
Ouch -- I was hoping that you and Keiron had some big chunks of code that
were nearing completion. The fact that you and Joerg are having trouble
getting traction really scares me, because I know only about 5% of what you
do. You and I have both been kind of drawn toward some of the peripheral
things that are needed to drive forward, probably because we are scared to
jump into the layout.
> > Issue 1 -- Project Focus
...
> trunk! The only
> > thing that the redesign is really supposed to touch is the layout.
>
> ...plus:
> - better API
> - refactoring of all ugly static constructs
If that was decided somewhere along the way, then I will 1) stand corrected,
and 2) ask that the issue be reopened. I'm all for both of these, but not
until the layout rework is done. The problem is that we branched /all/ of
the code. If we had kept common code common, we could add stuff, refactor,
and clean up at will, and move both forward. I don't mean to go over this
ground again. The point is that open source projects depend on code that
works (no matter how basically or trivially), and we have /locked/ ourselves
into broken code.
> > So my
> > thoughts about working on fonts are misplaced. Fonts and
> Avalonization might
> > need to be done before 1.0, but AFAIK, they don't need to be done before
> > reunification.
>
> I dread that term. There has been a lot of effort to clean up code in
> the trunk. The SVG and PDF and other subsystems have been improved.
> Peter is working on the improved FO handling. IMO there's not much in
> the maintenance branch that is worth keeping after the layout has been
> brought to a good level in the trunk.
I am not talking so much about reunification of code (although that is
implied), but reunification of resources. Even if no code is merged, we
still move from development along two lines to development along one line.
We move from working on two sets of code to working on one set.
> > New
> > features, whether in the maintenance branch or the trunk,
> whether for the
> > user's benefits or for our's, should be abandoned unless they have an
> > immediate payback toward a 0.21 release.
>
> I can live with that although the API discussion is a very important one.
I agree. But we are in a world of hurt until we get back to one version of
code.
Suppose for a moment that we simply abandoned the maintenance branch. What
would we have? We have code that doesn't work and won't work until layout is
done. The critical path toward our next release is getting layout working.
If layout were working today, we could do a release, start getting feedback,
fix bugs, and move forward. What will it take to get layout done? Keiron
probably knows, and can probably tell us in abstract terms. To a large
extent, he already has. There is a wiki on the topic, but it is neither
prioritized nor concrete. For me anyway, there is not enough detail to get
started. We have three choices: 1) Keiron finishes it himself, 2) Keiron
directs the efforts of the other developers, or 3) every developer starts
hacking away and hopes he doesn't hurt the others.
> So what is this "unification" that you don't mention in this last
> paragraph but in the subject?
See above.
> It all comes down to our resource problem. :-(
Our resource problem is self-inflicted. We made some bad choices along the
way. Right now the success or failure of this project hinges on Keiron's
ability to either get the layout done himself or help us help him get it
done. If Jeremias and Joerg don't know how to get productive in the trunk
layout code, we will never, NEVER (yes, I am shouting a bit) get anyone else
to. If you count me as .05, we have 2.05 developers ready, willing, and able
to help punch this thing forward. Keiron, can you show us where to start?
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: toward reunification
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 23.04.2003 10:53:46 Victor Mote wrote:
> FOP compatriots:
>
> I shared more than a little of Joerg's frustration in his recent posting
> about trying to get going in trunk development again.
That makes three of us when it comes to layout. It's a very complicated
matter I have not been able to dive into, yet.
> I have been able to
> spend some quality time walking through code with my debugger, and my work
> on the doc has helped some of the design concepts sink in better as well, so
> I am getting more confident about being able to jump in and help for real.
> Here are some issues for discussion.
>
> Issue 1 -- Project Focus
> I think I jumped into this project just as serious efforts were being made
> to discourage new development on the maintenance branch. This was rightly
> perceived as a dilution of resources. It has taken me nearly six months to
> see another dilution of resources -- new development on the trunk! The only
> thing that the redesign is really supposed to touch is the layout.
...plus:
- better API
- refactoring of all ugly static constructs
> So my
> thoughts about working on fonts are misplaced. Fonts and Avalonization might
> need to be done before 1.0, but AFAIK, they don't need to be done before
> reunification.
I dread that term. There has been a lot of effort to clean up code in
the trunk. The SVG and PDF and other subsystems have been improved.
Peter is working on the improved FO handling. IMO there's not much in
the maintenance branch that is worth keeping after the layout has been
brought to a good level in the trunk.
> This difference is so important to this project, that I offer
> it as a proposition to be voted upon:
>
> Resolved: Rather than focusing on a 1.0 release, our efforts should be
> focused on a 0.21 release from the trunk that is as good as 0.20.5.
With that I can agree.
> New
> features, whether in the maintenance branch or the trunk, whether for the
> user's benefits or for our's, should be abandoned unless they have an
> immediate payback toward a 0.21 release.
I can live with that although the API discussion is a very important one.
> Only after stabilizing 0.21 so that
> our users can safely move to it should we start adding features. This
> implies that, whenever possible, we should be working on trunk layout code.
So what is this "unification" that you don't mention in this last
paragraph but in the subject?
> Issue 2 -- Unstable Code
> We know that we are working with unstable code, which presents some risks.
> First, with stable code, if a hacker like me messes it up, it will be
> obvious almost immediately, and can easily be rolled back. That won't be
> true in our situation. Second, unstable implies that some of the code might
> be working well or finished. Most of us don't understand what is going on
> the layout code as well as Keiron. I've spent a little time in there, and I
> frankly don't have a clear idea of what works and what doesn't, what is
> stable & what is not. So I really have two choices: 1) wade in and start
> hacking away, perhaps at cross-purposes of the big picture, or 2) have a
> "manager" pass a task off to me that is reasonably well-defined, and that
> fits well into the big picture, then, when that is done, give another, etc.
> I can do either one, but the second one makes more sense to me. I would
> naturally look to Keiron for this, if he is willing. I am not looking for
> something like "get line justification working", but more like "take class
> Xyz.java and make method abc() return the correct word-spacing to justify
> the input line -- here is a test file."
>
> The good news is that it is probable that after a couple of cycles of this,
> I would be able to find the next task on my own.
>
> I guess what I am saying is that I am willing to follow if someone is
> willing to lead.
It all comes down to our resource problem. :-(
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: toward reunification
Posted by Keiron Liddle <ke...@aftexsw.com>.
Hi All,
Sorry about not being able to do much lately. I understand how
complicated, in particular, the layout is and how difficult it is to get
going on it.
I have been working slowly on improving the current layout. Simplifying
the way it works and handles all the various situations in the way that
I hve outlined previously. It is looking quite promising unfortunately I
have not found the time to really get going on it and get things in good
order. The good news is that it is only effecting the layoutmgr code and
other parts are untouched.
I realise that it really needs to get a good approach before we can
start doing the smaller details and this approach needs to accommodate
the future needs. This is what really makes it more difficult and slow.
Hopefully I can find a bit of time to get the process rolling.
Keiron
On Wednesday, April 23, 2003, at 06:53 PM, Victor Mote wrote:
> FOP compatriots:
>
> I shared more than a little of Joerg's frustration in his recent posting
> about trying to get going in trunk development again. I have been able
> to
> spend some quality time walking through code with my debugger, and my
> work
> on the doc has helped some of the design concepts sink in better as
> well, so
> I am getting more confident about being able to jump in and help for
> real.
> Here are some issues for discussion.
>
> Issue 1 -- Project Focus
> I think I jumped into this project just as serious efforts were being
> made
> to discourage new development on the maintenance branch. This was
> rightly
> perceived as a dilution of resources. It has taken me nearly six months
> to
> see another dilution of resources -- new development on the trunk! The
> only
> thing that the redesign is really supposed to touch is the layout. So my
> thoughts about working on fonts are misplaced. Fonts and Avalonization
> might
> need to be done before 1.0, but AFAIK, they don't need to be done before
> reunification. This difference is so important to this project, that I
> offer
> it as a proposition to be voted upon:
>
> Resolved: Rather than focusing on a 1.0 release, our efforts should be
> focused on a 0.21 release from the trunk that is as good as 0.20.5. New
> features, whether in the maintenance branch or the trunk, whether for
> the
> user's benefits or for our's, should be abandoned unless they have an
> immediate payback toward a 0.21 release. Only after stabilizing 0.21 so
> that
> our users can safely move to it should we start adding features. This
> implies that, whenever possible, we should be working on trunk layout
> code.
>
> Issue 2 -- Unstable Code
> We know that we are working with unstable code, which presents some
> risks.
> First, with stable code, if a hacker like me messes it up, it will be
> obvious almost immediately, and can easily be rolled back. That won't be
> true in our situation. Second, unstable implies that some of the code
> might
> be working well or finished. Most of us don't understand what is going
> on
> the layout code as well as Keiron. I've spent a little time in there,
> and I
> frankly don't have a clear idea of what works and what doesn't, what is
> stable & what is not. So I really have two choices: 1) wade in and start
> hacking away, perhaps at cross-purposes of the big picture, or 2) have a
> "manager" pass a task off to me that is reasonably well-defined, and
> that
> fits well into the big picture, then, when that is done, give another,
> etc.
> I can do either one, but the second one makes more sense to me. I would
> naturally look to Keiron for this, if he is willing. I am not looking
> for
> something like "get line justification working", but more like "take
> class
> Xyz.java and make method abc() return the correct word-spacing to
> justify
> the input line -- here is a test file."
>
> The good news is that it is probable that after a couple of cycles of
> this,
> I would be able to find the next task on my own.
>
> I guess what I am saying is that I am willing to follow if someone is
> willing to lead.
>
> Victor Mote (mailto:vic@outfitr.com)
> 2025 Eddington Way
> Colorado Springs, Colorado 80916
> Voice +1 (719) 622-0650
> Fax +1 (720) 293-0044
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org