Re: Element list generation for tables (special case)
On 27.07.2005 23:26:48 Andreas L Delmelle wrote: On Jul 27, 2005, at 20:45, Jeremias Maerki wrote: Hi, I got a test case for tables which raises not a technical but rather a interesting conceptual question. Please have a look at the attached test case. It defines a table with two columns and two rows. In the given setup the second row creates an break decision with the current code that can be argued as being bad (see the PDF). Indeed, doesn't look right. Given the value for the orphans property, one still would reasonably expect the break to occur before the first cell of the second row. ...or after the first 3 lines of the second row. BTW: tried adding a third column mirroring the first, and this leads to ONLY the second column being moved to the next page... This as a further demonstration that the currently produced result still leaves a bit to be desired. (see attach) That was to be expected because the element list from the first and third column will likely be that same and therefore won't produce a different combined element list. Here's an excerpt from the element list: 8) box w=9600 9) penalty p=0 w=0 10) box w=28800 11) penalty p=0 w=0 12) box w=0 //-- this is where the second row starts 13) penalty p=0 w=9600 //this penalty is due to the possible break after B 14) box w=28800 15) penalty p=0 w=0 //this is the next break poss after three lines //due to the orphan setting 16) box w=28800 While working on element list generation for tables I came across this question and decided not to do anything about it, especially since removing some of these break possibilities might not be desirable in all cases. A rule that could be easily implemented would be that we allow the first break possibility only after every cell in a new row contributed at least one of its own boxes to the combined element list. So IOW, if I get this correctly: all break possibilities are to be considered preliminary until the last cell occupying this row (= last grid-unit in the row) has been taken into account? Almost. In different words again: this means the first step is only after each newly started cell in a new row contributes at least one box to the combined element list. I wouldn't want to work with something like a preliminary break possibility as it suggests that you somehow have to revisit the list. I'd rather improve the getNextStep method to only return for the first time after the above rule is met. An example: If you look at page 1 of [1], step 1 would over ignored. On page 3 of [1], the steps 1 and 2 would be ignored. [1] http://people.apache.org/~jeremias/fop/ KnuthBoxesForTablesWithBorders.pdf Hmm... Do you mean that the steps would be performed but their results discarded, or that the steps simply would not be performed at all? Not performed at all. See above. I'd think the first, but just want to make sure... Are the break possibilities currently considered only at the level of the table body --so the element list contains the elements for the cells' boxes, but no separate elements/indicators of row-boundaries? We seem to have a different word set for expressing this. I don't think we can say that the breaks are considered at table body level. And you have to be careful about with element list you speak: the individual cell element lists or the effective combined element list. Let me explain how this is implemented: The TableRowIterator simply provides effective rows with grid units. For TableContentLM it chooses an array of effective rows which forms a row group so that no column-spanned cell is split between groups. See the Wiki for details. Such a row group is the minimal work item for combining element lists. There is always a break possibility before and after a row group (except if there is a keep constraint on a row, for example). Inside a row group the break possibilities are determined by the getNextStep() method where the combined element list is created. In that case --with the risk of underestimating the complexity of what I propose--, perhaps an alternative to the suggested rule would be to insert a step that combines the generated boxes/penalties only after the element list for the last grid unit in a logical row has been created (?) Anyway, instead of simply ignoring those steps, we could also increase the penalty value for the offending break possibility (currently: p=0 for all of them) So, IOW, for each row, store the element lists, and after all lists are available, review the calculated penalty values, increasing them when a given break possibility has undesirable consequences when the other element lists for the row are taken into account. Or the other way around: give them a default penalty value that is high enough, then afterwards decreasing them for the most
Re: Element list generation for tables (special case)
On Jul 28, 2005, at 10:10, Jeremias Maerki wrote: On 27.07.2005 23:26:48 Andreas L Delmelle wrote: Indeed, doesn't look right. Given the value for the orphans property, one still would reasonably expect the break to occur before the first cell of the second row. ...or after the first 3 lines of the second row. Yes, but IIC, there isn't enough space left on the page to display those, hence 'break before the row'. snip / These are all valid possibilities, but as a I hinted I want to discuss this at conceptual level not implementation level. I want to know if we can have a general rule that we don't allow breaks before every cell contributed at least one box to the combined element list. Also, Simon and you are talking about providing higher penalty values, but I asked about allowing a break at all (i.e. INFINITE penalty, or rather no penalty at all, only a box). Considering a penalty value pINFINITE requires a decision that such breaks are possible/desirable in the first place. Well, if it is only the conceptual side that matters ATM, I don't see any immediate problem with such a rule. snip / Right, but is that rule ok or not from a conceptual view. Are there any cases where it might be bad? Definitely OK for me. I can't seem to imagine a situation where this rule might cause undesirable effects. On the contrary, it reminds me of a question Luca raised some time ago when implementing lists, roughly : Is it desirable that, due to a page-break, label and body end up on different pages? I didn't think it was, and I don't think this should happen in case of tables either. The different columns in a row should always be considered together, not one-by-one. So the first column can never be allowed to end up in its entirety on a different page than the second. Where it comes to rowspans: In my modified example, if you move all the text in the middle column to the first row and make that cell span two rows, things get a bit awkward without the proposed rule anyway. (see attached PDF: the middle cell doesn't span the two rows, and the 'second' row only has two cells, and they're considered to be the first and second cell --while they should actually be the first and third) table-body4c.xml.head.pdf Description: Adobe PDF document table-body4c.xml Description: application/text Greetz, AD PGP.sig Description: This is a digitally signed message part
Re: Element list generation for tables (special case)
On 28.07.2005 13:42:08 Andreas L Delmelle wrote: On Jul 28, 2005, at 10:10, Jeremias Maerki wrote: On 27.07.2005 23:26:48 Andreas L Delmelle wrote: Indeed, doesn't look right. Given the value for the orphans property, one still would reasonably expect the break to occur before the first cell of the second row. ...or after the first 3 lines of the second row. Yes, but IIC, there isn't enough space left on the page to display those, hence 'break before the row'. Right. I just wanted to point out all the relevant break possibilities. snip / These are all valid possibilities, but as a I hinted I want to discuss this at conceptual level not implementation level. I want to know if we can have a general rule that we don't allow breaks before every cell contributed at least one box to the combined element list. Also, Simon and you are talking about providing higher penalty values, but I asked about allowing a break at all (i.e. INFINITE penalty, or rather no penalty at all, only a box). Considering a penalty value pINFINITE requires a decision that such breaks are possible/desirable in the first place. Well, if it is only the conceptual side that matters ATM, I don't see any immediate problem with such a rule. Ok. snip / Right, but is that rule ok or not from a conceptual view. Are there any cases where it might be bad? Definitely OK for me. I can't seem to imagine a situation where this rule might cause undesirable effects. On the contrary, it reminds me of a question Luca raised some time ago when implementing lists, roughly : Is it desirable that, due to a page-break, label and body end up on different pages? D'oh. I missed that. Definitely the same problem. I didn't think it was, and I don't think this should happen in case of tables either. The different columns in a row should always be considered together, not one-by-one. So the first column can never be allowed to end up in its entirety on a different page than the second. Where it comes to rowspans: In my modified example, if you move all the text in the middle column to the first row and make that cell span two rows, things get a bit awkward without the proposed rule anyway. (see attached PDF: the middle cell doesn't span the two rows, and the 'second' row only has two cells, and they're considered to be the first and second cell --while they should actually be the first and third) Ouch. You definitely hit a bug here. The height calculation rule should have placed the two Bs right under the As (i.e. first row height = 8pt). Jeremias Maerki
Re: fop contribution
Jeremias, thanks for explanations. As commit I meant contribute of course. I'm already aware of the rule that commit rights are awarded by voting. Btw, I contacted JEuclid founder Stephan Michels yesterday. Unfortunately I received no reply at the moment. Will try to contact another project admin. -- Siarhei Baidun On 27.07.2005 15:49:02 Siarhei Baidun wrote: Jeremias, we consider the signing of the CCLA (corporate) , not ICLA (individual). The ICLA is mandatory for each person that intends to submit a contribution to an ASF project. The CCLA is only necessary if you work for a company and you want to make sure everything is 100% waterproof. At the ASF no company can be a contributor. It's always an individual that does the actual contribution. The CCLA is simply there to make certain that you are entitled as an employee of that company to make contributions to the ASF. Could you please advise if ICLAs have to be signed along with CCLA for those employees who would commit to Apache? I don't want to be a nitpicker but at first, you can only submit patches as a contributor. Commit rights have to be earned and are proposed to you by the existing committers. Just to avoid any false expectations. Jeremias Maerki
Re: Element list generation for tables (special case)
I've been following this thread with interest. From a conceptual point of view, I agree with Andreas. I can't see any situation where you might want to have cells of the same row group on separate pages. Regardless of how many rows a particular cell spans. Is there nothing in the spec to give you some clues? snip what=very good discussion/ Chris
DO NOT REPLY [Bug 35918] New: - [PATCH] Shapes are slightly shifted with respect to lines on larger graphics
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=35918. 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=35918 Summary: [PATCH] Shapes are slightly shifted with respect to lines on larger graphics Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: major Priority: P2 Component: pdf renderer AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] Due to insufficient precision of the transformation matrix, shapes are not correctly positioned on larger graphics. As lines are rendered differently this results in ugly, unusable PDF output. The resolution is simple to provide a better precision in the PDF output (see attached patch). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 35918] - [PATCH] Shapes are slightly shifted with respect to lines on larger graphics
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=35918. 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=35918 --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 17:51 --- Created an attachment (id=15816) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15816action=view) patch to write transformation matrix with higher precision -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
