You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by rsargent <rs...@xmission.com> on 2012/08/02 19:56:36 UTC
spurious indentation with (small) text lose
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
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/spurious-indentation-with-small-text-lose-tp36563.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: spurious indentation with (small) text lose
Posted by Rob Sargent <rs...@xmission.com>.
Of course the subject should have read "(small) text loss"
On 08/02/2012 11:56 AM, rsargent wrote:
> 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
>
>
>
>
> --
> View this message in context: http://apache-fop.1065347.n5.nabble.com/spurious-indentation-with-small-text-lose-tp36563.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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
Re: spurious indentation with (small) text lose SOLVED
Posted by Samuel Penn <sa...@glendale.org.uk>.
On Thursday 06 September 2012 19:57:03 Rob Sargent wrote:
> On 09/06/2012 12:03 PM, Samuel Penn wrote:
> > The general layout of the documents themselves isn't particulary
> > exciting. There's a lot I'd like to be able to do, especially around
> > image and table layout (auto-placement of images, and stretching them
> > across two text columns etc), which doesn't yet seem to be possible in
> > FOP.
>
> span="all" doesn't work? You would of course have to split the page into
> before, body and after regions and place some of the content in the
> erstwhile head and footer. Alternatively a trick VH showed me is to
> print content twice covering 200% of the available width and use
> left/right indent at 0% and -100% alternately. This is how I print
> tables across two pages.
Haven't tried that. I do already make use of the header/footer, so I
don't know whether that prevents use of this technique.
When I get time, I might look into that.
I do have a workaround for tables - I have a chapter type which has
a single column, and save all the big tables until then. It's not
ideal, but it's functional.
--
Be seeing you, Games: http://www.glendale.org.uk/
Sam. Posts: http://www.google.com/profiles/samuel.penn
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: spurious indentation with (small) text lose SOLVED
Posted by Glenn Adams <gl...@skynav.com>.
you guys are getting rather off topic here; i'd suggest you start a new
thread if you wish to continue
On Fri, Sep 7, 2012 at 2:57 AM, Rob Sargent <rs...@xmission.com> wrote:
> On 09/06/2012 12:03 PM, Samuel Penn wrote:
>
> The general layout of the documents themselves isn't particulary exciting.
> There's a lot I'd like to be able to do, especially around image and table
> layout (auto-placement of images, and stretching them across two text
> columns etc), which doesn't yet seem to be possible in FOP.
>
> span="all" doesn't work? You would of course have to split the page into
> before, body and after regions and place some of the content in the
> erstwhile head and footer. Alternatively a trick VH showed me is to print
> content twice covering 200% of the available width and use left/right
> indent at 0% and -100% alternately. This is how I print tables across two
> pages.
>
> <fo:table border-collapse="separate" table-layout="fixed" width="200%"
> start-indent="{$leftIndent}%"
> end-indent="{$rightIndent}%">
>
> There's an example document here:
> http://yags.glendale.org.uk/download/yags-character.pdf Which is built
> from the source XML files here:
> http://yagsbook.svn.sourceforge.net/viewvc/yagsbook/trunk/sources/yags/
>
>
>
Re: spurious indentation with (small) text lose SOLVED
Posted by Rob Sargent <rs...@xmission.com>.
On 09/06/2012 12:03 PM, Samuel Penn wrote:
> The general layout of the documents themselves isn't particulary
> exciting. There's a lot I'd like to be able to do, especially around
> image and table layout (auto-placement of images, and stretching them
> across two text columns etc), which doesn't yet seem to be possible in
> FOP.
span="all" doesn't work? You would of course have to split the page into
before, body and after regions and place some of the content in the
erstwhile head and footer. Alternatively a trick VH showed me is to
print content twice covering 200% of the available width and use
left/right indent at 0% and -100% alternately. This is how I print
tables across two pages.
<fo:table border-collapse="separate" table-layout="fixed" width="200%"
start-indent="{$leftIndent}%"
end-indent="{$rightIndent}%">
> There's an example document here:
> http://yags.glendale.org.uk/download/yags-character.pdf Which is built
> from the source XML files here:
> http://yagsbook.svn.sourceforge.net/viewvc/yagsbook/trunk/sources/yags/
Re: spurious indentation with (small) text lose SOLVED
Posted by Samuel Penn <sa...@glendale.org.uk>.
On Thursday 06 September 2012 17:07:37 Rob Sargent wrote:
> On 09/06/2012 06:04 AM, Samuel Penn wrote:
> > On Tue, 04 Sep 2012 09:46:23 -0600, Rob Sargent
> >
> > <rs...@xmission.com> wrote:
> >> I have long suspected that what we're asking FOP to do is somewhat
> >>
> >> "out there". Man would I love a review of my xsl/fo
> >> transformation. 2700+ lines of xsl can't be a good thing!
> >
> > That doesn't seem that bad. My own XSLT for FOP is pushing 7000 lines.
> >
> > :-)
>
> That's just wrong! :) What on earth are you doing?
Documenting rules for a (pen and paper) roleplaying game. Most of it is
handling the maths and rules for displaying inline character sheets, or
building lists of skills, spells or equipment which do a lot of referencing
to each other and semi-complex mangling according to game rules.
I started off using Docbook, then decided it was too complex in areas I
wasn't interested in, and wasn't suited to handling the things I was
interested in.
The code is here:
http://yagsbook.svn.sourceforge.net/viewvc/yagsbook/trunk/xml/xslt/pdf/
The project is over 10 years old, so there's probably a lot of cruft
in there which doesn't help matters.
The general layout of the documents themselves isn't particulary
exciting. There's a lot I'd like to be able to do, especially around
image and table layout (auto-placement of images, and stretching them
across two text columns etc), which doesn't yet seem to be possible in
FOP. There's an example document here:
http://yags.glendale.org.uk/download/yags-character.pdf
Which is built from the source XML files here:
http://yagsbook.svn.sourceforge.net/viewvc/yagsbook/trunk/sources/yags/
--
Be seeing you, Games: http://www.glendale.org.uk/
Sam. Posts: http://www.google.com/profiles/samuel.penn
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: spurious indentation with (small) text lose
Posted by Rob Sargent <rs...@xmission.com>.
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<rs...@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
Re: spurious indentation with (small) text lose SOLVED
Posted by Rob Sargent <rs...@xmission.com>.
On 09/06/2012 06:04 AM, Samuel Penn wrote:
> On Tue, 04 Sep 2012 09:46:23 -0600, Rob Sargent
> <rs...@xmission.com> wrote:
>> I have long suspected that what we're asking FOP to do is somewhat
>> "out there". Man would I love a review of my xsl/fo
>> transformation. 2700+ lines of xsl can't be a good thing!
>
> That doesn't seem that bad. My own XSLT for FOP is pushing 7000 lines.
> :-)
>
That's just wrong! :) What on earth are you doing?
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: spurious indentation with (small) text lose SOLVED
Posted by Samuel Penn <sa...@glendale.org.uk>.
On Tue, 04 Sep 2012 09:46:23 -0600, Rob Sargent <rs...@xmission.com>
wrote:
> I have long suspected that what we're asking FOP to do is somewhat
> "out there". Man would I love a review of my xsl/fo
> transformation. 2700+ lines of xsl can't be a good thing!
That doesn't seem that bad. My own XSLT for FOP is pushing 7000 lines.
:-)
--
Be seeing you,
Sam.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: spurious indentation with (small) text lose SOLVED
Posted by Rob Sargent <rs...@xmission.com>.
I hate to wimp-out on you good sir, but I'm /really/ under the gun right
now. It will be at least a week before I can (attempt to) put together
an example fo.
I have long suspected that what we're asking FOP to do is somewhat "out
there". Man would I love a review of my xsl/fo transformation. 2700+
lines of xsl can't be a good thing!
But it's shaping up to be a beautiful book, thanks to FOP.
On 09/04/2012 09:21 AM, Vincent Hennebert wrote:
> On 04/09/12 16:04, Rob Sargent wrote:
>> Wonderful. Thank you very much. It's working great here.
>>
>> An interesting twist on the other side of this thread (re:
>> MAX_RECOVERY_ATTEMPTS). We find that if the last image-bearing page of a
>> chapter is a text-less gallery page the page immediately following page is
>> confused about it's column-count. It's defined as a two-column page but the
>> first column appears to be rendered full width and the second column
>> over-prints. I've fixed that by using column-count="2" on the gallery page
>> and that seems to clear things up.
> Could you start a new thread about this and upload a small file showing
> the issue?
>
>
>> Thanks again for all you help. We believe we are good to go to print very
>> soon. And just in time! We probably won't wait for the general release of
>> fop-1.1.
> Glad it works. I must say, your documents are pushing FOP to the limit
> of its comfort zone...
>
>
>> Cheers,
>>
>> rjs
>
> Thanks,
> Vincent
>
>
>> On 09/04/2012 08:36 AM, Vincent Hennebert wrote:
>>> I’ve just submitted a fix to trunk:
>>> http://svn.apache.org/viewvc?rev=1380667&view=rev
>>>
>>> Vincent
>>>
>>>
>>> On 30/08/12 20:54, rsargent wrote:
>>>> Ok if Vincent agrees this is a bug I can make the issue and supply the test
>>>> fo. The patch is his and I don't think I should claim it.
>>>>
>>>>
>>>> Glenn Adams-2 wrote
>>>>> First, someone needs to open a bug and submit a patch against the bug.
>>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://apache-fop.1065347.n5.nabble.com/spurious-indentation-with-small-text-lose-tp36563p36733.html
>>>>
>>>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
Re: spurious indentation with (small) text lose SOLVED
Posted by Vincent Hennebert <vh...@gmail.com>.
On 04/09/12 16:04, Rob Sargent wrote:
> Wonderful. Thank you very much. It's working great here.
>
> An interesting twist on the other side of this thread (re:
> MAX_RECOVERY_ATTEMPTS). We find that if the last image-bearing page of a
> chapter is a text-less gallery page the page immediately following page is
> confused about it's column-count. It's defined as a two-column page but the
> first column appears to be rendered full width and the second column
> over-prints. I've fixed that by using column-count="2" on the gallery page
> and that seems to clear things up.
Could you start a new thread about this and upload a small file showing
the issue?
> Thanks again for all you help. We believe we are good to go to print very
> soon. And just in time! We probably won't wait for the general release of
> fop-1.1.
Glad it works. I must say, your documents are pushing FOP to the limit
of its comfort zone...
> Cheers,
>
> rjs
Thanks,
Vincent
> On 09/04/2012 08:36 AM, Vincent Hennebert wrote:
>> I’ve just submitted a fix to trunk:
>> http://svn.apache.org/viewvc?rev=1380667&view=rev
>>
>> Vincent
>>
>>
>> On 30/08/12 20:54, rsargent wrote:
>>> Ok if Vincent agrees this is a bug I can make the issue and supply the test
>>> fo. The patch is his and I don't think I should claim it.
>>>
>>>
>>> Glenn Adams-2 wrote
>>>> First, someone needs to open a bug and submit a patch against the bug.
>>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://apache-fop.1065347.n5.nabble.com/spurious-indentation-with-small-text-lose-tp36563p36733.html
>>>
>>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: spurious indentation with (small) text lose SOLVED
Posted by Rob Sargent <rs...@xmission.com>.
Wonderful. Thank you very much. It's working great here.
An interesting twist on the other side of this thread (re:
MAX_RECOVERY_ATTEMPTS). We find that if the last image-bearing page of
a chapter is a text-less gallery page the page immediately following
page is confused about it's column-count. It's defined as a two-column
page but the first column appears to be rendered full width and the
second column over-prints. I've fixed that by using column-count="2" on
the gallery page and that seems to clear things up.
Thanks again for all you help. We believe we are good to go to print
very soon. And just in time! We probably won't wait for the general
release of fop-1.1.
Cheers,
rjs
On 09/04/2012 08:36 AM, Vincent Hennebert wrote:
> I’ve just submitted a fix to trunk:
> http://svn.apache.org/viewvc?rev=1380667&view=rev
>
> Vincent
>
>
> On 30/08/12 20:54, rsargent wrote:
>> Ok if Vincent agrees this is a bug I can make the issue and supply the test
>> fo. The patch is his and I don't think I should claim it.
>>
>>
>> Glenn Adams-2 wrote
>>> First, someone needs to open a bug and submit a patch against the bug.
>>>
>>
>>
>>
>> --
>> View this message in context: http://apache-fop.1065347.n5.nabble.com/spurious-indentation-with-small-text-lose-tp36563p36733.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> 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
Re: spurious indentation with (small) text lose SOLVED
Posted by Vincent Hennebert <vh...@gmail.com>.
I’ve just submitted a fix to trunk:
http://svn.apache.org/viewvc?rev=1380667&view=rev
Vincent
On 30/08/12 20:54, rsargent wrote:
> Ok if Vincent agrees this is a bug I can make the issue and supply the test
> fo. The patch is his and I don't think I should claim it.
>
>
> Glenn Adams-2 wrote
>>
>> First, someone needs to open a bug and submit a patch against the bug.
>>
>
>
>
>
> --
> View this message in context: http://apache-fop.1065347.n5.nabble.com/spurious-indentation-with-small-text-lose-tp36563p36733.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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
Re: spurious indentation with (small) text lose SOLVED
Posted by rsargent <rs...@xmission.com>.
Ok if Vincent agrees this is a bug I can make the issue and supply the test
fo. The patch is his and I don't think I should claim it.
Glenn Adams-2 wrote
>
> First, someone needs to open a bug and submit a patch against the bug.
>
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/spurious-indentation-with-small-text-lose-tp36563p36733.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: spurious indentation with (small) text lose SOLVED
Posted by Glenn Adams <gl...@skynav.com>.
On Thu, Aug 30, 2012 at 7:40 AM, rsargent <rs...@xmission.com> wrote:
> I am happy to report (rather belatedly I'm afraid) that the patch has done
> the trick.
>
> The test fo supplied no longer presents the problem and we see none in our
> book. It's hard to know from the book itself whether the lack of problems
> is
> happy coincidence or not, but the test is quite clear.
>
> Is this patch to be expected in the 1.1 final release?
>
First, someone needs to open a bug and submit a patch against the bug.
Re: spurious indentation with (small) text lose SOLVED
Posted by rsargent <rs...@xmission.com>.
I am happy to report (rather belatedly I'm afraid) that the patch has done
the trick.
The test fo supplied no longer presents the problem and we see none in our
book. It's hard to know from the book itself whether the lack of problems is
happy coincidence or not, but the test is quite clear.
Is this patch to be expected in the 1.1 final release?
Undying gratitude,
rjs
--
View this message in context: http://apache-fop.1065347.n5.nabble.com/spurious-indentation-with-small-text-lose-tp36563p36730.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: spurious indentation with (small) text lose
Posted by Rob Sargent <rs...@xmission.com>.
THANKS! I'll start with the patch, then leader, then revisit indent
property and report first success.
My apologies for conflating two issues in this thread. I had no
business presuming they were related.
rjs
On 08/22/2012 04:23 AM, Vincent Hennebert wrote:
> On 20/08/12 16:05, Rob Sargent wrote:
>> Do we agree that this portion of the thread (small data loss at page break)
>> really is an issue?
> Yes, this is due to the text-indent property set on the block that is
> broken over the two pages, that doesn't play well with the changing IPD
> code.
>
> You can:
> . Remove the text-indent property, if you can live with the start of the
> paragraph being flush with the left margin;
> . Replace the text-indent with an <fo:leader leader-length="{the value
> of the text indent}/> at the beginning of the block. This might be
> tricky as there must be no whitespace whatsoever between that
> fo:leader and the word starting the paragraph. Also, I may have
> overlooked undesirable side effects. But it may be worth a try.
> . Avoid creating page masters where the region-body only has one column.
> That triggers the changing IPD hack that is notoriously buggy. Note
> that in theory the trigger shouldn't be made, as your columns all have
> the same width (I believe). But there's another bug in FOP where the
> number of columns on a region-body is not taken into account when
> determining whether the IPD changes or not.
> So in the present case, FOP compares the width of the region-body on
> the first page to the width of the region-body on the second page,
> which are different since the second region-body has a big left margin
> to leave space to the region-start.
> . Apply the attached patch and hope that it doesn't break anything else.
> It resets a few variables to account for the fact that the first line
> of the block has already been rendered.
>
> HTH,
> Vincent
>
>
>> rjs
>>
>>
>> On 08/15/2012 11:53 AM, Rob Sargent wrote:
>>> And now we have attached the smallest possible fo, with only
>>> font-family="any" which shows the spurious text loss across a page break.
>>> Note that the top of page 2 is slightly indented (not our intent) and is
>>> missing text (in this case the single Âword "appears").
>>>
>>> I'm tempted to include the pdf (generated with 1.1rc1-VHx2) but won't until
>>> I here you're not able to reproduce the problem!
>>>
>>> Cheers,
>>>
>>> rjs
>>>
>>>
>>>
>>>
>>> On 08/15/2012 09:14 AM, Rob Sargent wrote:
>>>> Meanwhile...
>>>>
>>>> IT WORKS. I set column-count to 1 and set the (derogatory remark
>>>> redacted) MAX_RECOVERY_ATTEMPTS to 10, which was lucky because by the time
>>>> I got back to the original document it had 7 text-free pages in succession.
>>>>
>>>> Now, recall the title of this thread (swapping loss for lose of course): I
>>>> had hoped that the two issues were related but no such luck. I expect to
>>>> have a funky-font free example by end of day. This is a real problem here
>>>> and I have a sinking feeling that I cannot correct it with layout tricks.
>>>>
>>>> Thanks a ton,
>>>> rjs
>>>>
>>>>
>>>> On 08/15/2012 02:47 AM, Vincent Hennebert wrote:
>>>>> On 14/08/12 23:20, Glenn Adams wrote:
>>>>>> On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert
>>>>>> <vh...@gmail.com>wrote:
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>> Is it worth introducing the ability for the FOP operator to specify the
>>>>>> maximum recovery attempts via fop.xconf? Is it worth dividing this into two
>>>>>> settings, one for page breaking, another for line breaking?
>>>>> I don't think it's worth the additional complexity of wiring a look-up
>>>>> to a configuration variable. I'd rather implement a more intelligent
>>>>> analysis of the page sequence to determine if there will be an infinite
>>>>> loop or not.
>>>>>
>>>>>
>>>>>> I'd prefer not to have non-configurable magic numbers of this sort if
>>>>>> possible.
>>>>> Vincent
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>>>>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: spurious indentation with (small) text lose
Posted by Vincent Hennebert <vh...@gmail.com>.
On 20/08/12 16:05, Rob Sargent wrote:
> Do we agree that this portion of the thread (small data loss at page break)
> really is an issue?
Yes, this is due to the text-indent property set on the block that is
broken over the two pages, that doesn’t play well with the changing IPD
code.
You can:
• Remove the text-indent property, if you can live with the start of the
paragraph being flush with the left margin;
• Replace the text-indent with an <fo:leader leader-length="{the value
of the text indent}/> at the beginning of the block. This might be
tricky as there must be no whitespace whatsoever between that
fo:leader and the word starting the paragraph. Also, I may have
overlooked undesirable side effects. But it may be worth a try.
• Avoid creating page masters where the region-body only has one column.
That triggers the changing IPD hack that is notoriously buggy. Note
that in theory the trigger shouldn’t be made, as your columns all have
the same width (I believe). But there’s another bug in FOP where the
number of columns on a region-body is not taken into account when
determining whether the IPD changes or not.
So in the present case, FOP compares the width of the region-body on
the first page to the width of the region-body on the second page,
which are different since the second region-body has a big left margin
to leave space to the region-start.
• Apply the attached patch and hope that it doesn’t break anything else.
It resets a few variables to account for the fact that the first line
of the block has already been rendered.
HTH,
Vincent
> rjs
>
>
> On 08/15/2012 11:53 AM, Rob Sargent wrote:
>> And now we have attached the smallest possible fo, with only
>> font-family="any" which shows the spurious text loss across a page break.
>> Note that the top of page 2 is slightly indented (not our intent) and is
>> missing text (in this case the single Âword "appears").
>>
>> I'm tempted to include the pdf (generated with 1.1rc1-VHx2) but won't until
>> I here you're not able to reproduce the problem!
>>
>> Cheers,
>>
>> rjs
>>
>>
>>
>>
>> On 08/15/2012 09:14 AM, Rob Sargent wrote:
>>> Meanwhile...
>>>
>>> IT WORKS. I set column-count to 1 and set the (derogatory remark
>>> redacted) MAX_RECOVERY_ATTEMPTS to 10, which was lucky because by the time
>>> I got back to the original document it had 7 text-free pages in succession.
>>>
>>> Now, recall the title of this thread (swapping loss for lose of course): I
>>> had hoped that the two issues were related but no such luck. I expect to
>>> have a funky-font free example by end of day. This is a real problem here
>>> and I have a sinking feeling that I cannot correct it with layout tricks.
>>>
>>> Thanks a ton,
>>> rjs
>>>
>>>
>>> On 08/15/2012 02:47 AM, Vincent Hennebert wrote:
>>>> On 14/08/12 23:20, Glenn Adams wrote:
>>>>> On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert
>>>>> <vh...@gmail.com>wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>> Is it worth introducing the ability for the FOP operator to specify the
>>>>> maximum recovery attempts via fop.xconf? Is it worth dividing this into two
>>>>> settings, one for page breaking, another for line breaking?
>>>> I don't think it's worth the additional complexity of wiring a look-up
>>>> to a configuration variable. I'd rather implement a more intelligent
>>>> analysis of the page sequence to determine if there will be an infinite
>>>> loop or not.
>>>>
>>>>
>>>>> I'd prefer not to have non-configurable magic numbers of this sort if
>>>>> possible.
>>>>
>>>> Vincent
Re: spurious indentation with (small) text lose
Posted by Rob Sargent <rs...@xmission.com>.
Do we agree that this portion of the thread (small data loss at page
break) really is an issue?
rjs
On 08/15/2012 11:53 AM, Rob Sargent wrote:
> And now we have attached the smallest possible fo, with only
> font-family="any" which shows the spurious text loss across a page
> break. Note that the top of page 2 is slightly indented (not our
> intent) and is missing text (in this case the single word "appears").
>
> I'm tempted to include the pdf (generated with 1.1rc1-VHx2) but won't
> until I here you're not able to reproduce the problem!
>
> Cheers,
>
> rjs
>
>
>
>
> On 08/15/2012 09:14 AM, Rob Sargent wrote:
>> Meanwhile...
>>
>> IT WORKS. I set column-count to 1 and set the (derogatory remark
>> redacted) MAX_RECOVERY_ATTEMPTS to 10, which was lucky because by
>> the time I got back to the original document it had 7 text-free pages
>> in succession.
>>
>> Now, recall the title of this thread (swapping loss for lose of
>> course): I had hoped that the two issues were related but no such
>> luck. I expect to have a funky-font free example by end of day. This
>> is a real problem here and I have a sinking feeling that I cannot
>> correct it with layout tricks.
>>
>> Thanks a ton,
>> rjs
>>
>>
>> On 08/15/2012 02:47 AM, Vincent Hennebert wrote:
>>> On 14/08/12 23:20, Glenn Adams wrote:
>>>> On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert
>>>> <vh...@gmail.com>wrote:
>>>>
>>>>> 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.
>>>>>
>>>> Is it worth introducing the ability for the FOP operator to specify
>>>> the
>>>> maximum recovery attempts via fop.xconf? Is it worth dividing this
>>>> into two
>>>> settings, one for page breaking, another for line breaking?
>>> I don't think it's worth the additional complexity of wiring a look-up
>>> to a configuration variable. I'd rather implement a more intelligent
>>> analysis of the page sequence to determine if there will be an infinite
>>> loop or not.
>>>
>>>
>>>> I'd prefer not to have non-configurable magic numbers of this sort if
>>>> possible.
>>>
>>> Vincent
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: spurious indentation with (small) text lose
Posted by Rob Sargent <rs...@xmission.com>.
Interesting upshot: when a single-column textless page precedes the last
page (all text, 2 column) it appears thao FOP is um, er, forgetting to
go to two column mode. The last text page is filled with sentences which
run from border to border, then eventually the two column directive
kicks in and the second column is printed over the first (page-wide)
column. I can think of a couple of work-arounds (raise the
MAX_RECOVERY_ATTEMPTS to 20 and revert to two column) or make a new
layout definition for 'special textless pages near the end of a
chapter'. Regrettable nuisance either way.
Cheers,
rjs
On 08/15/2012 11:53 AM, Rob Sargent wrote:
> And now we have attached the smallest possible fo, with only
> font-family="any" which shows the spurious text loss across a page
> break. Note that the top of page 2 is slightly indented (not our
> intent) and is missing text (in this case the single word "appears").
>
> I'm tempted to include the pdf (generated with 1.1rc1-VHx2) but won't
> until I here you're not able to reproduce the problem!
>
> Cheers,
>
> rjs
>
>
>
>
> On 08/15/2012 09:14 AM, Rob Sargent wrote:
>> Meanwhile...
>>
>> IT WORKS. I set column-count to 1 and set the (derogatory remark
>> redacted) MAX_RECOVERY_ATTEMPTS to 10, which was lucky because by
>> the time I got back to the original document it had 7 text-free pages
>> in succession.
>>
>> Now, recall the title of this thread (swapping loss for lose of
>> course): I had hoped that the two issues were related but no such
>> luck. I expect to have a funky-font free example by end of day. This
>> is a real problem here and I have a sinking feeling that I cannot
>> correct it with layout tricks.
>>
>> Thanks a ton,
>> rjs
>>
>>
>> On 08/15/2012 02:47 AM, Vincent Hennebert wrote:
>>> On 14/08/12 23:20, Glenn Adams wrote:
>>>> On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert
>>>> <vh...@gmail.com>wrote:
>>>>
>>>>> 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.
>>>>>
>>>> Is it worth introducing the ability for the FOP operator to specify
>>>> the
>>>> maximum recovery attempts via fop.xconf? Is it worth dividing this
>>>> into two
>>>> settings, one for page breaking, another for line breaking?
>>> I don't think it's worth the additional complexity of wiring a look-up
>>> to a configuration variable. I'd rather implement a more intelligent
>>> analysis of the page sequence to determine if there will be an infinite
>>> loop or not.
>>>
>>>
>>>> I'd prefer not to have non-configurable magic numbers of this sort if
>>>> possible.
>>>
>>> Vincent
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: spurious indentation with (small) text lose
Posted by Rob Sargent <rs...@xmission.com>.
And now we have attached the smallest possible fo, with only
font-family="any" which shows the spurious text loss across a page
break. Note that the top of page 2 is slightly indented (not our intent)
and is missing text (in this case the single word "appears").
I'm tempted to include the pdf (generated with 1.1rc1-VHx2) but won't
until I here you're not able to reproduce the problem!
Cheers,
rjs
On 08/15/2012 09:14 AM, Rob Sargent wrote:
> Meanwhile...
>
> IT WORKS. I set column-count to 1 and set the (derogatory remark
> redacted) MAX_RECOVERY_ATTEMPTS to 10, which was lucky because by the
> time I got back to the original document it had 7 text-free pages in
> succession.
>
> Now, recall the title of this thread (swapping loss for lose of
> course): I had hoped that the two issues were related but no such
> luck. I expect to have a funky-font free example by end of day. This
> is a real problem here and I have a sinking feeling that I cannot
> correct it with layout tricks.
>
> Thanks a ton,
> rjs
>
>
> On 08/15/2012 02:47 AM, Vincent Hennebert wrote:
>> On 14/08/12 23:20, Glenn Adams wrote:
>>> On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert
>>> <vh...@gmail.com>wrote:
>>>
>>>> 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.
>>>>
>>> Is it worth introducing the ability for the FOP operator to specify the
>>> maximum recovery attempts via fop.xconf? Is it worth dividing this
>>> into two
>>> settings, one for page breaking, another for line breaking?
>> I don’t think it’s worth the additional complexity of wiring a look-up
>> to a configuration variable. I’d rather implement a more intelligent
>> analysis of the page sequence to determine if there will be an infinite
>> loop or not.
>>
>>
>>> I'd prefer not to have non-configurable magic numbers of this sort if
>>> possible.
>>
>> Vincent
>>
>> ---------------------------------------------------------------------
>> 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
>
Re: spurious indentation with (small) text lose
Posted by Rob Sargent <rs...@xmission.com>.
Meanwhile...
IT WORKS. I set column-count to 1 and set the (derogatory remark
redacted) MAX_RECOVERY_ATTEMPTS to 10, which was lucky because by the
time I got back to the original document it had 7 text-free pages in
succession.
Now, recall the title of this thread (swapping loss for lose of course):
I had hoped that the two issues were related but no such luck. I expect
to have a funky-font free example by end of day. This is a real problem
here and I have a sinking feeling that I cannot correct it with layout
tricks.
Thanks a ton,
rjs
On 08/15/2012 02:47 AM, Vincent Hennebert wrote:
> On 14/08/12 23:20, Glenn Adams wrote:
>> On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert <vh...@gmail.com>wrote:
>>
>>> 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.
>>>
>> Is it worth introducing the ability for the FOP operator to specify the
>> maximum recovery attempts via fop.xconf? Is it worth dividing this into two
>> settings, one for page breaking, another for line breaking?
> I don’t think it’s worth the additional complexity of wiring a look-up
> to a configuration variable. I’d rather implement a more intelligent
> analysis of the page sequence to determine if there will be an infinite
> loop or not.
>
>
>> I'd prefer not to have non-configurable magic numbers of this sort if
>> possible.
>
> Vincent
>
> ---------------------------------------------------------------------
> 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
Re: spurious indentation with (small) text lose
Posted by Vincent Hennebert <vh...@gmail.com>.
On 14/08/12 23:20, Glenn Adams wrote:
> On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert <vh...@gmail.com>wrote:
>
>>
>> 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.
>>
>
> Is it worth introducing the ability for the FOP operator to specify the
> maximum recovery attempts via fop.xconf? Is it worth dividing this into two
> settings, one for page breaking, another for line breaking?
I don’t think it’s worth the additional complexity of wiring a look-up
to a configuration variable. I’d rather implement a more intelligent
analysis of the page sequence to determine if there will be an infinite
loop or not.
> I'd prefer not to have non-configurable magic numbers of this sort if
> possible.
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: spurious indentation with (small) text lose
Posted by Glenn Adams <gl...@skynav.com>.
On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert <vh...@gmail.com>wrote:
>
> 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.
>
Is it worth introducing the ability for the FOP operator to specify the
maximum recovery attempts via fop.xconf? Is it worth dividing this into two
settings, one for page breaking, another for line breaking?
I'd prefer not to have non-configurable magic numbers of this sort if
possible.
Re: spurious indentation with (small) text lose
Posted by Vincent Hennebert <vh...@gmail.com>.
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<rs...@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
Re: spurious indentation with (small) text lose
Posted by Rob Sargent <rs...@xmission.com>.
Do we at least agree that there is a problem?
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<rs...@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
Re: spurious indentation with (small) text lose
Posted by Rob Sargent <rs...@xmission.com>.
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<rs...@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
>
Re: spurious indentation with (small) text lose
Posted by Rob Sargent <rs...@xmission.com>.
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 <rs...@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
Re: spurious indentation with (small) text lose
Posted by Pascal Sancho <ps...@gmail.com>.
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 <rs...@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
>
--
pascal