Re: Redesign issues
On Thu, 2002-12-12 at 11:37, Oleg Tkachenko wrote: > Keiron, can you place the link somewhere in the dev docs for memory, please? Sure. Done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Keiron Liddle wrote: A very rough start at some tasks for FOP here: http://codeconsult.ch/wiki/index.php/FopTasks I'm new to this wiki stuff, so see what happens. Keiron, can you place the link somewhere in the dev docs for memory, please? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Markers (was: RE: Redesign issues)
On Tue, 2002-12-10 at 17:26, Arved Sandstrom wrote: > Incidentally, I still think that the way markers are described in the spec > is vague and confusing. Perhaps we should hammer this out. Agreed. I still have figured out what it really means. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
Responses below. > -Original Message- > From: Keiron Liddle [mailto:[EMAIL PROTECTED]] > Sent: December 10, 2002 5:56 AM > To: FOP > Subject: RE: Redesign issues > > > Hi Arved, > > On Mon, 2002-12-09 at 20:30, Arved Sandstrom wrote: > > The feeling I got from my prototype is that there is not much > commonality. > > > > Markers - there is no logic here that has anything to do with > layout, per > > se. The content goes into a static-content and hence does not > influence page > > break decisions. The logic for handling markers can be confined to the > > document level. "root" is an FO - it is the document, so it is > the FO that > > can handle this. > > That is true but there is something that happened in the original way > that fop handled markers. > The fo has a property list which has a parent property list from the > parent object. It also has a parent object. It couldn't be simply made > null and then passed to the root as it could cause npe's. > > The argument here is not so much that it cannot be done, more that if it > is a completely separate logic then it is easier to understand and > ensure it won't end up with bugs or memory leaks. Right...I implemented the original (incomplete) marker logic using what we had at the time for property handling. I did not tackle the re-parenting problem at all - didn't get that far - so the marker content actually retained the inherited properties from the origin FO, which is incorrect. I see no problems with a marker handler that associates with the document, in this case. This would coordinate with page-sequences and pages, obviously. Incidentally, I still think that the way markers are described in the spec is vague and confusing. Perhaps we should hammer this out. > > Floats and footnotes - the float goes on a page or it doesn't. > The footnote > > starts on page N and continues through N+x or it doesn't. What FO knows > > about pages? The "page-sequence"...that's the natural FO for > handling float > > and footnote problems. OK, this is somewhat simplified; with > floats it may > > come down to columns, and then it is the "region-body" that > also needs to > > intercede. > > > > Tables I can't comment on. So there may be an argument here for > independent > > layout managers. > > > > I think we could use layout managers when it is clear that > there is a layout > > problem involving N FOs, such that those N FOs are not identical to the > > children of a higher FO. I see keeps as being the main > occurrence of this. > > But even then, keeps are still related to logic that occurs in > page-sequence > > and region-body and lines (3 entities, in other words), and the > nature of > > that logic differs in all 3 situations, so is it worth abstracting out a > > keep manager? I don't know. > There is the line layout manager. There is no line fo. The block layout > manager is able to collect inline porducing layout managers and give > them to a line layout manager which then has the logic to handle flowing > inline areas into a line. > The block layout logic is then more simple. Lines are not FO's, no - that's why I used the word "entity". :-) > This is similar to the cells under a table body. > Also with page columns, do we want to make the FlowLayout manager handle > all the blocks that do and don't span columns or can we create a page > column layout manager which looks after blocks in columns and then can > handle the reflowing etc. I originally handled this (in my prototype) with managers for pages, regions, spans and columns. This is the one area where I think managers make the most sense - the handling of a page is complex and it simplifies matters to have clearly distinguishable managers to take care of the various constituent areas. > A leader with use-content creates an inline parent with a fixed width. > It is creating a simple inline area but we want to do a quick > independant layout for the content. > Again, maybe not necessary but it help separate out the logic. > > > Here's a common ground that I can agree on...pull the layout > logic out, and > > put it in "managers". This is not going to hurt. But really, > really cut down > > on the urge to re-use managers through an inheritance hierarchy. I think > > this is also Joerg's point. It obfuscates more than it helps. > > I'm not sure the exact re-use problem you are referring to but I agree > it should be simple and straight forward. Agreed. I won't comment further until I re-sync with the latest CVS and examine. :-) Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
Hi Arved, On Mon, 2002-12-09 at 20:30, Arved Sandstrom wrote: > The feeling I got from my prototype is that there is not much commonality. > > Markers - there is no logic here that has anything to do with layout, per > se. The content goes into a static-content and hence does not influence page > break decisions. The logic for handling markers can be confined to the > document level. "root" is an FO - it is the document, so it is the FO that > can handle this. That is true but there is something that happened in the original way that fop handled markers. The fo has a property list which has a parent property list from the parent object. It also has a parent object. It couldn't be simply made null and then passed to the root as it could cause npe's. The argument here is not so much that it cannot be done, more that if it is a completely separate logic then it is easier to understand and ensure it won't end up with bugs or memory leaks. > Floats and footnotes - the float goes on a page or it doesn't. The footnote > starts on page N and continues through N+x or it doesn't. What FO knows > about pages? The "page-sequence"...that's the natural FO for handling float > and footnote problems. OK, this is somewhat simplified; with floats it may > come down to columns, and then it is the "region-body" that also needs to > intercede. > > Tables I can't comment on. So there may be an argument here for independent > layout managers. > > I think we could use layout managers when it is clear that there is a layout > problem involving N FOs, such that those N FOs are not identical to the > children of a higher FO. I see keeps as being the main occurrence of this. > But even then, keeps are still related to logic that occurs in page-sequence > and region-body and lines (3 entities, in other words), and the nature of > that logic differs in all 3 situations, so is it worth abstracting out a > keep manager? I don't know. There is the line layout manager. There is no line fo. The block layout manager is able to collect inline porducing layout managers and give them to a line layout manager which then has the logic to handle flowing inline areas into a line. The block layout logic is then more simple. This is similar to the cells under a table body. Also with page columns, do we want to make the FlowLayout manager handle all the blocks that do and don't span columns or can we create a page column layout manager which looks after blocks in columns and then can handle the reflowing etc. A leader with use-content creates an inline parent with a fixed width. It is creating a simple inline area but we want to do a quick independant layout for the content. Again, maybe not necessary but it help separate out the logic. > Here's a common ground that I can agree on...pull the layout logic out, and > put it in "managers". This is not going to hurt. But really, really cut down > on the urge to re-use managers through an inheritance hierarchy. I think > this is also Joerg's point. It obfuscates more than it helps. I'm not sure the exact re-use problem you are referring to but I agree it should be simple and straight forward. > Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
Response below. -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 3:00 PM To: [EMAIL PROTECTED] Subject: Re: Redesign issues >> Keiron Liddle wrote: > These are the issues that you have mentioned before. > It is still essentially only attacking two methods (and supporting > classes). Unfortunately, these are the core methods, essential for understanding the whole approach. << Indeed. >> > If you have a better design, then do it. I put a detailed critique and some proposals for alternatives forward. It would be nice to hear your comments about how essential the current approach (for the iterators) is for you and Karens plans for further development, and/or how the alternatives would interfere with it. << I agree, and this is one of the reasons I thought a comprehensive development plan, not just a simple todo list, is essential. More than just one or two of us are waiting to see the solidification of a plan before we can see where we fit. Personally, I see a lot of things I'd like to do with the layout system, but I have a strong concern that they may not be fully congruent with the overall path of FOP as it is seen by the most prolific committers (like Keiron). My work would thus be a waste of time for both me and FOP. Let's get it together on this so we can all work towards a solution. I really don't see why there's such a "love it or leave it" attitude with respect to the LMs as they are now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Keiron Liddle wrote: These are the issues that you have mentioned before. It is still essentially only attacking two methods (and supporting classes). Unfortunately, these are the core methods, essential for understanding the whole approach. If you have a better design, then do it. I put a detailed critique and some proposals for alternatives forward. It would be nice to hear your comments about how essential the current approach (for the iterators) is for you and Karens plans for further development, and/or how the alternatives would interfere with it. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
> -Original Message- > From: Peter B. West [mailto:[EMAIL PROTECTED]] > Sent: December 9, 2002 8:56 AM > To: [EMAIL PROTECTED] > Subject: Re: Redesign issues > > > Keiron Liddle wrote: > > > > > > I still believe that it is useful to have the layout managers separate > > from the fo tree. There are a number of reasons that come to mind. It is > > possible to independantly change layout managers. Certain fo's aren't > > directly in the same hierarchy: markers, undefined table columns, table > > cells under table body. Then there are things like floats and footnotes > > that can gain from this. > > Keiron, > > I'm inclining in this direction myself, because I am interested in > isolating the layout/area tree functions as much as possible from the > raw information stream of the FO tree. I tend to view the FO tree as a > read-only data source for the layout. manaaged by the Fo objects. The feeling I got from my prototype is that there is not much commonality. Markers - there is no logic here that has anything to do with layout, per se. The content goes into a static-content and hence does not influence page break decisions. The logic for handling markers can be confined to the document level. "root" is an FO - it is the document, so it is the FO that can handle this. Floats and footnotes - the float goes on a page or it doesn't. The footnote starts on page N and continues through N+x or it doesn't. What FO knows about pages? The "page-sequence"...that's the natural FO for handling float and footnote problems. OK, this is somewhat simplified; with floats it may come down to columns, and then it is the "region-body" that also needs to intercede. Tables I can't comment on. So there may be an argument here for independent layout managers. I think we could use layout managers when it is clear that there is a layout problem involving N FOs, such that those N FOs are not identical to the children of a higher FO. I see keeps as being the main occurrence of this. But even then, keeps are still related to logic that occurs in page-sequence and region-body and lines (3 entities, in other words), and the nature of that logic differs in all 3 situations, so is it worth abstracting out a keep manager? I don't know. Here's a common ground that I can agree on...pull the layout logic out, and put it in "managers". This is not going to hurt. But really, really cut down on the urge to re-use managers through an inheritance hierarchy. I think this is also Joerg's point. It obfuscates more than it helps. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Keiron Liddle wrote: I still believe that it is useful to have the layout managers separate from the fo tree. There are a number of reasons that come to mind. It is possible to independantly change layout managers. Certain fo's aren't directly in the same hierarchy: markers, undefined table columns, table cells under table body. Then there are things like floats and footnotes that can gain from this. Keiron, I'm inclining in this direction myself, because I am interested in isolating the layout/area tree functions as much as possible from the raw information stream of the FO tree. I tend to view the FO tree as a read-only data source for the layout. manaaged by the Fo objects. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
On Fri, 2002-12-06 at 15:43, Rhett Aultman wrote: > We have a Wiki that seems to have been a good way of quickly throwing up ideas for >style guidelines and voting on them. Why don't we do the same thing here? We could >throw up our ideas, try to sort them into "lofty, long term" stuff and "immediate >tasks" and whatnot. Yeah...Bugzilla can be used somewhat, but I think this would be >a better way to go when it comes to collaboratively creating a game plan. Anyone >else have thoughts on this? I say we set up another page on our Wiki. A very rough start at some tasks for FOP here: http://codeconsult.ch/wiki/index.php/FopTasks I'm new to this wiki stuff, so see what happens. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Hi Joerg, These are the issues that you have mentioned before. It is still essentially only attacking two methods (and supporting classes). If you have a better design, then do it. On Sun, 2002-12-08 at 00:16, J.Pietschmann wrote: > deep inheritance hierarchies. There is only so much someone can hold in the > brain. Nevertheless, this is something I don't know how to fix on the cheap. We aren't at that stage yet. Why, because there aren't enough people developing it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
On Mon, 2002-12-09 at 01:00, Arved Sandstrom wrote: > I actually helped push for this last year - the notion of separate layout > managers. I was strongly influenced by the mess that FOP code had become at > the time, and really thought that layout should be taken out of the FOs > themselves; that the FO's, in a sense, were (or should be) just value > objects. > > I worked on an xslfo-proc prototype (in Perl) for months earlier this year. > I started out with the layout manager idea. It became increasingly clear to > me that there was in fact a natural 1-1 correspondence between managers and > FOs. I had a prototype, incidentally, which properly handled > reference-orientation in all regions, and even took RO down to > block-containers, something which no implementation (not FOP, not XEP, not > XSLFormatter, not XFC) has correctly done. Unless Epic handles RO correctly, > which I don't know. > > It's also interesting, Joerg, that you should mention a "hard to understand" > layout manager class hierarchy...this is also what inevitably developed in > my prototype. So at some point (and I think there are comments and emails to > support this) I eventually came back to the thought that there is nothing > wrong with individual FOs being able to do their own layout. Which is > actually the existing "maintenance stream" FOP model. I still believe that it is useful to have the layout managers separate from the fo tree. There are a number of reasons that come to mind. It is possible to independantly change layout managers. Certain fo's aren't directly in the same hierarchy: markers, undefined table columns, table cells under table body. Then there are things like floats and footnotes that can gain from this. > I'll have some more to say laterthese are immediate comments. I am just > struck by the fact that it is now December 2002 and we are not where we want > to be, not even close, which is providing an open-source Extended > conformance XSL processor to the hungry, huddled and poor. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Arved Sandstrom wrote: I actually helped push for this last year - the notion of separate layout managers. I was strongly influenced by the mess that FOP code had become at the time, and really thought that layout should be taken out of the FOs themselves; that the FO's, in a sense, were (or should be) just value objects. I worked on an xslfo-proc prototype (in Perl) for months earlier this year. I started out with the layout manager idea. It became increasingly clear to me that there was in fact a natural 1-1 correspondence between managers and FOs. I had a prototype, incidentally, which properly handled reference-orientation in all regions, and even took RO down to block-containers, something which no implementation (not FOP, not XEP, not XSLFormatter, not XFC) has correctly done. Unless Epic handles RO correctly, which I don't know. It's also interesting, Joerg, that you should mention a "hard to understand" layout manager class hierarchy...this is also what inevitably developed in my prototype. So at some point (and I think there are comments and emails to support this) I eventually came back to the thought that there is nothing wrong with individual FOs being able to do their own layout. Which is actually the existing "maintenance stream" FOP model. Here are a couple. I remembered these exchanges, and was wondering whether you might mention them in this context. http://sourceforge.net/mailarchive/forum.php?thread_id=740835&forum_id=450 http://sourceforge.net/mailarchive/message.php?msg_id=1780417 Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
Response below. > -Original Message- > From: J.Pietschmann [mailto:[EMAIL PROTECTED]] > Sent: December 7, 2002 7:16 PM > To: [EMAIL PROTECTED] > Subject: Re: Redesign issues > [ SNIP ] > Now the biggest issue: the layout managers itself. At the first > glance it is > not obvious why they should be first class objects at all, in > particular as > a cursory examination of the code shows a one-to-one correspondence to FOs > both for classes and instances. Well, layout managers abstract the layout > *process*, however, the deep layout manager class hierarchy is > mainly designed > around code reuse, which makes it really hard to understand. > There is a reason > that design rules recommend against overuse of inheritance for > code reuse and > deep inheritance hierarchies. There is only so much someone can > hold in the > brain. Nevertheless, this is something I don't know how to fix on > the cheap. I actually helped push for this last year - the notion of separate layout managers. I was strongly influenced by the mess that FOP code had become at the time, and really thought that layout should be taken out of the FOs themselves; that the FO's, in a sense, were (or should be) just value objects. I worked on an xslfo-proc prototype (in Perl) for months earlier this year. I started out with the layout manager idea. It became increasingly clear to me that there was in fact a natural 1-1 correspondence between managers and FOs. I had a prototype, incidentally, which properly handled reference-orientation in all regions, and even took RO down to block-containers, something which no implementation (not FOP, not XEP, not XSLFormatter, not XFC) has correctly done. Unless Epic handles RO correctly, which I don't know. It's also interesting, Joerg, that you should mention a "hard to understand" layout manager class hierarchy...this is also what inevitably developed in my prototype. So at some point (and I think there are comments and emails to support this) I eventually came back to the thought that there is nothing wrong with individual FOs being able to do their own layout. Which is actually the existing "maintenance stream" FOP model. I'll have some more to say laterthese are immediate comments. I am just struck by the fact that it is now December 2002 and we are not where we want to be, not even close, which is providing an open-source Extended conformance XSL processor to the hungry, huddled and poor. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Keiron Liddle wrote:
As far as I am concerned it is largely irrelevant whether the particular
layout design is 100% correct.
There will never be a design which is 100% correct. However, some designs
are easier to comprehend than others. The HEAD design has a few stumbling
blocks for beginners.
Let's start with LMiter. The class name is not only badly abbreviated,
it is also misleading if spelled out a LayoutManagerIterator. Commonly,
iterators are named after the collection the are iterating, not after
the data they expect to be in the collection. The main problem is that
the collection with said LayoutManagers is purely virtual and never
exists as an object, which makes it very hard to grasp where the
layout managers come from. This severly disrupts tracking the control
flow. Furthermore, just looking at the LMiter source it appears to be
horrible, for once because of the creation with a base iterator, and
secondly the because of the preLoadNext() which is not called in next().
This indicates that some interesting things happen outside of the LMiter
class and a that encapsulation is violated. Also, from the implementation
of LMiter it is *still* not clear what's iterated here. Suggestion: either
implement a LayoutManagerList and an associated LayoutManagerListIterator
and make them self contained and transparently caching, or move the state
keeping and access into the LayoutManager itself.
There is also the BreakPosPossIterator which also doesn't iterate over a
tangible collection. In fact if you see
public void addAreas(PositionIterator parentIter, ...
there is no way to say what the heck is iterated here. Furthermore, this
iterator violates common Java iterator patterns, in particular
while ((childLM = breakPosIter.getNextChildLM()) != null) {
childLM.addAreas(breakPosIter, lc);
should better be
while (breakPosIter.hasNext()) {
childLM = breakPosIter.next().getChildLM();
childLM.addAreas(breakPosIter, lc);
}
Also, such an iterator is often created by something which is not the
collection iterated over but with constraints which represent a
subcollection of the collection iterated over:
PositionIterator breakPosIter =
new BreakPossPosIter(blockBreaks, iStartPos,
lfp.getLeafPos() + 1);
This makes it even harder to keep track where the iterator actually points
and what this means.
A third point, uncanny in itself but still minor overall is the distinction
between positions and break possiblities. This implies that either positions
are used for something else beside break possibilities, or break possibilities
can be something else than positions. But most of the source implies that
neither will ever be the case. Unfortunately, while examining a layout manager
implementation, the users sees first that a collection with break possiblities
is created, and then there is a loop over positions which adds areas. It would
be easier to understand if the same abstraction, break possibility, was used
in both parts of the code. One of the possiblities is to unify break
possiblities and positions, another would be to use break possibilities only
and retrieve positions from them as needed.
Now the biggest issue: the layout managers itself. At the first glance it is
not obvious why they should be first class objects at all, in particular as
a cursory examination of the code shows a one-to-one correspondence to FOs
both for classes and instances. Well, layout managers abstract the layout
*process*, however, the deep layout manager class hierarchy is mainly designed
around code reuse, which makes it really hard to understand. There is a reason
that design rules recommend against overuse of inheritance for code reuse and
deep inheritance hierarchies. There is only so much someone can hold in the
brain. Nevertheless, this is something I don't know how to fix on the cheap.
HTH
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
Response below. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Fri 12/6/2002 6:05 AM To: FOP Cc: Subject: RE: Redesign issues I previously said: >> My personal problems aside, we're approaching a maintenance freeze, right? Shouldn't that mean it's time to figure out what our next step is going to be in a very clear way and keep hashing this out until we've got a list of tasks to complete?<< Keiron said: >Good point. Maybe we can create a comprehensive list broken into various sections.< We have a Wiki that seems to have been a good way of quickly throwing up ideas for style guidelines and voting on them. Why don't we do the same thing here? We could throw up our ideas, try to sort them into "lofty, long term" stuff and "immediate tasks" and whatnot. Yeah...Bugzilla can be used somewhat, but I think this would be a better way to go when it comes to collaboratively creating a game plan. Anyone else have thoughts on this? I say we set up another page on our Wiki. <>- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
On Thu, 2002-12-05 at 15:28, Rhett Aultman wrote: > This is something I'd really like to see hashed out better. We're winding down on >the maintenance brach. I've read a majority of the source in HEAD other than the >renderers (which I don't feel qualified or interested in, anyway), and I understand >the ideas in there, but I don't see the line of attack we want to take with this. > > I, personally, would like to see some objectives and plans laid out that I and >others can follow, especially with respect to the layout mechanisms. I'm doing my >best to be involved and follow the lead of the committers here, but the lead's not >clear. With respect to the layout system, Keiron has explained a few of the smaller >aspects of what should happen when he's got the whole thing together, and I would >like to help in making that happen, but I really feel that I can't until I see the >plan. As a developer, I'm following the lead of my committers. > > My personal problems aside, we're approaching a maintenance freeze, right? >Shouldn't that mean it's time to figure out what our next step is going to be in a >very clear way and keep hashing this out until we've got a list of tasks to complete? Good point. Maybe we can create a comprehensive list broken into various sections. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Keiron Liddle wrote: On Thu, 2002-12-05 at 13:01, Peter B. West wrote: There is an implication in what you are saying that you do have the direction forward for the FO processor "internalised", so to speak, and that a complete FO processor is, as Christian says, just a matter of time. I, and I suspect Arved, wonder why that is not clear to everyone. You have a great track record in FOP over a long period, and if you insist that the redesign is moving towards completion, I would be inclined to believe you, but I do need to be shown how. Arved also has a great track record over many years in FOP, and Arved seems to be skeptical. Please define "redesign". The following things are at least better than anywhere else: area tree, image handling, pdf lib, svg, renderer. Fo tree is better than the maintanence branch. See comments below. If you are referring to the layout then I can't say that it is anywhere near completion, but in general it is currently better than the maintanence branch. (lack of a number of features and missing words aside) It seems to me that a lot of the arguments are of this type: http://www.intrepidsoftware.com/fallacy/straw.htm As far as I am concerned it is largely irrelevant whether the particular layout design is 100% correct. Yes it is extermely important and will be best tackled by breaking it down into smaller problems. But so far I have only heard arguments against two methods in the layout managers, getting breaks and reset. Sure it probably would be helpful to design a layout algorithm isolated from all the other stuff and that is something that someone could pursue. Noted. Believe me, I can find plenty of other things to do that have no relation to the layout. Still, from my perspective it is a high priority to get it to a level similar to the maintanence branch, this will make fixing bugs, responding to users, integration with other projects documentation etc. a lot easier. Then to move forward from there. In any case, I would like to be able to make useful suggestions concerning the redesign. I have many times in the past expressed the genuine hope for the success of FOP by whatever path, and I had never, until recently, even suggested that anyone commit to alt.design over the HEAD redesign. I cannot, however, commit to a design that I either do not understand, or do not have any confidence in. Who can? If all you care about is a perfect layout then that is reasonable, then reduce the problem/difference to the layout. Most users care more about lots of other issues. Catering for these users will help us IMHO. Keiron, We seem to have achieved considerable agreement here. From what you say above, the HEAD redesign is nearing the point at which it can take over from the maint branch as the usable version of FOP. That solves one of the problems that Karen mentioned, and will integrate the efforts of those with production commitments, and those working on the New Design. You say, above: > Sure it probably would be helpful to design a layout algorithm isolated > from all the other stuff and that is something that someone could > pursue. I'll put my hand up for this. It is my intention to scavenge as much code as possible from HEAD to implement the design. It may not come to that. If those working on HEAD adopt elements of alt.design as they see the possibilty and benefit of so doing, the incremental design approach you favour and alt.design may turn out to be synergistic. In any case, I hope to pursue these goals without feeling a pariah in the FOP development community, when my purpose is a better FOP. I hope this goal remains relevant across Sun's pending announcement. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
On Thu, 2002-12-05 at 13:01, Peter B. West wrote: > There is an implication in what you are saying that you do have the > direction forward for the FO processor "internalised", so to speak, > and > that a complete FO processor is, as Christian says, just a matter of > time. I, and I suspect Arved, wonder why that is not clear to > everyone. > You have a great track record in FOP over a long period, and if you > insist that the redesign is moving towards completion, I would be > inclined to believe you, but I do need to be shown how. Arved also > has > a great track record over many years in FOP, and Arved seems to be > skeptical. Please define "redesign". The following things are at least better than anywhere else: area tree, image handling, pdf lib, svg, renderer. Fo tree is better than the maintanence branch. If you are referring to the layout then I can't say that it is anywhere near completion, but in general it is currently better than the maintanence branch. (lack of a number of features and missing words aside) It seems to me that a lot of the arguments are of this type: http://www.intrepidsoftware.com/fallacy/straw.htm As far as I am concerned it is largely irrelevant whether the particular layout design is 100% correct. Yes it is extermely important and will be best tackled by breaking it down into smaller problems. But so far I have only heard arguments against two methods in the layout managers, getting breaks and reset. Sure it probably would be helpful to design a layout algorithm isolated from all the other stuff and that is something that someone could pursue. Believe me, I can find plenty of other things to do that have no relation to the layout. Still, from my perspective it is a high priority to get it to a level similar to the maintanence branch, this will make fixing bugs, responding to users, integration with other projects documentation etc. a lot easier. Then to move forward from there. > In any case, I would like to be able to make useful suggestions > concerning the redesign. I have many times in the past expressed the > genuine hope for the success of FOP by whatever path, and I had never, > until recently, even suggested that anyone commit to alt.design over > the > HEAD redesign. I cannot, however, commit to a design that I either do > not understand, or do not have any confidence in. Who can? If all you care about is a perfect layout then that is reasonable, then reduce the problem/difference to the layout. Most users care more about lots of other issues. Catering for these users will help us IMHO. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
Responses below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 5:27 PM To: fop-dev Subject: Redesign issues >> This is the question that everyone has to answer. Blind faith that that the problem can be solved by simply hurling onself at it is not enough. I'm not saying that Keiron and Karen are in that situation, but I suspect that others are. An elegant and comprehensive plan of attack, including a design approach that can confidently be expected to crack the toughest problems, may exist in their imaginations, but it needs to be made manifest before any sort of team attack can be made on the problems. << This is something I'd really like to see hashed out better. We're winding down on the maintenance brach. I've read a majority of the source in HEAD other than the renderers (which I don't feel qualified or interested in, anyway), and I understand the ideas in there, but I don't see the line of attack we want to take with this. I, personally, would like to see some objectives and plans laid out that I and others can follow, especially with respect to the layout mechanisms. I'm doing my best to be involved and follow the lead of the committers here, but the lead's not clear. With respect to the layout system, Keiron has explained a few of the smaller aspects of what should happen when he's got the whole thing together, and I would like to help in making that happen, but I really feel that I can't until I see the plan. As a developer, I'm following the lead of my committers. My personal problems aside, we're approaching a maintenance freeze, right? Shouldn't that mean it's time to figure out what our next step is going to be in a very clear way and keep hashing this out until we've got a list of tasks to complete? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Karen Lease wrote: Peter, ... ... I will make a few comments on the "redesign" issue. I agree with Arved that we certainly have some large problems to face. As he points out, the mainstream redesign suffers from not being understood and therefore from a lack of active contributors. ... Insofar as I was quite involved in the initial idea and in some of the initial coding, I certainly helped chart this course, and there was quite a lot of discussion on the list concerning these ideas. I was aware of that, and I apologise if I have given the impression that I was not. Unfortunately I've been unable, because of work pressure, to contribute anything useful to the rewrite since early summer. However, I've tried to at least keep an eye on what was going on. What I see is that Keiron has been carrying on almost alone with the rewrite which we had started together, despite quite a lot of efforts to get more people (Joerg notably) involved in it. It's clear that one person on such a large job is not enough, even if the person has as much energy and talent as Keiron. And even if I were still involved, two people is still not enough. I did make some efforts to describe the general idea early this year, and Keiron wrote quite a lot of things as well: the whole understanding series and some design notes. But if people are not able to get over the entry barrier, than perhaps the idea or the way it is implemented is just too complex. Or perhaps we haven't written the right kind of documents. This may be the nub of the documentation problem. I fall into a similar trap very often. From within your own understanding it is almost impossible to get back to the pristine mind-set of anyone approaching the problem cold. I have never seen this problem dealt with very successfully anywhere. However, I think there is another factor contributing to the lack of general involvement in the rewrite streams, either the "main" or the "alt-design". This is that a large number of people, and I assume that includes many of the committers, are actually using FOP on a day-to-day basis to do real work. When one is in that state, it is much easier to justify working on fixing critical (or even just plain annoying) bugs in the "0.20.x" series than to find time to bring forward a "developer release" which is not yet capable of actually composing most documents. I know we already had this discussion some months ago and it was more or less decided to try to put out 0.20.5 and to stop development on the maintenance branch. I don't know if this is really possible; I for one am now using FOP in production and need some work done which will not be done in 0.20.5 (assuming we push it out the door fairly soon.) Until we get over this hurdle, neither "Main" nor "Alt-design" is going to be able to get far enough along to prove that it can do a better job at layout than current FOP. I still basically believe in the rewrite, and I don't know enough about Alt-design to judge its merits. I think we _do_ need to focus on the essential: implementing an FO processor. I personally don't think building the FO tree or even property handling is central to our problems today. Neither is perfect, but both are functional. I agree that implementing an FO processor is the essential thing. Alt.design started as a sidetrack for me to 1) implement pull-processing (although I didn't call it that) for the FO tree bulding, 2) to see whether properties could have a more compact resolution, and 3) to look at a galley-based method of implementing the layout engine. Properties just sucked me dry, as you would understand. Although it is not yet complete, if the FO tree work were found to be useful, it could be bolted onto the existing design without an outrageous amount of work. In any case, I am now at the point of seriously considering where to put my effort in the layout. If you can convince me that it's going to work I will join you. There is an implication in what you are saying that you do have the direction forward for the FO processor "internalised", so to speak, and that a complete FO processor is, as Christian says, just a matter of time. I, and I suspect Arved, wonder why that is not clear to everyone. You have a great track record in FOP over a long period, and if you insist that the redesign is moving towards completion, I would be inclined to believe you, but I do need to be shown how. Arved also has a great track record over many years in FOP, and Arved seems to be skeptical. In any case, I would like to be able to make useful suggestions concerning the redesign. I have many times in the past expressed the genuine hope for the success of FOP by whatever path, and I had never, until recently, even suggested that anyone commit to alt.design over the HEAD redesign. I cannot, however, commit to a design that I either do not understand, or do not have any confidence in. Who can? In order for the "s
