Re: Content spanning multiple pages issue
Hi Andreas and Rob, Just to let you know that relaxing the FOP structure by removing the block containers position=absolute and replacing the top/left by space-after/start-indent did the trick and the pages produced by FOP look as expected. Thank you very much for your help and suggestions ! Kind Regards, Fernando On Mon, Aug 1, 2011 at 10:18 AM, Fernando Israel wrote: > Hi Andreas and Rob, > > Thank you very much both for your suggestions. > > The idea of using space-before and start-indent attributes instead of top > and left respectively, and dropping the absolute position looks promising, > I'll try that. In fact there are 2 tables in the document, the main one > which we have discussed so far, and another one I did not mentioned so far > to keep things simple, that always follows the main one and it is > conceptually a summary of it. In the summary table I have actually used > space-before and start-indent and that works fine. So now I think I should > try to translate the top and left values to space-before and start-indent > and thereby relax the whole structure and let it flow more naturally. > > Let me perhaps give you a more detailed picture of what I am trying to > acomplish with FOP. This work is part of an application that deals with > billing out of a system. Part of the application let users design their own > invoice template that we then use, along with the actual data for each > invoice, to produce an invoice PDF document. So the WSIWYG editor let users > drop text, pictures and a table with the items sold which are part of the > invoice. Some of the text and the invoice items table are generated from > live data. So for instance, a typical invoice would include the company logo > (a pic) static text with the company address, dynamic text with the invoice > number, invoice date, client name and address, etc. Generally an invoice is > arranged with all these bits on the top of the page followed by a table with > the items invoiced; the table includes the name of the product, quantity, > price, etc. > > This is why we need to the PDF to reproduce what the users have designed. > In the template editor since we don't know upfront the height of the table > (we know the width and the columns headers) we drop a table with 3 rows as a > sample, but in practice the table's height varied depending on the number of > invoiced items. Underneath the table there is the other table with the > summary with things such as subtotal, VAT, total, etc. We made that summary > table follow the main one using space-before and start-indent. > > This design has the limitation that anything underneath the main table and > the following summary table might get hidden by the content of the tables if > they are too long. Having said that, in most of the cases that will not be > so. We just need to tell users to take this into account during design. Put > it in a different way, the tool does the job and covers most needs but it > does not cover 100% of the cases. > > We did use absolute positioning because it was the easiest thing to do. > However I now see that perhaps that wasn't the best choice and doing all the > positioning with space-before and start-indent will provide a more flexible > tool. For once, it will remove the limitation that anything under the tables > might get hidden by the tables content. It will also span multiple pages if > needed. > > Going forward we also plan to support header/footer, which will allow users > to have a finer control on what should appear in each page when it spans > over a single page. > > One last question. I think that the main issue we are having with the > current design is the constarins along the block propagation direction. So > the first thin we need to do is to relax the structure and replace the top > attribute by the space-before one. We don't have an issue in the inline > direction, so, can I keep using the left attribute there ?. So it will be a > mix of start-before and left attributes. > > Thanks again for you input. It is very much appreciated. > > Regards, > Fernando > > > > On Sun, Jul 31, 2011 at 12:11 AM, Rob Sargent wrote: > >> OP might also be interested in calculating the required offset on the >> second page (end of the table) at which to place (absolutely??) the >> follow-on text. If so follow the (ill-named) thread "breakpoint suggestions >> please". >> >> One is tempted to ask why the WYSIWYG editor doesn't open a second page... >> >> >> >> >> Andreas L. Delmelle wrote: >> >>> On 30 Jul 2011, at 21:13, Fernando Israel wrote: >>> >>> Hi Fernando, >>> >>> >>> So I now have to rephrase the question. Can I have a table within an absolute postioned block container go over to a second page it its length requires so ?. I guess that the answer is no, but I better ask. >>> >>> You guess correct. >>> >>> BTW, it just occurred to me, while re-examining the FO you sent, that the >>> 'position' property does not apply to fo:
Re: Content spanning multiple pages issue
Hi Andreas and Rob, Thank you very much both for your suggestions. The idea of using space-before and start-indent attributes instead of top and left respectively, and dropping the absolute position looks promising, I'll try that. In fact there are 2 tables in the document, the main one which we have discussed so far, and another one I did not mentioned so far to keep things simple, that always follows the main one and it is conceptually a summary of it. In the summary table I have actually used space-before and start-indent and that works fine. So now I think I should try to translate the top and left values to space-before and start-indent and thereby relax the whole structure and let it flow more naturally. Let me perhaps give you a more detailed picture of what I am trying to acomplish with FOP. This work is part of an application that deals with billing out of a system. Part of the application let users design their own invoice template that we then use, along with the actual data for each invoice, to produce an invoice PDF document. So the WSIWYG editor let users drop text, pictures and a table with the items sold which are part of the invoice. Some of the text and the invoice items table are generated from live data. So for instance, a typical invoice would include the company logo (a pic) static text with the company address, dynamic text with the invoice number, invoice date, client name and address, etc. Generally an invoice is arranged with all these bits on the top of the page followed by a table with the items invoiced; the table includes the name of the product, quantity, price, etc. This is why we need to the PDF to reproduce what the users have designed. In the template editor since we don't know upfront the height of the table (we know the width and the columns headers) we drop a table with 3 rows as a sample, but in practice the table's height varied depending on the number of invoiced items. Underneath the table there is the other table with the summary with things such as subtotal, VAT, total, etc. We made that summary table follow the main one using space-before and start-indent. This design has the limitation that anything underneath the main table and the following summary table might get hidden by the content of the tables if they are too long. Having said that, in most of the cases that will not be so. We just need to tell users to take this into account during design. Put it in a different way, the tool does the job and covers most needs but it does not cover 100% of the cases. We did use absolute positioning because it was the easiest thing to do. However I now see that perhaps that wasn't the best choice and doing all the positioning with space-before and start-indent will provide a more flexible tool. For once, it will remove the limitation that anything under the tables might get hidden by the tables content. It will also span multiple pages if needed. Going forward we also plan to support header/footer, which will allow users to have a finer control on what should appear in each page when it spans over a single page. One last question. I think that the main issue we are having with the current design is the constarins along the block propagation direction. So the first thin we need to do is to relax the structure and replace the top attribute by the space-before one. We don't have an issue in the inline direction, so, can I keep using the left attribute there ?. So it will be a mix of start-before and left attributes. Thanks again for you input. It is very much appreciated. Regards, Fernando On Sun, Jul 31, 2011 at 12:11 AM, Rob Sargent wrote: > OP might also be interested in calculating the required offset on the > second page (end of the table) at which to place (absolutely??) the > follow-on text. If so follow the (ill-named) thread "breakpoint suggestions > please". > > One is tempted to ask why the WYSIWYG editor doesn't open a second page... > > > > > Andreas L. Delmelle wrote: > >> On 30 Jul 2011, at 21:13, Fernando Israel wrote: >> >> Hi Fernando, >> >> >> >>> >>> So I now have to rephrase the question. Can I have a table within an >>> absolute postioned block container go over to a second page it its length >>> requires so ?. I guess that the answer is no, but I better ask. >>> >>> >> >> You guess correct. >> >> BTW, it just occurred to me, while re-examining the FO you sent, that the >> 'position' property does not apply to fo:block, so it actually serves no >> purpose there. >> Specifying the property can almost be seen as wasteful, because it >> 'overburdens' the property parser. Big word, because it does not matter >> _that_ much, but "less is more". :-) >> >> >> >>> If the answer is no, given my description of the objective, can you think >>> of a different way of trying to achieve the objective ?. >>> >>> >> >> Let's see... >> >> The block-container will only be broken if its top/left positioning is >> relative, which FOP does not support. Never
Re: Content spanning multiple pages issue
OP might also be interested in calculating the required offset on the second page (end of the table) at which to place (absolutely??) the follow-on text. If so follow the (ill-named) thread "breakpoint suggestions please". One is tempted to ask why the WYSIWYG editor doesn't open a second page... Andreas L. Delmelle wrote: On 30 Jul 2011, at 21:13, Fernando Israel wrote: Hi Fernando, So I now have to rephrase the question. Can I have a table within an absolute postioned block container go over to a second page it its length requires so ?. I guess that the answer is no, but I better ask. You guess correct. BTW, it just occurred to me, while re-examining the FO you sent, that the 'position' property does not apply to fo:block, so it actually serves no purpose there. Specifying the property can almost be seen as wasteful, because it 'overburdens' the property parser. Big word, because it does not matter _that_ much, but "less is more". :-) If the answer is no, given my description of the objective, can you think of a different way of trying to achieve the objective ?. Let's see... The block-container will only be broken if its top/left positioning is relative, which FOP does not support. Never mind, because that is not what you want anyway. You would get a page-break, sure enough, but it would still cause _some_ of the content to be clipped. In fact, what would happen if FOP were to implement it, is that the block-container would be broken using the full available page-height, as it does not interact with the absolute-positioned ones. Then, the generated areas on each page are offset by the specified amount. Hardly surprising that nobody has ever even asked questions about this on the user-list (at least AFAIK). It doesn't look useful --but I'm straying... Given the above, and assuming that, in the example you sent, you would only need to see that one block flowing to the next page, you could try using space-before (instead of "top") and start-indent (instead of "left") to create the displacement effect. Something like: TEXT 9 Here is some sample code Here is some sample code ... That way, at least that block-container will be split over multiple pages, if necessary. Any absolute-positioned content following it, will have its single area on the last page spanned by the preceding, relative-positioned content. Since it is likely not known in advance how many lines will end up on that last page, figuring out the right value for 'top' in such cases would be quite a challenge. Using 'bottom' displacement may offer a way out, here, but still... If there is then yet more following relative-positioned content, it becomes increasingly difficult to manage, since there is no clue as to what the initial offset should be. You would have to resort to using forced breaks to make it a bit easier. It all really depends on how complex the eventual result can become. If it's only a single block that should flow to the next page, and it is not itself interrupted/followed by absolute-positioned content, the above would suffice: use a regular block-container with space-before for the initial displacement on the first page, or even leave that block-container out entirely, and just insert the block. Not sure if this will help, but it's very difficult to say, generically, how best to address this, without actually having seen some of the more complex cases. Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Content spanning multiple pages issue
On 30 Jul 2011, at 21:13, Fernando Israel wrote: Hi Fernando, > > So I now have to rephrase the question. Can I have a table within an absolute > postioned block container go over to a second page it its length requires so > ?. I guess that the answer is no, but I better ask. You guess correct. BTW, it just occurred to me, while re-examining the FO you sent, that the 'position' property does not apply to fo:block, so it actually serves no purpose there. Specifying the property can almost be seen as wasteful, because it 'overburdens' the property parser. Big word, because it does not matter _that_ much, but "less is more". :-) > If the answer is no, given my description of the objective, can you think of > a different way of trying to achieve the objective ?. Let's see... The block-container will only be broken if its top/left positioning is relative, which FOP does not support. Never mind, because that is not what you want anyway. You would get a page-break, sure enough, but it would still cause _some_ of the content to be clipped. In fact, what would happen if FOP were to implement it, is that the block-container would be broken using the full available page-height, as it does not interact with the absolute-positioned ones. Then, the generated areas on each page are offset by the specified amount. Hardly surprising that nobody has ever even asked questions about this on the user-list (at least AFAIK). It doesn't look useful --but I'm straying... Given the above, and assuming that, in the example you sent, you would only need to see that one block flowing to the next page, you could try using space-before (instead of "top") and start-indent (instead of "left") to create the displacement effect. Something like: TEXT 9 Here is some sample code Here is some sample code ... That way, at least that block-container will be split over multiple pages, if necessary. Any absolute-positioned content following it, will have its single area on the last page spanned by the preceding, relative-positioned content. Since it is likely not known in advance how many lines will end up on that last page, figuring out the right value for 'top' in such cases would be quite a challenge. Using 'bottom' displacement may offer a way out, here, but still... If there is then yet more following relative-positioned content, it becomes increasingly difficult to manage, since there is no clue as to what the initial offset should be. You would have to resort to using forced breaks to make it a bit easier. It all really depends on how complex the eventual result can become. If it's only a single block that should flow to the next page, and it is not itself interrupted/followed by absolute-positioned content, the above would suffice: use a regular block-container with space-before for the initial displacement on the first page, or even leave that block-container out entirely, and just insert the block. Not sure if this will help, but it's very difficult to say, generically, how best to address this, without actually having seen some of the more complex cases. Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Content spanning multiple pages issue
Hi Andreas, Thank you for your prompt response. If you hadn't tell me the why I would have not got to that in a million years. I am glad I have asked and that you shed the necessary light. On the basis of your input it is quite clear that I cannot achieve the objective with the current XSL-FO I am using, so I need to re-design it. Let me give you the background as to why I am using absolute positioning for all blocks. This project is part of an application that has a web client where users design the document. The web client is a kind of WYSIWYG type of app that shows the presents the user with a blank canvas, which is the size of the page they selected -e.g. A4, Legal, etc., along with the margins selected, and there is a series of tools that allow the user to drop text, images and tables. In the canvas the user can re-size the blocks and images. We then take all this sizing, position, and content information in XML format, and pass it through an XSL-FO stylesheet to produce the input to FOP. Obviously the size and position of the content is important because we basically translate what the user designs in the web app into a PDF that looks the same as his/her design. In practice the web app only shows one page in the canvas so it is implicitly assumed that the output will always be one page. However, as I mentioned there is one table always and the table length depends on the number of rows, which in turn depends on dynamic data that we (the server) does not know upfront. In most cases the table will fit within one page so there would not be a problem. But I want to deal with the more rare case when the table length is such that it should go over the first page and into the second page. I haven't reflected this variable table in the XSL-FO I posted because I didn't know that the issue I am facing has to do with absolute positioning. But essentially the table also lives within an absolute positioned block. So I now have to rephrase the question. Can I have a table within an absolute postioned block container go over to a second page it its length requires so ?. I guess that the answer is no, but I better ask. If the answer is no, given my description of the objective, can you think of a different way of trying to achieve the objective ?. Thank you very much again for your help. It is very much appreciated. Regards, Fernando On Sat, Jul 30, 2011 at 3:45 PM, Andreas L. Delmelle < andreas.delme...@telenet.be> wrote: > On 30 Jul 2011, at 17:55, Fernando Israel wrote: > > Hi Fernando > > > I use FOP 1.0 to produce PDFs. The issue I am facing is that the content > of the page is such that it should span over multiple pages but I only get > one single page PDF file. I believe I am missing something very obvious. > > The reason is that *all* the content is wrapped inside absolute-positioned > block-containers. Those will never, ever trigger a page-break. At worst, > there will be an overflow condition if the content does not fit, but it will > never flow to the next page, like a 'regular' block-container. (In XSL-FO > terminology, regular block-containers will potentially yield multiple > viewport/reference pairs, whereas absolute-positioned ones will always have > only one such pair.) > > To give advice on how to resolve this (in case it is still necessary), we > would also need a hint of the intended result. > > Let us know if we can be of further assistance. > > > HTH! > > Regards > > Andreas > > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > >
Re: Content spanning multiple pages issue
On 30 Jul 2011, at 17:55, Fernando Israel wrote: Hi Fernando > I use FOP 1.0 to produce PDFs. The issue I am facing is that the content of > the page is such that it should span over multiple pages but I only get one > single page PDF file. I believe I am missing something very obvious. The reason is that *all* the content is wrapped inside absolute-positioned block-containers. Those will never, ever trigger a page-break. At worst, there will be an overflow condition if the content does not fit, but it will never flow to the next page, like a 'regular' block-container. (In XSL-FO terminology, regular block-containers will potentially yield multiple viewport/reference pairs, whereas absolute-positioned ones will always have only one such pair.) To give advice on how to resolve this (in case it is still necessary), we would also need a hint of the intended result. Let us know if we can be of further assistance. HTH! Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Content spanning multiple pages issue
Hi All, I use FOP 1.0 to produce PDFs. The issue I am facing is that the content of the page is such that it should span over multiple pages but I only get one single page PDF file. I believe I am missing something very obvious. Here is a sample of the XSL-FO I feed FOP and I am attaching the PDF that this produces too. As you can see one of the blocks in the flow (TEXT 9) has over 30 children blocks and, based on their positions on the page, this would lead to part of the content to spill over a second page.However, as can be seen in the PDF output attached, the content gets truncated and the PDF contains just one page. Is this something to do with my XSL-FO or is it something I am missing of FOP ?. Thank you very much in advance. Regards, Fernando http://www.w3.org/1999/XSL/Format";> TEXT 1 TEXT 2 TEXT 3 TEXT 4 TEXT 5 TEXT 6 TEXT 7 TEXT 8 TEXT 9 Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code Here is some sample code FopTest.pdf Description: Adobe PDF document - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
