xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Sargent <rsarg...@xmission.com>
Subject Re: spurious indentation with (small) text lose
Date Tue, 14 Aug 2012 20:33:24 GMT
Certainly gives one hope!
We do have 6 consecutive pages in the current plan, so I may be up for 
the local patch.
I'll report back asap.


Thanks,

rjs

On 08/14/2012 02:23 PM, Vincent Hennebert wrote:
> 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<rsargent@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-unsubscribe@xmlgraphics.apache.org
>>>>> For additional commands, e-mail:fop-users-help@xmlgraphics.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message