Re: Error:java.lang.IllegalStateException: Cannot find any provider supporting RC4
http://xmlgraphics.apache.org/fop/0.94/pdfencryption.html Regards, *Roland* [EMAIL PROTECTED] wrote: Hi, We are using Pdf encryption of FOP 0.20 and we are getting following error. Please guide us on the same java.lang.IllegalStateException: Cannot find any provider supporting RC4 at org.apache.fop.pdf.PDFEncryption.(PDFEncryption.java:164) at org.apache.fop.pdf.PDFDocument.setEncryption(PDFDocument.java:258) at org.apache.fop.render.pdf.PDFRenderer.setOptions(PDFRenderer.java:215) at rhReport.rhPDFConverter.convertXML2PDF(Unknown Source) at rhReport.GHRT.generatePDF(Unknown Source) at rhReport.GHRT.getReportInfo(Unknown Source) at jsp_servlet._rhrel.__rhjniscreen._jspService(__rhjniscreen.java:1652) at weblogic.servlet.jsp.JspBase.service(JspBase.java:33) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348) at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:322) at rhReport.rhControlServ.service(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6981) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3892) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2766) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183) | Thanks & Regards | Ismail Khan | Polaris Software Lab Limited | 91-22-39815900 Extn: 2258 This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit us at http://www.polaris.co.in - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is solely for the use of the intended recipient and may contain information which is confidential or privileged. Any unauthorised use of its contents is prohibited. If you have received this e-mail in error, please notify the sender via return e-mail and then delete the original e-mail. This e-mail is solely for the use of the intended recipient and may contain information which is confidential or privileged. Any unauthorised use of its contents is prohibited. If you have received this e-mail in error, please notify the sender via return e-mail and then delete the original e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Error:java.lang.IllegalStateException: Cannot find any provider supporting RC4
Hi, We are using Pdf encryption of FOP 0.20 and we are getting following error. Please guide us on the same java.lang.IllegalStateException: Cannot find any provider supporting RC4 at org.apache.fop.pdf.PDFEncryption.(PDFEncryption.java:164) at org.apache.fop.pdf.PDFDocument.setEncryption(PDFDocument.java:258) at org.apache.fop.render.pdf.PDFRenderer.setOptions(PDFRenderer.java:215) at rhReport.rhPDFConverter.convertXML2PDF(Unknown Source) at rhReport.GHRT.generatePDF(Unknown Source) at rhReport.GHRT.getReportInfo(Unknown Source) at jsp_servlet._rhrel.__rhjniscreen._jspService(__rhjniscreen.java:1652) at weblogic.servlet.jsp.JspBase.service(JspBase.java:33) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348) at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:322) at rhReport.rhControlServ.service(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6981) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3892) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2766) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183) | Thanks & Regards | Ismail Khan | Polaris Software Lab Limited | 91-22-39815900 Extn: 2258 This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit us at http://www.polaris.co.in - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Major issue with image loading in FOP 0.95beta
Andreas Delmelle a écrit : For now, you also spoke about the requests "suffocating" the server. Do you mean that there are also a lot /more/ requests, or only that they take longer to process on the FOP-side? If you also have an increase in the total number of requests, this could mean that the image-loading framework (unnecessarily?) tries to access the same images multiple times, which may already provide a pointer as to where to start looking in the code. No, but the behaviour looks very different in the server traces. FOP 0.94: a sequence of : one request / one response / one request / one response etc. with constant (server) response time seen in the server logs. Same application with FOP 0.95beta: seems to launch a whole bunch of requests at the same time, say 5..10.15.. requests for different images seen at the same time in the logs. And more a few seconds later. Now the way we interpret the SVN server logs is that the corresponding responses are consumed slower and slower and the SVN server response time traced in the logs is growing in a linear way until it reaches the server timeout (300 s = 5 min. was the default). Then the SVN server supposes nobody's listening to an answer and somehow closes the connection. And then FOP on the other side crashes immediately. Looks somehow like someone very hungry ordering 10 plates at the same time in a restaurant and eating slowly. Until the waiter gives up. (If you forgive me the comparison.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page bottom padding
Vincent Hennebert escreveu: Hi, kindaian a écrit : Some time ago I had a similar requirement. May happen it is the same. I have blocks in the format This is what I was getting: top of page | X -block one | X -block two | X - block three | | bottom of page This is what I wanted it to happen: top of page |X -block one | |X -block two | |X -block three bottom of the page I think what I'm looking can be called "vertical-justify". And is something very useful to make layouts like yellow pages and the like (lots of small blocks of text, spread on several columns in the page, justified to the top and bottom of the page). There’s no need for a vertical-justify setting to achieve this. You can just specify elastic spaces between the blocks: block one etc. FOP will use the amount of stretchable whitespace that’s avaialable to “justify” the content on the page. But I think that Vangelis’ requirement was to make visible the amount of whitespace left at the bottom of a column by the layout algorithm, when no elastic space is available. In which case I’m afraid I can’t think of any FO construction to achieve that. But maybe you will find the above hint useful, after all. There is a simple trick... |--| |||| || block 1 || |||| |||| || block 2 || |||| |||| || block 3 || |||| | | | unused space| |--| Just add a colored background in the table column. And add the "indented-normal" colour in background of each block. Some actual tests may be needed to check if this trick would do the expected result. The result will be that the unused space will appear coloured. Is this what you need Vangelis? Cheers ;) p.s.- this could be used to pre-render and ascertain block dimensions in a pdf engine, naturally, different output targets would generate different results (I've to think about this, because this gives me some interesting ideas). p.s.- and thank you for the tip on the "elastic" spacing... Jeremias Maerki escreveu: Not sure I understand you correctly. There are various way to generate "padding" at the page bottom: - margin-bottom on fo:simple-page-master - margin-bottom on fo:region-body - Enclose all your content in an fo:block and specify: padding-after="2cm" padding-after.conditionality="retain" Depends on what effect you need exactly. HTH On 02.05.2008 21:39:24 Vangelis Karageorgos wrote: Hi everybody, there's a question we've been confronted with during our development process using FOP. Is page bottom padding possible to materialize in FOP, while constructing a layout with several columns and flow from one onto another? Thanks in advance, HTH, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page bottom padding
Vangelis Karageorgos wrote: Is page bottom padding possible to materialize in FOP, while constructing a layout with several columns and flow from one onto another? Another wild guess: If you mean you want to have the columns balanced, add an empty column spanning block after the content (using span="all"). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page bottom padding
On May 5, 2008, at 20:06, Vincent Hennebert wrote: kindaian a écrit : This is what I wanted it to happen: top of page |X -block one | |X -block two | |X -block three bottom of the page I think what I'm looking can be called "vertical-justify". And is something very useful to make layouts like yellow pages and the like (lots of small blocks of text, spread on several columns in the page, justified to the top and bottom of the page). There’s no need for a vertical-justify setting to achieve this. You can just specify elastic spaces between the blocks: block one etc. FOP will use the amount of stretchable whitespace that’s avaialable to “justify” the content on the page. FWIW: What I think XSL-FO currently does not have, is a way to tell the formatter to distribute the lines evenly over an area. Take line1 line2 line3 If you use display-align on an ancestor table-cell or block- container, that would only specify something about a constraint on the placement of the block as a whole. Something like display-align="justify" does not exist. I do see references in the code towards the beginning of an implementation, though. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page bottom padding
Hi, kindaian a écrit : > Some time ago I had a similar requirement. May happen it is the same. I > have blocks in the format > > This is what I was getting: > top of page > | X -block one > | X -block two > | X - block three > | > | > bottom of page > > This is what I wanted it to happen: > top of page > |X -block one > | > |X -block two > | > |X -block three > bottom of the page > > I think what I'm looking can be called "vertical-justify". And is > something very useful to make layouts like yellow pages and the like > (lots of small blocks of text, spread on several columns in the page, > justified to the top and bottom of the page). There’s no need for a vertical-justify setting to achieve this. You can just specify elastic spaces between the blocks: block one etc. FOP will use the amount of stretchable whitespace that’s avaialable to “justify” the content on the page. But I think that Vangelis’ requirement was to make visible the amount of whitespace left at the bottom of a column by the layout algorithm, when no elastic space is available. In which case I’m afraid I can’t think of any FO construction to achieve that. But maybe you will find the above hint useful, after all. > Jeremias Maerki escreveu: >> Not sure I understand you correctly. There are various way to generate >> "padding" at the page bottom: >> >> - margin-bottom on fo:simple-page-master >> - margin-bottom on fo:region-body >> - Enclose all your content in an fo:block and specify: >>padding-after="2cm" padding-after.conditionality="retain" >> >> Depends on what effect you need exactly. >> >> HTH >> >> On 02.05.2008 21:39:24 Vangelis Karageorgos wrote: >> >>> Hi everybody, >>> >>> there's a question we've been confronted with during our development >>> process >>> using FOP. >>> Is page bottom padding possible to materialize in FOP, while >>> constructing a >>> layout with several columns and flow from one onto another? >>> >>> Thanks in advance, HTH, Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tables and keeps with 0.95beta
Hi Philipp, Philipp Wagner a écrit : > Hi, > > I tried FOP 0.95beta together with a table with > keep-together.within-page="always" and keep-with-previous="always" > attributes, which didn't work in 0.94 at all. While the page breaks are > almost correct now, there is a problem with the table headers. I > uploaded a sample document at > http://philipp-wagner.com/temp/20080504-fop/document.fo > and the PDF output at > http://philipp-wagner.com/temp/20080504-fop/document.pdf > > If you look on page two you'll see a horizontal line between the first > and the second row, which shouldn't be there. This is a bug that I’ve just fixed in the head of the 0.95 branch (for interested parties: http://svn.apache.org/viewvc?view=rev&revision=653537). Thanks for the testcase! > Apart from that, the keep-with-previous="always" attribute doesn't work, > as you can see on the top of the second page, too. The first row on the > second page has a keep-with-previous attribute, which should keep it > together with the row before, which is not the case here. The empty fo:block in the column-spanning cell indeed creates troubles; the keep-with-previous technically works (this empty block is to be found on the first page) but visually speaking the result is unexpected. It’s difficult to fix this since you can find blocks with visible contents whose heights are artificially set to zero, in order to achieve whatever rendering trick. Jeremias provided the answer to this; if you can also remove this empty fo:block, all the better. > Are this known limitations of FOP or just a small bug? Or are there any > workarounds? > > Philipp Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Major issue with image loading in FOP 0.95beta
On May 5, 2008, at 18:09, Jean-François El Fouly wrote: Two questions, for the moment: Which image format(s) are you using? PNG only (but lots of them). OK, we recently bumped into Mac OS not having a native TIFF codec. With a bit of fiddling, one could make the Sun default pure Java implementation available as a fallback, but that ran about 30 times slower than FOP's own TIFF loader from 0.94. Maybe a similar thing is happening with PNG, I don't know. I really hope Jeremias chimes in later... For now, you also spoke about the requests "suffocating" the server. Do you mean that there are also a lot /more/ requests, or only that they take longer to process on the FOP-side? If you also have an increase in the total number of requests, this could mean that the image-loading framework (unnecessarily?) tries to access the same images multiple times, which may already provide a pointer as to where to start looking in the code. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Major issue with image loading in FOP 0.95beta
Andreas Delmelle a écrit : On May 5, 2008, at 17:22, Jean-François El Fouly wrote: Hi Sorry, I guess in the strictest sense this is xmlgraphics-common related now, but it was discovered and investigated using FOP 0.95beta. We upgraded from 0.94 to use the new bookmarks features and our software became globally unstable, hanging randomly during PDF generation -- to be precise, getting all kinds of random problems during image loading. The images we use are stored in SVN and retrieved via their HTTP URLs from an SVN server. Reading the SVN logs, we see a very different behaviour between 0.94 (which worked fine and has been retested since) and 0.95beta: the FOP requests litteraly "suffocate" the SVN server, sending quite a lot of requests for images and taking way too long to consume the responses. So, after a (random) while, the SVN server gives up (timeout) and the FOP application on the other side crashes immediately after. At least that is how we understand the problem after testing and reading all sorts of server logs (with a sysadmin) for a whole day. This looks like a major regression and makes 0.95beta completely unusable for us -- though we badly need the new features :-( If anybody had an idea, I must say I'd be extremely grateful... Two questions, for the moment: Which image format(s) are you using? PNG only (but lots of them). Does the JAI/ImageIO implementation on the box where FOP runs, have a native codec to read that format? Will ask / investigate (it's a production server to which I don't have direct access). Debian 4.0 on JDK 1.5.0_11 and JBoss 4.2.1.GA. Thanks ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Major issue with image loading in FOP 0.95beta
On May 5, 2008, at 17:22, Jean-François El Fouly wrote: Hi Sorry, I guess in the strictest sense this is xmlgraphics-common related now, but it was discovered and investigated using FOP 0.95beta. We upgraded from 0.94 to use the new bookmarks features and our software became globally unstable, hanging randomly during PDF generation -- to be precise, getting all kinds of random problems during image loading. The images we use are stored in SVN and retrieved via their HTTP URLs from an SVN server. Reading the SVN logs, we see a very different behaviour between 0.94 (which worked fine and has been retested since) and 0.95beta: the FOP requests litteraly "suffocate" the SVN server, sending quite a lot of requests for images and taking way too long to consume the responses. So, after a (random) while, the SVN server gives up (timeout) and the FOP application on the other side crashes immediately after. At least that is how we understand the problem after testing and reading all sorts of server logs (with a sysadmin) for a whole day. This looks like a major regression and makes 0.95beta completely unusable for us -- though we badly need the new features :-( If anybody had an idea, I must say I'd be extremely grateful... Two questions, for the moment: Which image format(s) are you using? Does the JAI/ImageIO implementation on the box where FOP runs, have a native codec to read that format? If one of the formats is TIFF, and the answer to the second question is No, then a possible solution may be to try out a more recent version of the xmlgraphics-commons jar. Jeremias has recently re-activated the old FOP TIFF-loader to avoid the fallback to Sun's default pure Java implementation, which is significantly slower. Other than that, I wouldn't have a clue, unfortunately. HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Major issue with image loading in FOP 0.95beta
Sorry, I guess in the strictest sense this is xmlgraphics-common related now, but it was discovered and investigated using FOP 0.95beta. We upgraded from 0.94 to use the new bookmarks features and our software became globally unstable, hanging randomly during PDF generation -- to be precise, getting all kinds of random problems during image loading. The images we use are stored in SVN and retrieved via their HTTP URLs from an SVN server. Reading the SVN logs, we see a very different behaviour between 0.94 (which worked fine and has been retested since) and 0.95beta: the FOP requests litteraly "suffocate" the SVN server, sending quite a lot of requests for images and taking way too long to consume the responses. So, after a (random) while, the SVN server gives up (timeout) and the FOP application on the other side crashes immediately after. At least that is how we understand the problem after testing and reading all sorts of server logs (with a sysadmin) for a whole day. This looks like a major regression and makes 0.95beta completely unusable for us -- though we badly need the new features :-( If anybody had an idea, I must say I'd be extremely grateful... Jean-Francois El Fouly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tables and keeps with 0.95beta
Jeremias Maerki schrieb: Actually, no, it's not a bug. ;-) I just forgot that keep-together doesn't apply to table-cell, so the keep value is only propagated to its children. But the keep is not in effect between the two blocks of the table-cell. Hrhr, that solves everything :-) Thank you so much! The bad thing is that I even used the XSL validation stylesheet (http://www.renderx.com/tools/validators.html), but it gave me no hints whatsoever, probably because it is valid, but not what I expected :) Again, thank you very much and keep up the great work! Philipp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RTF generation and total page count
Hello, I am using fop to generate RTFs. I have managed to get around most of the limitations. But know I need some help. I need to print out the total page count, like "page 4 of 9". The current page number (in my example the 4) is no problem. But I can't find a way to generate the total page count. I've tried to reference an element on the last page without success. I've also tried the two-pass-way, mentioned in the faqs. Sadly the RTF renderer is not capable of telling me how many pages it has generated. In Word I can input the page count. Does RTFlib support this control-command (and therefore enable me to implement this functionality)? I am out of ideas and would greatly appreciate any help! Thank you M. Grauel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
using ttf-fonts embedded
Hello,
I configured my fop factory with the following line:
fopFactory.setFontBaseURL("file:///D:/Windows/Fonts");
But fop still uses the font 'any' instead. At the position mentioned above are
ttf files, which fit to the ones I use.
Andreas
_
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten!
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page bottom padding
Some time ago I had a similar requirement. May happen it is the same. I have blocks in the format This is what I was getting: top of page | X -block one | X -block two | X - block three | | bottom of page This is what I wanted it to happen: top of page |X -block one | |X -block two | |X -block three bottom of the page I think what I'm looking can be called "vertical-justify". And is something very useful to make layouts like yellow pages and the like (lots of small blocks of text, spread on several columns in the page, justified to the top and bottom of the page). I think that at the time, a management of the paddings and padding conditions would manage the wanted effect. [there was another issue regarding space management but that isn't the issue here hehehe] Cheers, Kindaian Jeremias Maerki escreveu: Not sure I understand you correctly. There are various way to generate "padding" at the page bottom: - margin-bottom on fo:simple-page-master - margin-bottom on fo:region-body - Enclose all your content in an fo:block and specify: padding-after="2cm" padding-after.conditionality="retain" Depends on what effect you need exactly. HTH On 02.05.2008 21:39:24 Vangelis Karageorgos wrote: Hi everybody, there's a question we've been confronted with during our development process using FOP. Is page bottom padding possible to materialize in FOP, while constructing a layout with several columns and flow from one onto another? Thanks in advance, Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tables and keeps with 0.95beta
Actually, no, it's not a bug. ;-) I just forgot that keep-together doesn't apply to table-cell, so the keep value is only propagated to its children. But the keep is not in effect between the two blocks of the table-cell. This is how it looks in document.fo (reduced to the important stuff): xx xx.xx x xx.xx xxx xx x xxx xxx xxx xxx x x x xxx xxx xxx xx xxx xxx xxx xxx This is the same as if you specified: xx xx.xx x xx.xx xxx xx x xxx xxx xxx xxx x x x xxx xxx xxx xx xxx xxx xxx xxx So, the keep-with-previous on the table-row only keeps the first block of the cell together with the last area produced by the previous table-row. The FO implementation is free to break between the first and second block in the cell. So to keep everything together, put the keep-together on the table-row (as I've mentioned in the other post). Or enclose the two blocks in yet another block. In that case the table-cell's keep-together has an effect on the enclosing block and effectively keeps the two original blocks together. Together with the keep-with-previous on the row, everything work as expected then. On 05.05.2008 09:49:21 Jeremias Maerki wrote: > I think this is a bug. I'll look into it. In the meantime, you can work > around the problem by moving the keep-together on the table-cell to the > table-row. > > On 05.05.2008 00:14:28 Philipp Wagner wrote: > > Hi, > > > > I tried FOP 0.95beta together with a table with > > keep-together.within-page="always" and keep-with-previous="always" > > attributes, which didn't work in 0.94 at all. While the page breaks are > > almost correct now, there is a problem with the table headers. I > > uploaded a sample document at > > http://philipp-wagner.com/temp/20080504-fop/document.fo > > and the PDF output at > > http://philipp-wagner.com/temp/20080504-fop/document.pdf > > > > If you look on page two you'll see a horizontal line between the first > > and the second row, which shouldn't be there. > > > > Apart from that, the keep-with-previous="always" attribute doesn't work, > > as you can see on the top of the second page, too. The first row on the > > second page has a keep-with-previous attribute, which should keep it > > together with the row before, which is not the case here. > > > > Are this known limitations of FOP or just a small bug? Or are there any > > workarounds? > > > > Philipp > > > > Jeremias Maerki > Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tables and keeps with 0.95beta
On 05.05.2008 09:56:27 Andreas Delmelle wrote: > On May 5, 2008, at 09:49, Jeremias Maerki wrote: > > I think this is a bug. I'll look into it. In the meantime, you can > > work > > around the problem by moving the keep-together on the table-cell to > > the > > table-row. > > Before you dive in: maybe Vincent can confirm that this is also > related to bug 44621 (*), and so may already be fixed in the current > head of the 0.95 branch. It's definitely not 44621. It has to do with our special rule that the first row step has to include contributions from all table-cells which is somehow not respected properly in this case. > If I run the sample FO through FOP trunk, and enable assertions, I > get an AssertionError in > TableStepper.getCombinedKnuthElementsForRowGroup() (all the way at > the end). > > https://issues.apache.org/bugzilla/show_bug.cgi?id=44621 > > Cheers > > Andreas Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tables and keeps with 0.95beta
On May 5, 2008, at 09:49, Jeremias Maerki wrote: I think this is a bug. I'll look into it. In the meantime, you can work around the problem by moving the keep-together on the table-cell to the table-row. Before you dive in: maybe Vincent can confirm that this is also related to bug 44621 (*), and so may already be fixed in the current head of the 0.95 branch. If I run the sample FO through FOP trunk, and enable assertions, I get an AssertionError in TableStepper.getCombinedKnuthElementsForRowGroup() (all the way at the end). https://issues.apache.org/bugzilla/show_bug.cgi?id=44621 Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tables and keeps with 0.95beta
I think this is a bug. I'll look into it. In the meantime, you can work around the problem by moving the keep-together on the table-cell to the table-row. On 05.05.2008 00:14:28 Philipp Wagner wrote: > Hi, > > I tried FOP 0.95beta together with a table with > keep-together.within-page="always" and keep-with-previous="always" > attributes, which didn't work in 0.94 at all. While the page breaks are > almost correct now, there is a problem with the table headers. I > uploaded a sample document at > http://philipp-wagner.com/temp/20080504-fop/document.fo > and the PDF output at > http://philipp-wagner.com/temp/20080504-fop/document.pdf > > If you look on page two you'll see a horizontal line between the first > and the second row, which shouldn't be there. > > Apart from that, the keep-with-previous="always" attribute doesn't work, > as you can see on the top of the second page, too. The first row on the > second page has a keep-with-previous attribute, which should keep it > together with the row before, which is not the case here. > > Are this known limitations of FOP or just a small bug? Or are there any > workarounds? > > Philipp Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page bottom padding
Not sure I understand you correctly. There are various way to generate "padding" at the page bottom: - margin-bottom on fo:simple-page-master - margin-bottom on fo:region-body - Enclose all your content in an fo:block and specify: padding-after="2cm" padding-after.conditionality="retain" Depends on what effect you need exactly. HTH On 02.05.2008 21:39:24 Vangelis Karageorgos wrote: > Hi everybody, > > there's a question we've been confronted with during our development process > using FOP. > Is page bottom padding possible to materialize in FOP, while constructing a > layout with several columns and flow from one onto another? > > Thanks in advance, Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
