Hi Rob, On 14/08/12 15:42, Rob Sargent wrote: > Do we at least agree that there is a problem?
Maybe not. Short version: on the region-bodies that are meant to be empty (the region-body elements from page masters ‘gallery6-page-[3-8]’ in the latest document you attached), set the column-count to 1. Also, make sure that no more than 5 such page masters ever consecutively follow each other. Long story: when FOP cannot fit any content on a page, it skips it and moves on to the next page, hoping that that next page will be big enough to accommodate some content. If the next page cannot accommodate any content either, then FOP skips it too and moves on to the next page, and so on, until it finds a suitable page, /or/ it has skipped pages more than 5 times in a row. The latter condition is to avoid entering an infinite loop, where FOP would hopelessly look for a page that can accommodate content while all the remaining pages of the page sequence actually have zero height. If your pages have multiple columns, then take the text above and substitute page with column. This is the case of your sample document, where FOP gives up at the second column of gallery6-page5. Which means that you cannot put more than 2 such pages consecutively in your document. Since the gallery pages are not meant to have a body, it doesn’t matter whether you specify a column-count of 1 or 2. Setting it to 1 will allow you to put up to 5 such pages in a row. If this is still not enough, then you can change the MAX_RECOVERY_ATTEMPTS constant in src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java to whatever suits your needs. Note that this constant is also used for line breaking, so you may want to keep it reasonably low in order to reduce the impact on performance. Something as small as 10 might be more than enough for your needs. In theory, you could avoid all that fiddling by giving a special region-name to the gallery page-masters’ region-bodies, but some quick experiments gave strange results on my side. I would have to investigate a bit more to find out what’s happening exactly. FOP could also be a little better at detecting a possible infinite loop, by analysing the page sequence and finding out whether there will ever be a suitable page, or if for example that page-sequence will always produce an alternation of the two same non-suitable pages. But that’s another story... HTH, Vincent > > Cheers, > rjs > > On 08/04/2012 03:46 PM, Rob Sargent wrote: >> OK I have a attached an fo which is free of our special fonts which >> addresses the variation of text loss to which I alluded in last post >> (missing paragraphs across textless pages). I get identical pdf from >> fop-1.0 and fop-1.1rc1-VH, showing the same data loss. >> >> Notice that the first page ends with a hyphenated word, yet the text picks >> up three pages later with the a major heading, losing the continuation of >> the hyphenated word plus the remainder of the sentence. If one adds more >> textless pages the data loss in creases. There is no data loss if there are >> only two consecutive textless pages. The real version of this chapter (54 >> pages) has a sequence of 6 textless pages. >> >> I've left the other three s-p-ms in the supplied fo, commented out. You can >> see the increase in data loss by adding (un-commenting) those back into play. >> >> However, I do suspect that the problem demonstrated here is not the same >> issue as first shown in this thread. I believe they are similar, aside from >> the fact of data loss: they are both dependent on the s-p-m ordering. >> >> In case brother Vincent is listening in, there is but one overflow warning: >> >> WARNING: Content overflows the viewport of the fo:region-body on >> page 3 in block-progression direction by 24480 millipoints. (See >> position 29:126) >> >> and you can see that this refers to the region-body of a "textless" page. >> With additional textless pages there are additional overflow warning for the >> successive region-body definitions. >> >> If overflow is the problem; is this overflow from the post-hyphenation >> content. That's about the correct linear requirement (~ 2 lines of text) >> >> I hope you are able to regenerate the problem now. We certainly can :) >> >> Cheers, >> >> rjs >> >> >> On 08/03/2012 09:05 AM, Rob Sargent wrote: >>> Drats! It's 100% reproducible here with necessary fonts. Should I post >>> the pdf? Lend you the fonts? >>> >>> Note that fop1.1rc1-VH has been tried but production is still using fop-1.0. >>> >>> We have multiple cases in production. Also a variation of the problem >>> which is losing two paragraphs when the flow extends over multiple textless >>> pages. >>> >>> >>> Ever desparate, >>> >>> rjs >>> >>> On 08/03/2012 01:23 AM, Pascal Sancho wrote: >>>> Hi, >>>> >>>> Unless I missed something, I cannot reproduce what you describe. >>>> did you tried it without VH's patch? >>>> I note that my FOP substitutes some fonts, that an have some effect there. >>>> I attach the output (pdf from FOP trunk, without patch and without >>>> your fonts), so you will see if there is something wrong in it. >>>> >>>> >>>> 2012/8/2 rsargent<rsarg...@xmission.com>: >>>>> We've hit this a couple of times now and I have a small fo showing the >>>>> problem. >>>>> >>>>> In production we are using fop-1.0, but I've generated this on both >>>>> 1.0 and 1.1rc1 (with a small patch from Vincent related to >>>>> http://apache-fop.1065347.n5.nabble.com/page-number-is-stuttering-tt36312.html >>>>> >>>>> page-number-stutters ) >>>>> >>>>> See the top of the second page of the generated pdf: the text is indented >>>>> ~ >>>>> 5 chars and missing the word "appears". >>>>> >>>>> The full sentence is shown below. >>>>> <fo:inline margin-left="4pt" font-weight="normal"> >>>>> While most PNFs remain benign, between 10-15% become >>>>> malignant. Deep-seated PNFs are at particular risk for development >>>>> <inline xmlns="http://www.w3.org/1999/XSL/Format"; >>>>> font-weight="bold">MPNST</inline> >>>>> . MicroRNA misregulation appears to be a critical >>>>> event >>>>> in the malignant transformation of PNFs. >>>>> </fo:inline> >>>>> >>>>> I apologise for the funky fonts, but this problem is so delicate >>>>> w.r.t. content that I cannot switch out my fonts at this time. >>>>> >>>>> The juxtaposition of the two simple-page-masters is critcal. The >>>>> gap/loss always appears on the "three-side" page layouts. I have >>>>> removed any overflows (Vincent ;) ) so I don't thing that as the problem. >>>>> >>>>> http://apache-fop.1065347.n5.nabble.com/file/n36563/short.xml short.xml >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
