DO NOT REPLY [Bug 38821] The manifest file no longer has a Class-Path entry
https://issues.apache.org/bugzilla/show_bug.cgi?id=38821 --- Comment #13 from Yannick Majoros yannick.majo...@gmail.com 2011-03-21 06:17:25 EDT --- The classpath entry gives a long list of stacktraces in Glassfish 3.1... and I think Glassfish is right. The classpath entry doesn't reflect the dependencies documented at http://www.linuxfromscratch.org/blfs/view/svn/pst/fop.html . It is trying to load things which aren't really required (xml-apis.jar, xerces, ...) and would cause problems here. Glassfish complains that those resources are missing (which is right). I think the best thing to do is to remove the classpath entry (at least everything that isn't required). Yes, running fop.jar should imply passing the correct classpath. You can do that with environment variables or better, batch / shell script files if you want. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Row span and keep-togehther.within-page problem
Hi Matthias, Looks like you pinpointed the problem, well done. I’ve just submitted a fix, please test with your real-life file. http://svn.apache.org/viewvc?rev=1083863view=rev On 19/03/11 21:22, Matthias Reischenbacher wrote: Hi Andreas, thanks a lot for your explanation of how keep conditions are enforced! Today I had been looking at the same code as you and I found it odd that the table keep condition is only taken into account inside TableStepper.getCombinedKnuthElementsForRowGroup() if the rowFinished value is set to false. Do you have any idea what rowFinished means in this context? When debugging the code with my test case the value of rowFinished is always true and therefore the if statement seems to be dead code. This means that the end of a table-row has been reached. That is, all the content of all the cell ending on that row has been handled. If you are talking about the test case you posted on the users list, then you always get true because all your cells are one line, so the end is immediately reached. Try again with cells containing several blocks of text. Do you think it would be a solution to just move out lines 250 and 252 of the if statement and execute it always. Yes indeed, this is what I did. In theory it would be better to handle table keeps in a table-related class (TableLM or TableContentLM), but it is impractical to modify the list of Knuth elements afterwards. Perhaps then the additional keep condition handling inside TableContentLM.getKnuthElementsForRowIterator() could be removed? No, it’s needed to handle keeps between row groups. Loosely speaking a row group is the smallest set of table rows that are spanned by cells. Usually a row group is the same as a row, but it may become more complicated when cells span several rows. For example: __ | | | | | |__|__| | | | | |__|__| | | | | | |__|__|__| Thanks Regards, Matthias Thanks for investigating this. Vincent Andreas Delmelle-2 wrote: On 18 Mar 2011, at 00:30, Matthias Reischenbacher wrote: snip / FWIW: I was just playing with the example, and noticed my suggestion --using keep.within-column-- does not help. This means, as Vincent suspects (IIC), that the culprit is the code that takes care of generating the element list in case of row-spanning cells, which inadvertently generates break-possibilities (i.e. does not take into account the keep that is dominating the ancestor fo:table) Comparing the case with and without row-span in a debug session reveals that, with row-span all BreakElements have penalty value 0, whereas without row-span, we get INFINITE, as expected. Looking deeper, in TableContentLM.getKnuthElementsForRowIterator(), notice that the case with row-span produces only one row-group, so the code that would set the keep constraint from the table --in the while loop, line 250-- never gets executed. The RowGroupLayoutManager gets passed a LayoutContext that is not properly initialized (keep=auto). Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Row span and keep-togehther.within-page problem
On 21 Mar 2011, at 17:50, Vincent Hennebert wrote: Hi Vincent, Matthias, Looks like you pinpointed the problem, well done. I’ve just submitted a fix, please test with your real-life file. http://svn.apache.org/viewvc?rev=1083863view=rev Not sure if Matthias also sees this, but as I pointed out, that change --which I also tried yesterday-- has the side-effect of dragging along the preceding block in Matthias' test case...? Could still be related to some local changes in my sandbox, though. Regards, Andreas ---
Re: Row span and keep-togehther.within-page problem
On 21 Mar 2011, at 18:51, Andreas Delmelle wrote: On 21 Mar 2011, at 17:50, Vincent Hennebert wrote: Hi Vincent, Matthias, Looks like you pinpointed the problem, well done. I’ve just submitted a fix, please test with your real-life file. http://svn.apache.org/viewvc?rev=1083863view=rev Not sure if Matthias also sees this, but as I pointed out, that change --which I also tried yesterday-- has the side-effect of dragging along the preceding block in Matthias' test case...? Could still be related to some local changes in my sandbox, though. Oops, sorry for the noise. Still had changes to TableContentLM that were causing this effect, so the issue should indeed be fixed now. Regards, Andreas ---
Re: Row span and keep-togehther.within-page problem
Hi Vincent, Looks like you pinpointed the problem, well done. I’ve just submitted a fix, please test with your real-life file. http://svn.apache.org/viewvc?rev=1083863view=rev Thanks for committing the fix! On 19/03/11 21:22, Matthias Reischenbacher wrote: Hi Andreas, thanks a lot for your explanation of how keep conditions are enforced! Today I had been looking at the same code as you and I found it odd that the table keep condition is only taken into account inside TableStepper.getCombinedKnuthElementsForRowGroup() if the rowFinished value is set to false. Do you have any idea what rowFinished means in this context? When debugging the code with my test case the value of rowFinished is always true and therefore the if statement seems to be dead code. This means that the end of a table-row has been reached. That is, all the content of all the cell ending on that row has been handled. If you are talking about the test case you posted on the users list, then you always get true because all your cells are one line, so the end is immediately reached. Try again with cells containing several blocks of text. Ah ok, now I understand. Do you think it would be a solution to just move out lines 250 and 252 of the if statement and execute it always. Yes indeed, this is what I did. Why you didn't move out: keep = keep.compare(rowGroup[activeRowIndex].getKeepTogether()); ? If i remove the keep attribute from the table and add it on the table row the keep doesn't work anymore. In theory it would be better to handle table keeps in a table-related class (TableLM or TableContentLM), but it is impractical to modify the list of Knuth elements afterwards. Perhaps then the additional keep condition handling inside TableContentLM.getKnuthElementsForRowIterator() could be removed? No, it’s needed to handle keeps between row groups. Loosely speaking a row group is the smallest set of table rows that are spanned by cells. Usually a row group is the same as a row, but it may become more complicated when cells span several rows. For example: __ | | | | | |__|__| | | | | |__|__| | | | | | |__|__|__| Thanks Regards, Matthias Thanks for investigating this. Vincent Thanks also to Andreas! Matthias -- View this message in context: http://old.nabble.com/Re%3A-Row-span-and-keep-togehther.within-page-problem-tp31193911p31202771.html Sent from the FOP - Dev mailing list archive at Nabble.com.
DO NOT REPLY [Bug 49801] Region-Body Column balancing incorrect if content is table with header
https://issues.apache.org/bugzilla/show_bug.cgi?id=49801 --- Comment #7 from Andreas L. Delmelle adelme...@apache.org 2011-03-21 15:27:29 EDT --- Thinking more about a possible fix, I am suddenly asking myself why we would even fiddle with the demerits at all to balance columns. Playing with the demerits alone is not enough to make a break more/less favorable. Ultimately, the adjustment ratio is a deciding factor too, and that is based on the difference between available width and the width of the line. Since the algorithm works with the full bpd of the page as line-width, this is bound to cause the algorithm to 'ignore' the better demerits at some points. In a way, that feels like we could handle column-balancing better by (also) forcing the available line-width down to the minimal width needed by the content (i.e. taking into account pieces that must be kept together within the same column). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
