Re: FOTreeBuilder/ElementMapping change ideas
Victor and fopdevs, See below... Victor Mote wrote: Peter B. West wrote: I'm pleased and surprised to hear that most of your design questions have been answered. What scope of design are you talking about? Ah, a good question. The scope of design on which I am currently working is: 1) refactor the startup procedures (Driver) into Session, Document, RenderContext, and RenderTask objects for greater reusability of each of those items. 2) refactor the redesign layout into a component that can very easily be replaced by some other layout engine. This is a very nasty one. The maintenance and the HEAD code may encourage you to believe that it is not. What I am looking to do next with alt.design is to make the resolution of FO nodes occur in the context of the Area into which the FO node is being composed. I.e., to intimately link FO tree and Area tree construction. I am intending to do this because I believe it is the only comprehensive and clean solution to the problem. 3) drop the old (maintenance branch) engine into the redesign code, if possible, using the same concept described in #2 above. You are correct that not all of my layout design questions have been answered. However, I am convinced that completing the above work is the quickest way to getting those questions answered, because it will get our common code base components (those other than layout) common again, and get layout to the place where we can have more than one option. It will take me a while to get through this big-picture work before I can start on layout again. I am a little more disturbed to hear that alt.design is once again my baby. I have been posting here intermittently over the past few weeks with design notes that explore the implications of my discoveries about the impact of some particulares of the Rec on my current properties handling, the implications for the layout of those issues and the integration of alt.design, and some general questions of layout design. Here is my frank take on the alt.design work: I /think/ you are on the right track as far as properties go. In a general way I understand the problems you have described about actual layout placement driving some of the property creation. I am inclined to think that these problems can be solved in layout itself rather than trying to make layout drive the FO tree creation. See above. However, I may be wrong, and at some point (not today) I may try to get better up to speed on this issue. I am not very excited at all about the pull parsing concept. It took me a while, but I finally got generally comfortable with the way our parsing now works, and went to the trouble of documenting why in our developer doc, with the hope that we can reach consensus around it, and prevent future new developers from stumbling there. I have made some comments about the way our parsing now works in another post. The reason I have not jumped into the alt.design work is that I do not see it as /the/ most important place to spend my efforts. That does not mean that it is not important, just that it is not as high on my priority list as it is on yours. With that said, I am eager to see the working code from your efforts (even the ones that I am inclined to disagree with), and to hear how they will benefit the project. Until there are pieces of alt.design that are ready to be merged into the trunk, it all seems like speculation. Agreed, which is why I a going to follow through on the implications of the Rec rather than try to integrate a model of FO tree parsing and construction which I know to be flawed. And rest assured that I will reserve judgment about all of it until that time -- I kick myself about 10 times a day as I discover things that I think I should have known before. ... I freely admit that I have not yet grasped why layout should affect properties. I understand that marker properties need to be resolved at layout time, but it seems like the property in the FO tree then becomes the integer equivalent of to be resolved. Marker processing is a clear example of the serendipitous advantages of pull parsing. It is the pull parsing design that makes the resolution of markers in static-content a near-trivial exercise. If you refer back to the diagrams I posted about marker processing, you will see that streams of FoXMLEvents are being buffered in two places. If the input buffer is a parameter, the normal FO tree building processes can be invoked on such buffers, which can also be dynamically switched to include the marker subtrees from earlier fo:marker processing. All of this may simply be because my comments are not considered relevant. Nonetheless, I believe that the *kind* of design commentary I am making is of great value in the development of the design of layout. irrespective of the particulars of my work. One of the problems of getting more people involved in the redesign work is the opacity of the process. It seems to me that the redesign
Re: FOTreeBuilder/ElementMapping change ideas
Victor Mote wrote: Glen Mazza wrote: No response on the below questions from any committer, and I'm concerned about the drop-off on the FOP-DEV mailing list over the past few weeks (at an extrapolated 170 emails on FOP-DEV for the month, this would be our lightest month since Dec. 1999!) Well, I think you solved that problem :-) :-) -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOTreeBuilder/ElementMapping change ideas
Glen Mazza wrote: --- Peter B. West [EMAIL PROTECTED] wrote: I thought it was generally agreed some time ago that my work on properties should be integrated, for the simple reason that it is smaller and faster. Exactly! Now you're talking my language--smaller and faster--i.e., something that will generate more same-size reports than trunk will ... However, per the centripetal/centrifugal discussion of Victor (*very* interesting, BTW), we need to see *proof* that it is faster, and to help do that, we should make the code more modular. http://marc.theaimsgroup.com/?l=fop-devm=103890259919360w=4 http://marc.theaimsgroup.com/?l=fop-devm=103918886413611w=4 -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOTreeBuilder/ElementMapping change ideas
Peter B. West wrote: What's happened to the redesign? I have nothing to prove - you guys do. I'll just keep working, publishing design notes for anyone who is interested, and, when I get chunks of code working, I'll publish the comparisons. Shall we put them to the vote? Will a vote decide whether alt.design property handling is faster and smaller? As I said before, there are opportunities to make redesign code faster and smaller. To compare the two, we need to see the things that are unique to the pull parsing approach. And more important than that, faster and smaller will not trump cleaner and more flexible (at least for me). Note that I am quite happy to work towards integrating a fully-working FO and area tree susbsystem into the redesign. I will not devote time to hacking such a working system apart to place nuggets of the original into a design in which I, as yet, have no confidence. OK, this all-or-nothing approach is news to me. So Glen actually better understood how matters stood on this issue than I did. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOTreeBuilder/ElementMapping change ideas
That concerns me as well. Personally, I must say that my fun time is nearing an end. I need to reestablish a more or less regular income in the next couple of months. So a lot of my energy is focused in this direction which means less participation in this project. But it doesn't mean I'm going away. On 16.06.2003 00:11:53 Glen Mazza wrote: No response on the below questions from any committer, and I'm concerned about the drop-off on the FOP-DEV mailing list over the past few weeks (at an extrapolated 170 emails on FOP-DEV for the month, this would be our lightest month since Dec. 1999!) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOTreeBuilder/ElementMapping change ideas
Victor Mote wrote: Glen Mazza wrote: No response on the below questions from any committer, and I'm concerned about the drop-off on the FOP-DEV mailing list over the past few weeks (at an extrapolated 170 emails on FOP-DEV for the month, this would be our lightest month since Dec. 1999!) At the moment, most of my design questions are answered, and it is merely :-) a question of finding time to implement. I'd like us to continue progress on both Trunk and Alt-Design until (1) at least one of the two methods are finished or (2) they've been merged completely. I would be happy to work as best I can towards both goals. Do the committers need to have a vote on this? I think most of us treat Alt-Design as Peter's baby and expect him at some point to propose a reintegration of some or all of his work into the trunk. We need to get working again. There are probably multiple opinions about how best to proceed. My personal view is that our biggest problem is not integrating Alt-Design, but rather integrating the maintenance branch and the trunk so that we are releasing and developing in the same branch. To that end, I am (as we speak) trying to untangle Driver into Session, Document, and RenderContext objects, as the first step toward refactoring to LayoutStrategy. So I guess I am working along a different line, but working nonetheless. Victor, I'm pleased and surprised to hear that most of your design questions have been answered. What scope of design are you talking about? I am a little more disturbed to hear that alt.design is once again my baby. I have been posting here intermittently over the past few weeks with design notes that explore the implications of my discoveries about the impact of some particulares of the Rec on my current properties handling, the implications for the layout of those issues and the integration of alt.design, and some general questions of layout design. In making those notes, I have been at pains to illustrate my points with either new diagrams or reference to existing ones. I have gone to those lengths because I an anxious to communicate my ideas as accessibly as possible. When I was working on the properties implementation, I found that my attempts to explain what I was doing were met with blank incomprehension. I am trying more diligently to circumvent such a situation now. However, it seems that I am still working in something of a vacuum. I have had a little feedback, but it did not relate specifically to the possible impact of my ideas or the alt.design properties integration, on the design of layout. All of this may simply be because my comments are not considered relevant. Nonetheless, I believe that the *kind* of design commentary I am making is of great value in the development of the design of layout. irrespective of the particulars of my work. One of the problems of getting more people involved in the redesign work is the opacity of the process. It seems to me that the redesign documentation is, to too great an extent, simply the code. I say this in spite of the other documentation that has been done. Add to this the opacity of the code itself, evidenced by a number of Joerg's comments over the past few months, and I think there is good cause for extensive documentation and diagramming of the intention and direction of the design, and of various critical algorithms, using a combination of text, diagrams and code fragments, in a way similar to the approach I have been attempting with the alt.design documention and recent discussions. The easiest way to proceed is to hack existing code. It's the conventional wisdom, it gives instant gratification and feedback, and one always has something that works - sort of. Granted, the HEAD base incorporated new design approaches when it was initiated, but my feeling is that HEAD redesign is now progressing by the above method. So far, this approach to development has not succeeded in resolving the thornier design issues thrown up by the Rec. I'm not saying that Kieron, Joerg and yourself will not succeed where others have failed. But I would like to see the process made as transparent as possible. (Your work on the rationalisation of the web site is a step in that direction.) One of the major virtues of trying to explain what one is attempting to do in advance, is that it wonderfully clarifies the thinking. Here endeth the gripe. Thank you for listening. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOTreeBuilder/ElementMapping change ideas
Peter B. West wrote: The easiest way to proceed is to hack existing code. Text-align=justify is broken in HEAD. Challenge: make it work. Right aligning works, so this should be easy... I bet quite a few people looked at it and decided there are less challenging but equally important (to them) things to do. sarcasm off If I could get some time, I probaly could pull it. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOTreeBuilder/ElementMapping change ideas
Peter, The decision to stop work in trunk--and to place all efforts into alt-design, should be put to a vote first by the committers. I'm quite reluctant for us to be putting all our eggs in one basket at this time. I want alt-design to win because it became the better implementation over an optimized trunk code--not because we kept purposefully trunk incomplete, buggy and unoptimized so that six months down the road we had no other choice but to go to alt-design. And if we kept trunk unimproved, what would happen should the lead developer on alt-design find out he doesn't have the time to complete his work? We've been in this situation before--this is a very time-consuming project and it could happen. We need a fallback. What *does* work is continually modularizing the code so alt-design can better fit in component-by-component where possible, and also incorporating your findings within the trunk design so we can continually reduce the delta between the two branches. (Besides...some of us happen to enjoy hacking code and optimizing it...Don't take away our fun! ;) Glen --- Peter B. West [EMAIL PROTECTED] wrote: Victor Mote wrote: __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOTreeBuilder/ElementMapping change ideas
Glen Mazza wrote: The decision to stop work in trunk--and to place all efforts into alt-design, should be put to a vote first by the committers. I'm quite reluctant for us to be putting all our eggs in one basket at this time. AFAIK, there is no such proposal on the table from Peter or anyone else. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOTreeBuilder/ElementMapping change ideas
Peter B. West wrote: I'm pleased and surprised to hear that most of your design questions have been answered. What scope of design are you talking about? Ah, a good question. The scope of design on which I am currently working is: 1) refactor the startup procedures (Driver) into Session, Document, RenderContext, and RenderTask objects for greater reusability of each of those items. 2) refactor the redesign layout into a component that can very easily be replaced by some other layout engine. 3) drop the old (maintenance branch) engine into the redesign code, if possible, using the same concept described in #2 above. You are correct that not all of my layout design questions have been answered. However, I am convinced that completing the above work is the quickest way to getting those questions answered, because it will get our common code base components (those other than layout) common again, and get layout to the place where we can have more than one option. It will take me a while to get through this big-picture work before I can start on layout again. I am a little more disturbed to hear that alt.design is once again my baby. I have been posting here intermittently over the past few weeks with design notes that explore the implications of my discoveries about the impact of some particulares of the Rec on my current properties handling, the implications for the layout of those issues and the integration of alt.design, and some general questions of layout design. Here is my frank take on the alt.design work: I /think/ you are on the right track as far as properties go. In a general way I understand the problems you have described about actual layout placement driving some of the property creation. I am inclined to think that these problems can be solved in layout itself rather than trying to make layout drive the FO tree creation. However, I may be wrong, and at some point (not today) I may try to get better up to speed on this issue. I am not very excited at all about the pull parsing concept. It took me a while, but I finally got generally comfortable with the way our parsing now works, and went to the trouble of documenting why in our developer doc, with the hope that we can reach consensus around it, and prevent future new developers from stumbling there. The reason I have not jumped into the alt.design work is that I do not see it as /the/ most important place to spend my efforts. That does not mean that it is not important, just that it is not as high on my priority list as it is on yours. With that said, I am eager to see the working code from your efforts (even the ones that I am inclined to disagree with), and to hear how they will benefit the project. Until there are pieces of alt.design that are ready to be merged into the trunk, it all seems like speculation. And rest assured that I will reserve judgment about all of it until that time -- I kick myself about 10 times a day as I discover things that I think I should have known before. In making those notes, I have been at pains to illustrate my points with either new diagrams or reference to existing ones. I have gone to those lengths because I an anxious to communicate my ideas as accessibly as possible. When I was working on the properties implementation, I found that my attempts to explain what I was doing were met with blank incomprehension. I am trying more diligently to circumvent such a situation now. However, it seems that I am still working in something of a vacuum. I have had a little feedback, but it did not relate specifically to the possible impact of my ideas or the alt.design properties integration, on the design of layout. I freely admit that I have not yet grasped why layout should affect properties. I understand that marker properties need to be resolved at layout time, but it seems like the property in the FO tree then becomes the integer equivalent of to be resolved. All of this may simply be because my comments are not considered relevant. Nonetheless, I believe that the *kind* of design commentary I am making is of great value in the development of the design of layout. irrespective of the particulars of my work. One of the problems of getting more people involved in the redesign work is the opacity of the process. It seems to me that the redesign documentation is, to too great an extent, simply the code. I say this in spite of the other documentation that has been done. Your comments are relevant. However, I frankly see issues like pull parsing to be a net distraction to the project, so I admit that I don't pay much attention to them. However, I think it is a worthy goal for the project to eventually resolve alt-design one way or another, and since you seem somewhat determined to bring the issue to a head, perhaps now is a good time. If you will present your ideas in the form of a proposal(s) to be voted on, I assure you that I will spend whatever time it takes to get up
Re: FOTreeBuilder/ElementMapping change ideas
J.Pietschmann wrote: Peter B. West wrote: The easiest way to proceed is to hack existing code. Text-align=justify is broken in HEAD. Challenge: make it work. Right aligning works, so this should be easy... I bet quite a few people looked at it and decided there are less challenging but equally important (to them) things to do. sarcasm off If I could get some time, I probaly could pull it. Joerg, I'm not sure what you meant, but my comment stands. Whatever it is you need time for (fixing justify or fixing FOP), it seems to me that the only way you will get the time is to limit your other committments and focus your considerable energies. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOTreeBuilder/ElementMapping change ideas
Glen, I hope I did not leave the impression that stopping work on trunk was what I was seeking. I thought it was generally agreed some time ago that my work on properties should be integrated, for the simple reason that it is smaller and faster. It seems now that there are philosophical differences in the group about at least two issues - pull vs push parsing and design methodology (or lack of it). [ Note that my properties handling runs faster in spite of the fact that pull parsing is *inherently* slower that push parsing. It is considerable smaller in spite of the fact that pull parsing *inherently* consumes more objects than push parsing. I'm committed to it because it makes for more readily understood code. In this I agree with Microsoft, surprisingly enough. ] Given that I was talking about the problems which arise from integration, including problems which I have since detected in my own properties implementations, I am surprised that I was misunderstood as seeking a switch to alt.design. However, much of the burden of what I did say relates to the issue of what happens when the lead designer can't do it any more. I'm the one who wants better, moer readily undestandable documentation, better, more readily understood design discussion, better, more readily understood documentation of the implementation details. If you don't believe that, try looking at my (incomplete) documentation of alt.design, and my contributions in this list to design discussions. The whole point of my urgings and example is to make it easier for new developers to come up to speed. Note that, indeed, we have been in this situation before. We still are. I repeat that hacking on the code is easier and more immediately rewarding than thinking through the design. The approaches are not mutually exclusive, and must be mixed, I think. But, here has been too much of the former and too little of the latter, IMO. Welcome aboard. Peter Glen Mazza wrote: Peter, The decision to stop work in trunk--and to place all efforts into alt-design, should be put to a vote first by the committers. I'm quite reluctant for us to be putting all our eggs in one basket at this time. I want alt-design to win because it became the better implementation over an optimized trunk code--not because we kept purposefully trunk incomplete, buggy and unoptimized so that six months down the road we had no other choice but to go to alt-design. And if we kept trunk unimproved, what would happen should the lead developer on alt-design find out he doesn't have the time to complete his work? We've been in this situation before--this is a very time-consuming project and it could happen. We need a fallback. What *does* work is continually modularizing the code so alt-design can better fit in component-by-component where possible, and also incorporating your findings within the trunk design so we can continually reduce the delta between the two branches. (Besides...some of us happen to enjoy hacking code and optimizing it...Don't take away our fun! ;) -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOTreeBuilder/ElementMapping change ideas
Glen Mazza wrote: No response on the below questions from any committer, and I'm concerned about the drop-off on the FOP-DEV mailing list over the past few weeks (at an extrapolated 170 emails on FOP-DEV for the month, this would be our lightest month since Dec. 1999!) Well, I think you solved that problem :-) Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOTreeBuilder/ElementMapping change ideas
--- Peter B. West [EMAIL PROTECTED] wrote: I thought it was generally agreed some time ago that my work on properties should be integrated, for the simple reason that it is smaller and faster. Exactly! Now you're talking my language--smaller and faster--i.e., something that will generate more same-size reports than trunk will. I want it so that when we get performance complaints such as Brian Minchau/Xalan recently did (http://marc.theaimsgroup.com/?l=xalan-devm=105552092525811w=2) we can confidently state that FOP has the best design possible. However, per the centripetal/centrifugal discussion of Victor (*very* interesting, BTW), we need to see *proof* that it is faster, and to help do that, we should make the code more modular. repeated boring discussion on the benefits of encapsulated code That's why I want ElementMappings out of apps package and back into the FOTreeBuilder class. This way, when someone like you has a competing design--no more ElementMappings, use push/pull parsers, widgets, abacuses, chickens, whatever--you only have to change FOTreeBuilder, and not simultaneously 57 places throughout the code. It makes it easier to test/compare different implementations, and less mortifying for such changes to be made because fewer classes need updating. /repeated boring discussion on the benefits of encapsulated code Secondly, as I mentioned earlier about applying your findings, you've already confirmed for me my suspicions that user-defined ElementMappings won't work because the semantics of those mappings would not be understood by the rest of the code anyway (please contradict me here if I'm wrong)--Great, for 1.0, in addition to moving the DefaultMappings to FOTreeBuilder, we can dispense with the code that allows for users to add on their own mappings. Me applying your findings now--even if in a different implementation--saves you the Hey, we can't go to push/pull parsers because we'll lose user-defined ElementMappings!!! argument later. (You'll still have to win the faster argument though... ;) I repeat that hacking on the code is easier and more immediately rewarding than thinking through the design. The approaches are not mutually exclusive, and must be mixed, I think. I agree that hacking the code would be useless for you, because you understand it--but I need to work on the code/refactor it/keep it clean (I have fun with a local version of FOP) just to understand how FOP works. I have apps mostly understood and am now looking at the layout package. This helps me hold more better conversations with the team. But, here has been too much of the former and too little of the latter, IMO. Agreed. I'm happily looking forward to the day when I can debate you on all implementation issues--even trip you up every now and then--until then, I need to keep working on the code to understand it more, and yes, reading your writings more. Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOTreeBuilder/ElementMapping change ideas
Team, No response on the below questions from any committer, and I'm concerned about the drop-off on the FOP-DEV mailing list over the past few weeks (at an extrapolated 170 emails on FOP-DEV for the month, this would be our lightest month since Dec. 1999!) I'd like us to continue progress on both Trunk and Alt-Design until (1) at least one of the two methods are finished or (2) they've been merged completely. I would be happy to work as best I can towards both goals. Do the committers need to have a vote on this? We need to get working again. This thread was prompted by my suggestions earlier for better encapsulating the layout.FOTreeBuilder object, namely, by moving code involving its internal ElementMapping setup from the Driver class to within the FOTreeBuilder itself. Moving layout-specific functionality out of apps package was also the reason for the patch I submitted moving the StructureHandler and LayoutHandler classes to the layout and area packages. These changes may also help our other goals with the application: 1) Avalonization: by moving layout out of the apps package, it makes the apps package more easily expendable with an Avalonized version. 2) multiple LayoutStrategies: Pluggable multiple LayoutStrategy objects probably best attain their pluggability by each object being able to work with the same apps package. (Otherwise, keeping layout functionality in apps package requires then including the apps package within each LayoutStrategy!) 3) Alt-Design: By making the code more modular, we can more easily bring in already completed and optimized portions of Alt-Design to start minimizing the delta between Trunk and Alt-Design. *But*, if the committers need more time for contemplation, that's fine--I'm starting to sink my teeth into other Apache projects as well! ;) Thanks, Glen BTW, how certain are we that alt.design will be ready for 1.0? Has there been agreement on switching the alt.design by the committers yet--to the degree that we should indeed forgo any improvement on the current layout code? I didn't get the impression from Joerg's email http://marc.theaimsgroup.com/?l=fop-devm=105121991624106w=2, that work on layout was frozen in preparation for alt.design--such freezing strikes me as premature right now. Glen --- Peter B. West [EMAIL PROTECTED] wrote: Glen, There is no element mapping in the push parser of alt.design, which we are looking at integrating into the code for 1.0. Peter Glen Mazza wrote: I was looking at how the Driver class initializes its FOTreeBuilder instance with formatting object ElementMappings. This currently occurs in three ways: ... __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOTreeBuilder/ElementMapping change ideas
Glen Mazza wrote: No response on the below questions from any committer, and I'm concerned about the drop-off on the FOP-DEV mailing list over the past few weeks (at an extrapolated 170 emails on FOP-DEV for the month, this would be our lightest month since Dec. 1999!) At the moment, most of my design questions are answered, and it is merely :-) a question of finding time to implement. I'd like us to continue progress on both Trunk and Alt-Design until (1) at least one of the two methods are finished or (2) they've been merged completely. I would be happy to work as best I can towards both goals. Do the committers need to have a vote on this? I think most of us treat Alt-Design as Peter's baby and expect him at some point to propose a reintegration of some or all of his work into the trunk. We need to get working again. There are probably multiple opinions about how best to proceed. My personal view is that our biggest problem is not integrating Alt-Design, but rather integrating the maintenance branch and the trunk so that we are releasing and developing in the same branch. To that end, I am (as we speak) trying to untangle Driver into Session, Document, and RenderContext objects, as the first step toward refactoring to LayoutStrategy. So I guess I am working along a different line, but working nonetheless. Nevertheless, your point is well taken. I will address the remainder of your email in a subsequent message. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOTreeBuilder/ElementMapping change ideas
BTW, how certain are we that alt.design will be ready for 1.0? Has there been agreement on switching the alt.design by the committers yet--to the degree that we should indeed forgo any improvement on the current layout code? I didn't get the impression from Joerg's email http://marc.theaimsgroup.com/?l=fop-devm=105121991624106w=2, that work on layout was frozen in preparation for alt.design--such freezing strikes me as premature right now. Glen --- Peter B. West [EMAIL PROTECTED] wrote: Glen, There is no element mapping in the push parser of alt.design, which we are looking at integrating into the code for 1.0. Peter Glen Mazza wrote: I was looking at how the Driver class initializes its FOTreeBuilder instance with formatting object ElementMappings. This currently occurs in three ways: ... -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FOTreeBuilder/ElementMapping change ideas
I was looking at how the Driver class initializes its
FOTreeBuilder instance with formatting object
ElementMappings. This currently occurs in three ways:
1.) Driver explicitly adds three default element
mappings (FO, SVG, FOP extension) to its FOTreeBuilder
instance
2.) Driver searches META-INF/services directory for
additional user-defined extension mappings, adds them
3.) Driver provides two forms of addElementMapping()
functions for embedded users to explicitly add more
ElementMappings.
(Jeremias explained #2 and #3 process here:
http://marc.theaimsgroup.com/?l=fop-userm=104256122918946w=2)
I see two possible changes for 1.0dev:
1.) For standard reasons of encapsulation/modular
design, also potential future deprecation of the
Driver class, I would like to make the FOTreeBuilder
more standalone. In particular, have (1) and (2) done
within the FOTreeBuilder code itself as part of its
responsibilities.
For (3), we may still need to retain the Driver
addElementMapping() functions for backwards
compatibility. But I would like to have them just
wrap new functions of the same name in the
FOTreeBuilder code:
i.e., Driver's:
public void addElementMapping(ElementMapping
mapping) {
mapping.addToBuilder(treeBuilder);
}
will now be:
public void addElementMapping(ElementMapping
mapping) {
treeBuilder.addElementMapping(mapping);
}
2.) Moving forward, I would like to see the
ElementMapping interface deprecated, and instead have
the mapping classes extend an ElementMap base class.
Features of this base class would be:
a) This base class would have two public member
variables: (1) the URL and (2) its fOObjs HashMap,
for the FOTreeBuilder to use for attaching the
ElementMap.
b) Instead of the ElementMapping-implementing class
attaching itself to the FOTreeBuilder (via
addToBuilder function defined in the interface), the
FOTreeBuilder will do the attaching of the ElementMap
subclass. (This will allow the FOTreeBuilder code to
do some error-checking prior to accepting the
extension class.)
c) The ElementMap base class and its subclasses will
have no reference to an FOTreeBuilder object. They
will be standalone, can be attached to things besides
an FOTreeBuilder, and will work even if the
FOTreeBuilder class is removed.
Let me know if this seems advisable--if desired, I can
try to submit patches on one or both of these.
Thanks,
Glen
__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: FOTreeBuilder/ElementMapping change ideas
Glen, There is no element mapping in the push parser of alt.design, which we are looking at integrating into the code for 1.0. Peter Glen Mazza wrote: I was looking at how the Driver class initializes its FOTreeBuilder instance with formatting object ElementMappings. This currently occurs in three ways: ... -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOTreeBuilder/ElementMapping change ideas
That simplifies things!--just out of curiosity, no user-defined extension mappings either? (Not that I was clear how those would work with the current code anyway...) Thanks, Glen --- Peter B. West [EMAIL PROTECTED] wrote: Glen, There is no element mapping in the push parser of alt.design, which we are looking at integrating into the code for 1.0. Peter Glen Mazza wrote: I was looking at how the Driver class initializes its FOTreeBuilder instance with formatting object ElementMappings. This currently occurs in three ways: ... -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOTreeBuilder/ElementMapping change ideas
No user defined mappings. The semantics of such mappings have to be defined elsewhere anyway. Extensions will have to be programmed in alongside the fo: elements and within the processing logic. Peter Glen Mazza wrote: That simplifies things!--just out of curiosity, no user-defined extension mappings either? (Not that I was clear how those would work with the current code anyway...) -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
