DO NOT REPLY [Bug 28706] - [PATCH] More justification problems
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28706. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28706 [PATCH] More justification problems --- Additional Comments From [EMAIL PROTECTED] 2004-05-17 07:42 --- Hi Simon, thanks for your additional comments. On your first point regarding trailing spaces, just to be clear, are you saying there shouldnt be trailing spaces according to the XSL-FO specification, or is this your opinion? Either way, you may be right, I just want to understand this problem from a specification point of view. After all there is a lot of talk about whitespace handling in the spec, and my understanding was that this is all dealt with in Block.handleWhiteSpace and so any whitespace left after that is intentional by the user, and by preserving it FOP is conforming with the spec. On your second point, I'm afraid I still dont follow completely. You are analysing the problem from a code perspective and seeing a possible flaw in the logic. I understand that, and your reasoning looks good. However, I am taking a step back and saying I do not see the word spaces disappearing. Dont forget that patch 28314 is applied to CVS, so if that patch is the cause of the word disappearing I'm a little puzzled why it doesnt disappear when I run the test. If you have a different test case, then please attach it. Is anyone else observing this anomaly? Chris
Re: Table processing question
Andreas L. Delmelle wrote: snip/ Now, I'm wondering, since the spec states that an fo:table-row doesn't generate any reference areas and since it can contain only TableCells, whether it wouldn't be more interesting (heap-wise :) ) to create just one TableRow object per TableBody, use it to process the TableCell objects in sets, but add the latter objects directly to the TableBody and reset the TableRow every time. IIC, a similar adjustment should then also be made to the Row LM. Definitely worth considering. IOW: as I understand it, right now processing the TableBody iterates over the TableRows (i.e. simply catches the SAX events and blindly maps them to the corresponding Tree structure), as opposed to using a TableRow (catching a first SAX Event into a mutable member variable?) and iterate over groups of TableCells. Since the spec does provide for the starts-row property for fo:table-cells, it shouldn't be that difficult to set these to true to allow the Body and Row LM to determine which Cells are returned by the fo:table-row... The properties of the fo:table-row can be stored in the separate TableCells where applicable (there are no properties specifically meant for fo:table-rows; this occasion could also be used to settle background and border issues). Huh? This is not true. Follow the link you provided to the spec. table-rows can have background and border properties (when border-collapse is on) 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 !?! If I judge correctly this could save a significant amount in memory usage in case of tables with a large number of rows, and could make implementing the table layout algorithms as defined in the CSS spec a lot easier (--at least, it seems more natural, since it's possible that there are no fo:table-rows specified at all, to consider them as optional, rather than having to perform all sorts of ugly tricks to be able to process a fo:table without them --which is a wall I bounced into) OTOH: I do see a challenge in the break-* and keep-* properties on table-rows, but I guess these could as well be stored in the row-starting cells somehow. yes, keep-* properties also apply to rows. On reflection I'm inclided to say it looks easier to stay as we are at the moment. Your idea is definitely worth considering, but since its primary goal is optimization, and at this time our primary objective really should be to get a working layout. That 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. snip/ Chris
RE: Table processing question
-Original Message- From: Chris Bowditch [mailto:[EMAIL PROTECTED] Hi Chris, snip / Huh? This is not true. Follow the link you provided to the spec. table-rows can have background and border properties (when border-collapse is on) 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. ( 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. snip / OTOH: I do see a challenge in the break-* and keep-* properties on table-rows, but I guess these could as well be stored in the row- starting cells somehow. yes, keep-* properties also apply to rows. On reflection I'm inclided to say it looks easier to stay as we are at the moment. Your idea is definitely worth considering, but since its primary goal is optimization, and at this time our primary objective really should be to get a working layout. That 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. 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?) Later, Andreas
RE: Table processing question - follow-up
-Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] 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) The requirements for this I see up to here are roughly as follows: In fop.fo.flow.TableBody - add a protected TableRow member variable, and - override fop.fo.FObj.addChild to assign the caught row event to it, instead of creating an FObj child for every encountered row and adding it to its children ArrayList (=default FObj behaviour). If a child to be added to the TableBody is a TableCell and the first child, insert one TableRow anyway --will come in handy further downstream. Also in fop.fo.flow.TableBody, introduce a variable to hold the current cell being added. In fop.fo.flow.TableRow, override fop.fo.FObj.addChild, and make it : - add the child to its parent TableBody when it starts a row, or - assign the child as next cell to the TableBody's currentCell The idea being that the cells are added to the TableBody as chains. Only the row-starting cells are direct children of the TableBody. The others are referenced by a nextCellInRow variable in the previous cell (--dunno for sure about this :/ ) What it comes down to, is trading this structure TableBody TableRow (-columns: ArrayList of TableColumns) TableCell TableCell ... TableRow (-columns: ArrayList of TableColumns) TableCell TableCell ... for TableBody TableRow (-columns: ArrayList of TableColumns) TableCell (-nextCellInRow: TableCell (-nextCellInRow: null)) TableCell (-nextCellInRow: TableCell (-nextCellInRow: null)) 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...) In case the Table didn't have any columns specified, this is where they can be added/derived. If the TableRow's columns ArrayList is set to reference the one from the parent Table in the TableRow's constructor or init(), we could test in addChild() whether it is null: in this case create the columns and add them to the TableRow's column List as the TableCells are added. In the TableRow.end() method, set the columns List for the parent Table if it is still null. For each subsequent TableRow being processed, the columns List will be readily available from the parent Table. (IOW: this facilitates implementing the 'columns-are-determined-by-cells-in-the-first-row' part) ? My question here is whether this can be done in TableRow.addChild() by a simple: TableColumn col = new TableColumn( (FONode)getParentTable() ); /* set width from current cell if known, else defer this setting /* until the List is passed back to the Table, and use a /* formula like: Table.OptIPD / ColumnCount, possibly /* refined to include widths of other Columns that *were* /* explicitly set /* DON'T add the column to the Table just yet ... */ columns.add( col ); then later on in TableRow.end(), something like: getParentTable().setColumns( columns ); ? 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) 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)
ANN: FOray
Dear FOP Developers: 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/ 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 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. Victor Mote
Re: [Bug 29025] New: - Document/LayoutStrategy consolidation
On Sun, May 16, 2004 at 07:10:50PM -, [EMAIL PROTECTED] wrote: Team, The following patch incorporates the (rather simple) LayoutStrategy code into the apps.Document class, and does away with LayoutStrategy and LayoutManagerLS.java. Implementation of multiple layout strategies, should we ever be doing this, is still possible, and with roughly the same complexity, however by reimplementing and/or subclassing apps.Document instead. This simplifies the LayoutManager code and makes the tracing of Document creation a bit easier to follow, hopefully beneficial for other developers besides me. The motivation for this change is that currently I'm trying to implement space-before correctly in fo:static-content (as a digression, doesn't work on pages past the first, because I reset its value to zero for fo:flow, need to find a way to differentiate the layout between the two types) and some reduction of the number of dimensions of the source code makes it easier for me to understand the process. If I understand this correctly, this patch removes one user-configurable layer between Document and the LayoutManagers, viz. the LayoutStrategy. This means that AddLMVisitor becomes a direct child of Document instead of LayoutStrategy. I am not an opponent to such user-configurable layers. It allows users to combine parts of the application according to their own needs. OTOH, we are far from a situation where this would be useful, and the perspective of a user implementing another LayoutManagement is extremely unrealistic. I am therefore neither against nor in favour of the change; either way is OK with me. I have always felt that AddLMVisitor is another user-configurable layer between Document and LMs. That was a bit weird, and the proposed situation is more normal. 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. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
RE: Table processing question - follow-up
BTW, Andreas, sorry for not responding to your emails on this thread, I'm juggling a bit much right now, both FOP and non-FOP--thankfully Chris at least has been able to comment on your work, and hopefully I and/or a few others will be able to add something later. Thanks for helping us out with the tables. Glen --- Andreas L. Delmelle [EMAIL PROTECTED] wrote:
RE: Table processing question - follow-up
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] BTW, Andreas, sorry for not responding to your emails on this thread, I'm juggling a bit much right now, Well, don't worry about that... Just posting this all to see if it's just in my head, or all crazy talk --and if not the latter, maybe it will give someone else some ideas, or make them see the light, so to speak. If it is crazy, and I'm not interpreting the process correctly, at least someone will feel compelled to correct me ... in time (--we all hope :) ) Greetz, Andreas
Re: ANN: FOray
N.B. CC'd to [EMAIL PROTECTED] follow-up to fop-dev Victor Mote wrote: Dear FOP Developers: 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/ 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 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. Without speculating at all about the reasons for Victor's decision, I can tell you that I have considered moving alt-design to SourceForge. The reasons are two-fold. Firstly, and most importantly, there is the remote possibility of garnering some financial support for alt-design's development. For those of you who may not yet know, SourceForge has implemented a means for donating to projects or specific developers. The attractions of this idea I need not comment on further. My second reason was to clear the FOP waters by physically separating alt-design from HEAD development. My approach to testing alt-design's layout is to use Java facilities as much as possible. This will cause even further divergence from HEAD, at least initially. Moving to SourceForge will clarify the development lines of FOP HEAD for those who are considering involvement in the project. Such a move would, obviously, have little or no impact on the main 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. Many Apache projects seem to me to be wide open to this kind of de-stabilisation. Those projects with a large contingent of paid developers will not be affected; those with few of no paid developers (e.g. FOP) will be. I think the Board might better serve Apache by addressing this issue rather than some others on its current agenda. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: ANN: FOray
Peter B. West wrote: Such a move would, obviously, have little or no impact on the main 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. How, if FOray will closely parallel the HEAD development could it possibly ha[ve] a great potential to de-stabilise FOP. If A = B, there could be no reason to switch from A to B. There seems to be implicit in your comment a nascent fear that maybe FOP really would benefit from being modularized. The initial, relatively small, fork will be from the maintenance branch. While it is being modularized, I will keep it in sync with my local copy of the FOP maintenance branch code, and hopefully submit a patch to that branch for your consideration. It is my hope that the benefits of this approach will be compelling enough that someone will want to roll it into HEAD as well, but that is your call, not mine. Depending on the success of this approach and its reception, I'll decide whether forking other pieces is needed (there are more extensive comments about this on the FOray home page.) Some of those forks may well be started with code from HEAD. WRT FOray's effect on FOP's stability, I don't see a need for any concern: 1. FOray's work is available to FOP (Apache 2 License), and I hope that FOP (among others) will use it. 2. Most importantly, if I thought that there were FOP developers who shared my zeal for modularizing FOP, I would a) not have left the project, and b) would even now be trying to reenter FOP to do the work there. The very brief review I took of the archives last week led me to believe that instead, the baby steps I had taken toward my goals are being dismantled. (I'm not offended, but merely reminded that I'm out of sync with you all.) Now, it is possible that there are some developers not currently involved with FOP that will be attracted to FOray. If there are compelling advantages to FOray's approach, then that is as it should be. Further, if there are people who see, for example, a benefit in having a freely-distributable alternative to JAI, who want it for a totally non-FOP related purpose, and who contribute to FOray, this seems like a net benefit to FOP. A similar situation would exist for someone who wants to build an FOTree for a voice-related application, use a well-crafted library of PDF-building routines, or write a layout engine that was optimized for some particular axis. There is no explicit intention to reconcile HEAD and maint. However, there are several sets of circumstances that could have that outcome as a byproduct. The biggest unknowns are the timing of LayoutManager's completion, and the speed of progress in FOray. WRT to the opportunity for funding, that had no part in my decision to use sourceforge. (I did opt-in to accept contributions -- why not?). And I doubt that serious funding will materialize through this channel. I would vastly have preferred to do this within FOP for many reasons. My second best choice was to find some other home on Apache for the independent modules, but I frankly don't have time to jump through all of their hoops. The great benefit to using sourceforge was the easy access. I can still get and receive the benefits of an open-source approach and let you guys stay on track with your work. Victor Mote
