Re: ANN: FOray
Victor Mote wrote: Dear FOP Developers: Hi Victor - welcome back. I was saddened by your decision to leave FOP. After considering a return to FOP development, and briefly discussing the pros and cons with those whom I consider to be the FOP development leaders, I have decided to partially fork FOP into a sourceforge project called FOray: http://foray.sourceforge.net/ Ive taken a look and it all seems to make sense. The main reason for this is that, at the moment anyway, my development goals are quite different from those of FOP's development team. It is likely that my return to FOP development would be a net disruption to the project, which is not my intent. Instead, my hope is that this vehicle will allow me to continue to get my real work done and still cooperate with the FOP development team. I do understand why you have decided to start FOray. Although modularisation is a nice feature, I dont see it as a key goal for FOP. FOP's primary objective is to achieve a working layout. The main things needed to achieve this are listed here: http://xml.apache.org/fop/design/layout.html#status I hope that no one will think that I am recruiting here. I simply thought it would be rude for you to hear about this some other way. I wish you all success. No I dont think that, it is very polite of you to let us know. I cant speak for the team as a whole, but I hope that we will be able to cooperate to a high extent. Chris
Re: Table processing question
Andreas L. Delmelle wrote: Hmm.. Yes, but... these properties are not specifically meant for the rows themselves. They are meant to be propagated to/combined with those defined on the table-cells contained by it. Good point. ( IIC, resolving the possible conflicts WRT backgrounds/borders can be settled, for a large part, at FOTree building time. ) I also have a hunch that this would be very convenient WRT managing rowspans... In that case, TableCells could be added to the TableRow directly, but only temporarily, to defer their finishing (?) Conversely, what about column spans specific just to one row !?! They will be stored in the table-cells, just as they are now. Another good point. doesnt mean dont consider optimization, I just mean working layout takes priority over an optimized one. And it looks like it will be harder to achieve a working layout with your suggested changes. Something I'm very concerned about, which is why I haven't started any work on it yet... wanted to gather your opinions first. Theres no harm in doing work locally and then formulating a patch for review. Right now, I just have a very clear-cut idea on what exactly needs to be done, and if I'm not mistaken, the required changes to Layout will be minimal (see the upcoming follow-up message: will post that one later tonight). For the most part, it will work exactly as it does now, only the code for *creating* the Row and Cell LM's will need a little adjusting (serveTableRow() and serveTableCell() in AddLMVisitor?) Chris
Re: Table processing question - follow-up
Andreas L. Delmelle wrote: comments below: Posting this as a follow-up to my earlier ponderings. If we don't get it implemented, or postpone this one indefinitely, at least we'll have it nicely summed up for possible future use... (Who knows, maybe parts of these remarks can be used to implement the starts-row and ends-row properties for table-cells) snip/ If we manage to make it possible for the Layout Managers to deal with the latter, this would allow us to support tables with or without explicitly defined rows with greater ease (i.e. one strategy fitting both situations). Difference: in a 700-row table, you'd only have one TableRow FObj instead of 700 that remain referenced until the page-sequence is completed... (admitted: it does enlarge the TableCell objects a bit...) Yes, just what I was thinking. TableCell would be quite complicated. Although it is hard to gauge by just talking about it. snip/ While we're at it, add an implementation for the starts-row and ends-row properties. Still mapped to fop.fo.properties.ToBeImplementedProperty, so for starters, change the mapping in fop.fo.FOPropertyMapping to make an EnumProperty for them. In fop.fo.flow.TableCell, add the necessary code to the doSetup() method to make it possible to actually use them... (is there another step I'm missing?) (Come to think of it: the 'width' property for table-cells seems also unimplemented for the moment) This makes sense - what effect would you expect width on table cell to have? I maybe missing something, but the width is derived from table column and cant be overridden for a single cell. Modifications in Layout: as already indicated, I think there are not that many. It will continue to work as it does now. It's only the LM *creation* process that will need a little tweaking... As there will always be a TableRow child present, even if there was none specified in the source FO, the first Row LM will be created anyway. It will just be a matter of adding the Cell LMs as children of the current Row LM, and generating a new Row LM when the Cell in question starts a row. So, for those of you that have read closely (--and have been able to keep awake ;) ): Indeed, it seems as if I'm making things more complicated, since the rows are removed in the FOTree, but are re-introduced in Layout... This is because, AFAICT, the problem with big tables is mainly the creation of the FObj's, so this goes a little step towards solving that one. On top of that, while building the FOTree, it is hardly ever necessary to peek into preceding/following Rows, so the work over there (IMHO) doesn't really *need* multiple TableRow objects for one TableBody. There may be a need to peek at surrounding rows when implementing border-collapse algorithms. Not sure if this peeking will need to be done in FO Tree or layout or both. Just food for thought... hope someone enjoys :) On the whole a very well thought out idea. I dont want you to think I'm discouraging you. You have answered my initial concerns, so why dont you go ahead and make the changes locally and then create a patch for review. It will be easier to discuss pros/cons in more depth by looking at the patch file. Chris
Re: ANN: FOray
Peter B. West [EMAIL PROTECTED] wrote on 18.05.2004 05:59:20: project. The situation with FOray is more complicated. I don't know whether it is Victor's intention to fork from HEAD and continue the development along the lines he has previously discussed, or to attempt to integrate HEAD and the maintenance branch in some way. In any case, what Victor is doing will closely parallel the HEAD development, and this, combined with the possibility of some financial support, has a great potential to de-stabilise FOP. I'm not saying this as a criticism of Victor, but as a bald statement of the reality. Some elaborations on this from my side. Please feel free to ignore it entirely. About 18 months ago, I was in a situation similar to Victor's. I wanted to get a few things done in FOP and did some patches. Like all of you here I realized that FOPs (maintenance) internal structure wasn't all that great. However, unlike the committers here I thought that refactoring the maintenance branch would have been the way to go. My gut feeling was that, given the time available to the committers and the non-existence of a strong head developer, the re-implementation would either take extremely long or fail. Since this was really a gut feeling based on the discussions here and my professional experience, I didn't really speak up, because I didn't really have anything in my hands to prove my point and I also wasn't a stakeholder - so to speak. Maybe that was wrong, maybe not. Well, I discussed a little with Nicola as another interested bystander at that time. Here's an excerpt from my mail that I think still applies: Truth to tell, my greatest fear concerning FOP right now is not the license but that the people involved in the redesign take too long because they don't have enough time. In commercial projects, I've seen the following happen many times: 1. Project A starts and is moderately successful 2. Implementation learnings from A and new requirements toggle the decision for a complete redesign. 3. Project B is kicked off as a result, but progresses slowly (for whatever reasons) 4. A is still in use but needs fixes and some small enhancements, yielding A' 5. Time goes on, A' and B progress further. 6. Someone comes up with a carefully refactored version of A' and B is stopped. I truly hope this doesn't happen with the seemingly long ongoing FOP redesign. This was two years ago, but I think I can still subscribe to it. About 18 months ago, my options were: 1. Get into the hot-headed discussions an try a turn-around to refactoring 2. Fork off an 0.20.3 branch (at that time) on SourceForge (like Victor did now) 3. Write my own XSL formatter. I pretty soon discarded 1. and toyed with 2. However, since sometimes I still have a let's storm that hill attitude and were also pretty familiar with writing text formatters and PS and PDF emitters, I opted to do 3, but to do it as a fun project with an open goal since I didn't have all that much spare time beside my business. Kind of a let's just see what happens project. So what happened was: I now have an XSL formatter that is in my estimation further along than the FOP redesign and that does most things that 0.20.5 does and a lot of things that 0.20.5 does not. I confess that so far, I did borrow the TrueType font reader from FOP. What am I going to do with it? Well, it's not really decided yet. The most likely scenario is to make it a commercial product. BTW: why was I fast? I'm good (like you), I had experience in many of the areas involved, and - very important - I didn't need to discuss my architectural decisions because I did it alone. I had fun. So why am I writing this? First, I very much wish the FOP team and the project to succeed. Even I my pet project is ultimately successful and even if it's a commercial success I firmly believe that we need an open source XSL formatter under the Apache license. Second, maybe to give you second thoughts about what you and Victor are doing. My personal impression and also my recommendation is to: Model A: Let one strong developer with resonable time on his hands drive the development of the redesign until it has so far progressed that it's usable for people currently using 0.20.5. Model B: Refactor the maintenance branch. This keeps more users and therefore more possible contributors on the bandwagon. Refactoring is tedious and needs experience, but you get that experience quickly and the motivation stays over time. Also, the maintenance branch source code is not *that* bad. Yes, it badly needs refactoring in most places, but it's not beyond repair. Since I don't see Model A for FOP currently (no strong developer WITH enough time on the horizon), I believe Model B is what would work best. Your existing development model for FOP 1.0 is taking too long IMO. This is not a criticism of any of you, but a personal assessment of what I think can be achieved with the time
Re: ANN: FOray
[EMAIL PROTECTED] wrote: Some elaborations on this from my side. Please feel free to ignore it entirely. Thanks for speaking up. Just because you are not a committer, doesnt mean your opinion doesnt matter. This is open source way. The project is owned by everyone. snip/ 5. Time goes on, A' and B progress further. 6. Someone comes up with a carefully refactored version of A' and B is stopped. This is very true, I also have the same concerns, which is why I have set out some simple objectives that must be met before the redesign is ready for an initial release. See here: http://xml.apache.org/fop/design/layout.html#status-todo We have in fact completed the first item. Once we have completed the other tasks the redesign wont be far behind 0.20.5. Once we do a release, I believe the project will gain some momentum. So what happened was: I now have an XSL formatter that is in my estimation further along than the FOP redesign and that does most things that 0.20.5 does and a lot of things that 0.20.5 does not. I confess that so far, I did borrow the TrueType font reader from FOP. What am I going to do with it? Well, it's not really decided yet. The most likely scenario is to make it a commercial product. BTW: why was I fast? I'm good (like you), I had experience in many of the areas involved, and - very important - I didn't need to discuss my architectural decisions because I did it alone. I had fun. I'm impressed. You must have a lot of spare time, and be a very talented programmer. I would be grateful if you could help with any of the tasks listed above, so we can get a release of the redesign and overcome FOP's current dilema. Model A: Let one strong developer with resonable time on his hands drive the development of the redesign until it has so far progressed that it's usable for people currently using 0.20.5. Model B: Refactor the maintenance branch. This keeps more users and therefore more possible contributors on the bandwagon. Refactoring is tedious and needs experience, but you get that experience quickly and the motivation stays over time. Also, the maintenance branch source code is not *that* bad. Yes, it badly needs refactoring in most places, but it's not beyond repair. The redesign project is further along than you might think. 2003 was really bad for the redesign, absolutely zilch progress was made on layout. However, there has been some progress since the end of last year. So if we can just finish the tasks listed above, FOP should be back on the road to success. I'm certainly not keen to drop the redesign so close to the finish line. Perhaps 12 months ago I would have been inclined to agree, but not now. snip/ Like two years ago, I still don't feel all that comfortable about speaking up on this. After all, it's *your* project, and what the f*** do I have to say about it. Ok, this time I decided to do it. Please don't be offended - it's really meant as a personal opinion from an interested bystander. I hope you can accept it as such. I'm glad you have spoken up. And this goes for any other silent folks out there considering the same options. Please speak up - every opinion counts, the project belongs to the community, not just to the committers. Chris
Borders on Blocks
FOP Devs, I would appreciate some advice. I have noticed that top/bottom borders dont work on regular blocks. This is because the PDF Renderer uses block.getWidth() to determine the length of the border lines. Here is a sinnper of Area Tree output: block width=138897 ipd=0 height=274960 block width=0 ipd=138897 height=250351 block width=0 ipd=138897 height=250351 block width=0 ipd=138897 height=22000 lineArea height=22000 text tsadjust=0 props=font-size:2;font-family:F5;color:#00;Home Insurance/text /lineArea Notice how ipd=0 for the top level (static content) block and then width and ipd swap around for regular fo:blocks. Question is, is this wrong, or should the PDF Renderer be changed to consider either IPD or width properties of block? Thoughts will be appreciated. Chris
Re: Borders on Blocks
Chris Bowditch wrote: FOP Devs, I would appreciate some advice. I have noticed that top/bottom borders dont work on regular blocks. This is because the PDF Renderer uses block.getWidth() to determine the length of the border lines. Here is a sinnper of Area Tree output: block width=138897 ipd=0 height=274960 block width=0 ipd=138897 height=250351 block width=0 ipd=138897 height=250351 block width=0 ipd=138897 height=22000 lineArea height=22000 text tsadjust=0 props=font-size:2;font-family:F5;color:#00;Home Insurance/text /lineArea Notice how ipd=0 for the top level (static content) block and then width and ipd swap around for regular fo:blocks. Question is, is this wrong, or should the PDF Renderer be changed to consider either IPD or width properties of block? I think I have solved this mystery. The second level block shown above was a BC with the optional width property not specified. The assigning of width/ipd for a block is done in Block.getParentArea where IPD is always copied and width is based on either IPD or parent width. I have modified this logic a bit so that if the parent width is used, it will fall back to IPD if it is zero. It fixes my problem, but I'll wait for any comments before committing this change. Chris
Re: ANN: FOray
Chris Bowditch [EMAIL PROTECTED] wrote on 18.05.2004 12:03:33: This is very true, I also have the same concerns, which is why I have set out some simple objectives that must be met before the redesign is ready for an initial release. See here: http://xml.apache.org/fop/design/layout.html#status-todo One comment on the todos: - border-collapse is both important and difficult. I am still fiddling with details of the spec. I suggest ugrading the priority. Not supporting border-collapes yields ugly output. We have in fact completed the first item. Once we have completed the other tasks the redesign wont be far behind 0.20.5. Once we do a release, I believe the project will gain some momentum. That I agree with. May I was too pessimistic regarding the progress. I'm impressed. You must have a lot of spare time, and be a very talented programmer. I would be grateful if you could help with any of the tasks listed above, so we can get a release of the redesign and overcome FOP's current dilema. Well, unfortunately not so much spare time, but as I said, doing it alone really, really helps. And I very much tried to aggregate as much spare time as possible into full dev-only days. That helps, too. With the same background, most of you committers could have done the same. If you look at it, most successful projects initially had 1 or 2 people at the start who did the core work, and then others joined to make it complete. If I had joined the redesign team, FOP wouldn't be much farther than it is now, because most of my time would have gone to discussions, which in turn would also have taken up other committer's time. What I *can* offer to contribute is discussion about the FO spec or about implementing PS oder PDF output. This is a concern that we probably share and that needs discussion in any case. However, for actual implementation discussions I feel a little reluctant. If my pet project becomes a product in the future, we will have the same issues coming up here that we had with the RenderX guy speaking up here recently. This is not what I want - though I think what he did was perfectly ok, well-meaning and to be applauded. If I recall correctly, the uproar was resolved, the RenderX guy got his deserved apology, but the consensus was that the FOP code should be kept clean from competitor's code or even ideas. If I remember that correctly and this still stands, then I would rather not discuss algorithms here. Have a nice day out there, Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH
Re: [Bug 29025] New: - Document/LayoutStrategy consolidation
Simon Pepping wrote: Note in this respect the comment in LayoutStrategy.java: /** Useful only for allowing subclasses of AddLMVisitor to be set by those extending FOP **/ right above private AddLMVisitor addLMVisitor = null; I think you should copy that comment to Document.java as well. Just added the comment, thanks. Now I'm back to (1) the space-before/space-after issues on both static-content and fo:flow, and to hopefully (2) add to Andreas' research on the table issue. I tried to run a report at work on 1.0 instead of 0.20.5 and had found five bugs--I fixed four of them, the spacing issues are the last, and then (at least for my report) 1.0 is as good as 0.20.5. Then, test my next report..., and the next, and the next, then finally...the Docbook fo stylesheet! Glen
Re: ANN: FOray
[EMAIL PROTECTED] wrote: Chris Bowditch [EMAIL PROTECTED] wrote on 18.05.2004 12:03:33: This is very true, I also have the same concerns, which is why I have set out some simple objectives that must be met before the redesign is ready for an initial release. See here: http://xml.apache.org/fop/design/layout.html#status-todo One comment on the todos: - border-collapse is both important and difficult. I am still fiddling with details of the spec. I suggest ugrading the priority. Not supporting border-collapes yields ugly output. What I forgot to say is that I think we should do an initial release of FOP after doing just High priority TODO items. Yes, ugly output can be caused without border collapse, but yet RenderX's XEP doesnt have border collapse, so I dont see an immediate need for it. After all, output only looks ugly if you specify borders on every cell edge, with careful writing of the FO, the output can still look good without border collapse. Well, unfortunately not so much spare time, but as I said, doing it alone really, really helps. And I very much tried to aggregate as much spare time as possible into full dev-only days. That helps, too. With the same background, most of you committers could have done the same. If you look at it, most successful projects initially had 1 or 2 people at the start who did the core work, and then others joined to make it complete. If I had joined the redesign team, FOP wouldn't be much farther than it is now, because most of my time would have gone to discussions, which in turn would also have taken up other committer's time. Perhaps, but perhaps not. As long as you dont make major changes, then its possible to proceed without seeking group consent on every little item. Thats what I'm trying to do. Work towards a working layout a bit at a time using the existing redesigned framework. What I *can* offer to contribute is discussion about the FO spec or about implementing PS oder PDF output. This is a concern that we probably share and that needs discussion in any case. However, for actual implementation discussions I feel a little reluctant. If my pet project becomes a product in the future, we will have the same issues coming up here that we had with the RenderX guy speaking up here recently. This is not what I want - though I think what he did was perfectly ok, well-meaning and to be applauded. If I recall correctly, the uproar was resolved, the RenderX guy got his deserved apology, but the consensus was that the FOP code should be kept clean from competitor's code or even ideas. If I remember that correctly and this still stands, then I would rather not discuss algorithms here. Fair enough. That was an unfortunate affair, and one I'm keen not to repeat. Chris
cyrillic
Hello! What wrong with pdf made with cyrillic KOI8-r?
border-collapse WAS: Re: ANN: FOray
Chris Bowditch [EMAIL PROTECTED] wrote on: 18.05.2004 14:31:39: What I forgot to say is that I think we should do an initial release of FOP after doing just High priority TODO items. Ok, that changes things, of course. Yes, ugly output can be caused without border collapse, but yet RenderX's XEP doesnt have border collapse, so I dont see an immediate need for it. After all, output only looks ugly if you specify borders on every cell edge, with careful writing of the FO, the output can still look good without border collapse. True. Well, partially so. If you have, for example, tables with small fonts and lots of narrow columns and horizonal space is scarce, then it gets increasingly difficult to create good-looking table borders between columns without border-collapse. Maybe my focus is shifted a little too much on the actual problems that I have with my customer's requirements. Also, in my formatter, I want to implement the collapsing model early, because it's default in FO and because I want to get everything out of the way that I don't have an immediate solution for. Makes me nervous otherwise. As for FOP, ok, I do agree that getting a formatter out that is at least as good as 0.20.5 may take priority. Bye, Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH Bahnhofstr. 3, 71063 Sindelfingen, Germany Tel.: +49-7031-763863-11, Fax: +49-7031-763863-99 Mobile: +49-173-3016917 Chris Bowditch [EMAIL PROTECTED] schrieb am 18.05.2004 14:31:39: [EMAIL PROTECTED] wrote: Chris Bowditch [EMAIL PROTECTED] wrote on 18.05.2004 12:03:33: This is very true, I also have the same concerns, which is why I have set out some simple objectives that must be met before the redesign is ready for an initial release. See here: http://xml.apache.org/fop/design/layout.html#status-todo One comment on the todos: - border-collapse is both important and difficult. I am still fiddling with details of the spec. I suggest ugrading the priority. Not supporting border-collapes yields ugly output. What I forgot to say is that I think we should do an initial release of FOP after doing just High priority TODO items. Yes, ugly output can be caused without border collapse, but yet RenderX's XEP doesnt have border collapse, so I dont see an immediate need for it. After all, output only looks ugly if you specify borders on every cell edge, with careful writing of the FO, the output can still look good without border collapse. Well, unfortunately not so much spare time, but as I said, doing it alone really, really helps. And I very much tried to aggregate as much spare time as possible into full dev-only days. That helps, too. With the same background, most of you committers could have done the same. If you look at it, most successful projects initially had 1 or 2 people at the start who did the core work, and then others joined to make it complete. If I had joined the redesign team, FOP wouldn't be much farther than it is now, because most of my time would have gone to discussions, which in turn would also have taken up other committer's time. Perhaps, but perhaps not. As long as you dont make major changes, then its possible to proceed without seeking group consent on every little item. Thats what I'm trying to do. Work towards a working layout a bit at a timeusing the existing redesigned framework. What I *can* offer to contribute is discussion about the FO spec or about implementing PS oder PDF output. This is a concern that we probably share and that needs discussion in any case. However, for actual implementation discussions I feel a little reluctant. If my pet project becomes a product in the future, we will have the same issues coming up here that we had with the RenderX guy speaking up here recently. This is not what I want - though I think what he did was perfectly ok, well-meaning and to be applauded. If I recall correctly, the uproar was resolved, the RenderX guy got his deserved apology, but the consensus was that the FOP code should be kept clean from competitor's code or even ideas. If I remember that correctly and this still stands, then I would rather not discuss algorithms here. Fair enough. That was an unfortunate affair, and one I'm keen not to repeat. Chris
Re: cyrillic
Baron Moenghausen wrote: Hello! What wrong with pdf made with cyrillic KOI8-r? Hello, sorry but I dont understand your question. Could you rephrase it and maybe elaborate. Thanks, Chris
RE: Table processing question - follow-up
-Original Message- From: Chris Bowditch [mailto:[EMAIL PROTECTED] Hi Chris, snip / This makes sense - what effect would you expect width on table cell to have? I maybe missing something, but the width is derived from table column and cant be overridden for a single cell. Indeed, but the columns can be absent in the source FO. In which case they're actually to be considered present, and their widths are determined by the cells in the first row (--or, but I didn't dare consider that possibility just yet, in case of auto-layout, by the cell 'in' that column that has the content with the largest width). snip / On the whole a very well thought out idea. I dont want you to think I'm discouraging you. You have answered my initial concerns, so why dont you go ahead and make the changes locally and then create a patch for review. It will be easier to discuss pros/cons in more depth by looking at the patch file. That was what I meant by 'Now, back to work' :) IOW: expect a patch-proposal for this one of the coming days... Cheers, Andreas
RE: Table processing question - follow-up
Andreas L. Delmelle [EMAIL PROTECTED] wrote on 18.05.2004 18:09:15: Indeed, but the columns can be absent in the source FO. In which case they're actually to be considered present, and their widths are determined by the cells in the first row (--or, but I didn't dare consider that possibility just yet, in case of auto-layout, by the cell 'in' that column that has the content with the largest width). As far as I understand the spec, table-column elements with a column-width property are mandatory for tables with fixed table layout. From the spec: 7.26.9.: The column-width property must be specified for every column, unless the automatic table layout is used. To me, this means not only that column-width is mandatory in fixed-layout *if* table-column elements exist, but also that a table-column needs to exist for each column. Since they don't talk about a derived trait, but of a column-width property that also isn't inherited, I can only conclude that must be specified for every column means: 1. In fixed-layout, there MUST be a table-column element for each column. AND 2. In fixed-layout, the column-width property must be set in all table-column elements. Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH Bahnhofstr. 3, 71063 Sindelfingen, Germany Tel.: +49-7031-763863-11, Fax: +49-7031-763863-99 Mobile: +49-173-3016917
RE: Table processing question - follow-up
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Hi Arnd, snip / As far as I understand the spec, table-column elements with a column-width property are mandatory for tables with fixed table layout. *Vry* good point! Yup, got me there... I was mixing the two layout modes (a bit too focused on CSS2). Would this mean that it's actually (a bit) easier than it looks? I'll have to reconsider... Thanks for this effort-saving remark! Cheers, Andreas
Re: ANN: FOray
On Tue, May 18, 2004 at 09:16:23AM +0100, Chris Bowditch wrote: Victor Mote wrote: Dear FOP Developers: Hi Victor - welcome back. I was saddened by your decision to leave FOP. After considering a return to FOP development, and briefly discussing the pros and cons with those whom I consider to be the FOP development leaders, I have decided to partially fork FOP into a sourceforge project called FOray: http://foray.sourceforge.net/ Ive taken a look and it all seems to make sense. I agree. Goal 1. provide a place where enhancements can continue to be made to the working branch of FOP. I sympathize with this goal. The position of the FOP team over the past years w.r.t. the maintenance code is rather strict. It sort of disallows commits to the maintenance branch, even if non-team members come up with a patch. In view of the long time it takes to release a usable version of the development code, it may be wiser to relax this policy, and cooperate on improvements to the maintenance code. 2. modularize FOP's design I do understand why you have decided to start FOray. Although modularisation is a nice feature, I dont see it as a key goal for FOP. FOP's primary objective is to achieve a working layout. The main things needed to achieve this are listed here: http://xml.apache.org/fop/design/layout.html#status I sympathize with this goal as well. I realize that that is not quite in line with my reaction to Glen's recent patch. I agree with Chris and Glen that it is not currently a key goal for FOP. And since we do not have a strong proponent and architect of a modular design, there is little point in leaving bits and pieces in the code. But in the longer run, I consider putting the FOP code in a modular structure as a desirable thing. Meanwhile I will keep adding my small contribution to the layout system of the development code. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
RE: ANN: FOray
Simon Pepping wrote: 2. modularize FOP's design I do understand why you have decided to start FOray. Although modularisation is a nice feature, I dont see it as a key goal for FOP. FOP's primary objective is to achieve a working layout. The main things needed to achieve this are listed here: http://xml.apache.org/fop/design/layout.html#status I sympathize with this goal as well. I realize that that is not quite in line with my reaction to Glen's recent patch. I agree with Chris and Glen that it is not currently a key goal for FOP. And since we do not have a strong proponent and architect of a modular design, there is little point in leaving bits and pieces in the code. But in the longer run, I consider putting the FOP code in a modular structure as a desirable thing. If you guys are as close to having LayoutManager working as has been stated in this thread (and I hope you are), then I agree that modularization would not be the top priority. It is not an end in itself, but a means to an end. When FOP was internally forked 2 1/2 years ago, the only thing that needed to be rewritten from scratch was layout, but the whole project was forked instead. Modularization would have prevented that, and allowed releases to continue even though a chasm was being created and filled simultaneously. The whole nature of refactoring anything is that you do it before you do the real work. That is where FOray starts. The real question on modularity was never whether it should be a priority, but whether it hurt the project. On open-source projects, priorities are really set by each individual. You fix the thing that hurts the most at the moment, and that might be different for each developer. If I am working on A, and you are working on B, as long as your work on B isn't bad for the project as a whole, I have no right to complain. Nobody has yet put forth a good argument against modularization, but it was opposed anyway. So now we'll have a chance to test it in the real world. Consider this -- what if the XSL spec hadn't been split into two pieces? Would the part that we call Xalan today have its development stalled because layout is stalled? If XSL-T and XSL-FO were all in one spec, would we be smart enough to break the implementation into the two projects that it is in today? All we are really talking about here is the principle of encapsulation writ large. Victor Mote
RE: ANN: FOray
Victor Mote [EMAIL PROTECTED] wrote on 18.05.2004 22:12:45: The real question on modularity was never whether it should be a priority, but whether it hurt the project. On open-source projects, priorities are really set by each individual. You fix the thing that hurts the most at the moment, and that might be different for each developer. If I am working on A, and you are working on B, as long as your work on B isn't bad for the project as a whole, I have no right to complain. Nobody has yet put forth a good argument against modularization, but it was opposed anyway. So now we'll have a chance to test it in the real world. In my formatter, I have implemented modularized layout. From the start, I was sceptical, and I was indeed tempted several times to throw the concept out of the window because it got in the way, but in the end it was always possible to maintain the separation of concerns between different kinds of layouters (BlockArea, Table, Page, and List for example) even though the interaction is admittedly complex. And, yes, it's sometimes hard to follow the logic by staring just at the code - which I prefer to using debuggers. To summarize my impressions from this: 1. I would do it again this way. 2. Maintaining clean separation of concerns *forced* me to redesign my layouter interfaces several times when I added new functionality, but I gained an implementation that I still understand clearly in its entirety even I cannot work on it for a week. 3. The only place where I have difficulties after some time off is my BlockAreaLayouter which is one very large chunk of code. Maybe it's even worth factoring out a LineAreaLayouter, though I'm not sure of it - the interaction is really tight. 4. It's too early to estimate how much modularized layout will hurt performance in the end. My gut feeling is: not much, and it's probably wort it. So, from my own experience I can only encourage you to go forward with your plan. For me, it worked so far. Let's see if the XSL rec turns up more nasty surprises... Bye, Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH
Re: ANN: FOray
[EMAIL PROTECTED] wrote: In my formatter, I have implemented modularized layout. From the start, I was sceptical, and I was indeed tempted several times to throw the concept out of the window because it got in the way, but in the end it was always possible to maintain the separation of concerns between different kinds of layouters (BlockArea, Table, Page, and List for example) even though the interaction is admittedly complex. And, yes, it's sometimes hard to follow the logic by staring just at the code - which I prefer to using debuggers. To summarize my impressions from this: 1. I would do it again this way. 2. Maintaining clean separation of concerns *forced* me to redesign my layouter interfaces several times when I added new functionality, but I gained an implementation that I still understand clearly in its entirety even I cannot work on it for a week. 3. The only place where I have difficulties after some time off is my BlockAreaLayouter which is one very large chunk of code. Maybe it's even worth factoring out a LineAreaLayouter, though I'm not sure of it - the interaction is really tight. 4. It's too early to estimate how much modularized layout will hurt performance in the end. My gut feeling is: not much, and it's probably wort it. So, from my own experience I can only encourage you to go forward with your plan. For me, it worked so far. Let's see if the XSL rec turns up more nasty surprises... Arnd, I think you are talking about different modularisation contexts here. You might want to clarify this part of the discussion with Victor. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Incremental vs rewrite
The thing that immediately strikes me about Arnd's development is that it seems to blow away the theory that incremental modification of an existing code base is always the better way to go. IIUC, Arnd wrote a formatter from scratch (except for some fo the font handling) in two years. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Incremental vs rewrite
Peter B. West wrote: The thing that immediately strikes me about Arnd's development is that it seems to blow away the theory that incremental modification of an existing code base is always the better way to go. IIUC, Arnd wrote a formatter from scratch (except for some fo the font handling) in two years. Peter It would be interesting to compare some RenderX example output between the two^H^H^H three (ArndFO, fop-0.20.5, fop-1.0Dev)... I suspect there may be other significant differences as well, with performance, heap, etc. Then again, the more I think about it, the more it seems like Peter's train-of-thought RE: FOP development destabilization. 'We' could be working on FOP development, but instead we're talking about Arnd's (and Victor's) development efforts (I have every reason to believe it is everything he says it is), and discussing how the grass may be greener on the other side of the fence. Web Maestro Clay
