Re: page-number is stuttering

2012-08-09 Thread Rob Sargent 

Ever helpful. Thanks a ton.

The italics-outside-the-box is not an issue here, more a curiosity.  
I'll try other fonts to see what affect that has.


Now that I understand the value of the line numbers, I make good use of 
them by running from the commandline and trapping the output.  (I must 
turn down the logger though because fop1.1rc1-VH is generating 700Mb log 
files!)


I've drastically reduced the overflow, at least for the parts which I 
can control.  I had been using fixed height in certain components and 
these were involved in the vast majority of the overflow.  Since we are 
at a point in our process where clipping the content is no longer 
desirable I have removed the height restrictions (and overflow=hidden) 
and am much cleaner now.


In the parallel thread, "Spurious indentation with (small) text 
lose[sic]" you can find example fo with no over /except /for the 
region-body.  Unfortunately the affected region-body elements are not 
supposed to have any text.  My guess is that overflow is the fragment of 
data being lost.  I suspect also this same situation was in play with 
your patch.  Since I have removed the bulk of the overflow fop-1.0 still 
produces page-number stutters and that may still be as you point out due 
to the overflow - again on region-body elements which have zero sized.


My bet is that both my issues are tied to the same flaw, with apparently 
separate manifestations.


Welcome home :)

rjs


On 08/09/2012 01:18 PM, Vincent Hennebert wrote:

Fix committed in rev. 1371386:
http://svn.apache.org/viewvc?rev=1371386&view=rev

See also Bugzilla 53688: 
https://issues.apache.org/bugzilla/show_bug.cgi?id=53688

As to your other questions:

On 20/07/12 22:49, Rob Sargent wrote:

Saint Vincent, you deliver us again. The patch works on the original fo! (One
vote from here for committing the patch)

About the overflow:

  * All the incidents I've looked at are in the captions under the
header or in the page header.  Would overflow in these static
regions the cause of the page stutter?

No. The stutter was caused by an overflow in the region-body.



  * Said captions are rendered in font-style="italic".  Placing a border
around the image captions I find that the slant forces the bottom of
the first letter of each line outside the border. Is this not a bug?
For instance if I had another element abutting the caption, the
first letter of each line would overlap that abutting element.

Difficult to tell without having the font. There might be a bug in
reading the font metrics, but it’s more probable that the glyph’s
outline sticks out of the bounding box. In other words, that the glyph
is bigger than it pretends to be. A solution could be to add some
padding to the element that has the border.



  * The border on the caption does get clipped (2/3 of the time the
sides and the bottom does not appear in the printout), but I'm at a
loss to see why.  There's plenty of room according to what is shown
if I add a background colour to the caption text block and a
different colour for the static region.

I’m not sure what you are referring to. You may want to mention this
issue in a new thread (if you haven’t already done so).



  * Btw, when running the application in IntelliJ all the overflow
messages show as being at position(-1, -1), so that was rather
confusing.

This is probably because you pipe the result of the XSLT straight to
FOP, without saving it to a file. In that case there is no information
about line and column. If you save it to a file and format it nicely,
then you will get useful information about the locations of problems.

HTH,
Vincent



And another definitions of overflow: the log of my full-chapter fo was 450M!


On 07/20/2012 04:37 AM, Vincent Hennebert wrote:

I've run out of the time I can allocate to this issue I'm afraid. I have
a fix but it needs to be cleaned up and tested.

The best way to avoid the problem is to fix all the overflow warnings
that you are getting. You probably want to fix them anyway since it may
lead to a better output.

If constraints prevent you from fixing them all, then you can try the
attached patch against the latest trunk. It should be fairly safe in the
sense that it doesn't modify the layout engine's behaviour, only the
overflow reporting mechanism. That said, it's untested and unsupported
:-)

In the future, one thing that would be of great help when you submit FO
files would be to replace all the custom fonts with the default ones:
serif, sans-serif, monospace. That will avoid a lot of noise in the
warnings, but most of all allow us to reproduce the exact same layout as
you have.


Thanks,
Vincent


On 19/07/12 22:09, Rob Sargent wrote:

A prince you are!

I do have many of those messages, some are very regular (same 7200pt overflow)
and must be from a repeated element.  Others are more varied are hence more
likely to be in the flow perhaps? Since as you point out they are not page
n

Re: page-number is stuttering

2012-08-09 Thread Vincent Hennebert 
Fix committed in rev. 1371386:
http://svn.apache.org/viewvc?rev=1371386&view=rev

See also Bugzilla 53688: 
https://issues.apache.org/bugzilla/show_bug.cgi?id=53688

As to your other questions:

On 20/07/12 22:49, Rob Sargent wrote:
> Saint Vincent, you deliver us again. The patch works on the original fo! (One
> vote from here for committing the patch)
> 
> About the overflow:
> 
>  * All the incidents I've looked at are in the captions under the
>header or in the page header.  Would overflow in these static
>regions the cause of the page stutter?

No. The stutter was caused by an overflow in the region-body.


>  * Said captions are rendered in font-style="italic".  Placing a border
>around the image captions I find that the slant forces the bottom of
>the first letter of each line outside the border. Is this not a bug?
>For instance if I had another element abutting the caption, the
>first letter of each line would overlap that abutting element.

Difficult to tell without having the font. There might be a bug in
reading the font metrics, but it’s more probable that the glyph’s
outline sticks out of the bounding box. In other words, that the glyph
is bigger than it pretends to be. A solution could be to add some
padding to the element that has the border.


>  * The border on the caption does get clipped (2/3 of the time the
>sides and the bottom does not appear in the printout), but I'm at a
>loss to see why.  There's plenty of room according to what is shown
>if I add a background colour to the caption text block and a
>different colour for the static region.

I’m not sure what you are referring to. You may want to mention this
issue in a new thread (if you haven’t already done so).


>  * Btw, when running the application in IntelliJ all the overflow
>messages show as being at position(-1, -1), so that was rather
>confusing.

This is probably because you pipe the result of the XSLT straight to
FOP, without saving it to a file. In that case there is no information
about line and column. If you save it to a file and format it nicely,
then you will get useful information about the locations of problems.

HTH,
Vincent


> And another definitions of overflow: the log of my full-chapter fo was 450M!
> 
> 
> On 07/20/2012 04:37 AM, Vincent Hennebert wrote:
>> I've run out of the time I can allocate to this issue I'm afraid. I have
>> a fix but it needs to be cleaned up and tested.
>>
>> The best way to avoid the problem is to fix all the overflow warnings
>> that you are getting. You probably want to fix them anyway since it may
>> lead to a better output.
>>
>> If constraints prevent you from fixing them all, then you can try the
>> attached patch against the latest trunk. It should be fairly safe in the
>> sense that it doesn't modify the layout engine's behaviour, only the
>> overflow reporting mechanism. That said, it's untested and unsupported
>> :-)
>>
>> In the future, one thing that would be of great help when you submit FO
>> files would be to replace all the custom fonts with the default ones:
>> serif, sans-serif, monospace. That will avoid a lot of noise in the
>> warnings, but most of all allow us to reproduce the exact same layout as
>> you have.
>>
>>
>> Thanks,
>> Vincent
>>
>>
>> On 19/07/12 22:09, Rob Sargent wrote:
>>> A prince you are!
>>>
>>> I do have many of those messages, some are very regular (same 7200pt 
>>> overflow)
>>> and must be from a repeated element.  Others are more varied are hence more
>>> likely to be in the flow perhaps? Since as you point out they are not page
>>> numbers, is there anything I can do, e.g. command line params, debug levels 
>>> to
>>> help me pin-point the errant content?
>>>
>>> Counting this one as under control, I still have one more issue for which I
>>> think there is an page break problem.  Still working on a small repeatable
>>> offender.
>>>
>>> Cheers,
>>>
>>> rjs
>>>
>>>
>>>
>>>
>>> On 07/19/2012 02:26 PM, Vincent Hennebert wrote:
 Hi Rob,

 Thanks for your efforts to reduce the size of the FO file, this is
 really appreciated.

 I believe I found the problem, but need to investigate a bit more. In
 the meantime, try to modify the content so that it doesn't overflow the
 page. Watch for messages saying 'Content overflows the viewport of the
 fo:region-body on page n'. Except that 'n' is not the page number... but
 the column number!

 If you can avoid page overflows, you should avoid triggering the issue
 and get appropriate page numbers.

 HTH,
 Vincent


 On 19/07/12 20:33, Rob Sargent wrote:
> I have whittled the fo down further (shorter-fop.xml, now 35%) of 
> original,
> but this is as small as I can go to reproduce the exact 3-page stutter. 
> I can
> remover one more page and get a single stutter (shortest-fop.xml)
>
> I pray this will be enough.
>
> Thanks a bunch.
>
>

Re: page-number is stuttering

2012-07-20 Thread Rob Sargent 
Saint Vincent, you deliver us again. The patch works on the original fo! 
(One vote from here for committing the patch)


About the overflow:

 * All the incidents I've looked at are in the captions under the
   header or in the page header.  Would overflow in these static
   regions the cause of the page stutter?
 * Said captions are rendered in font-style="italic".  Placing a border
   around the image captions I find that the slant forces the bottom of
   the first letter of each line outside the border. Is this not a bug?
   For instance if I had another element abutting the caption, the
   first letter of each line would overlap that abutting element.
 * The border on the caption does get clipped (2/3 of the time the
   sides and the bottom does not appear in the printout), but I'm at a
   loss to see why.  There's plenty of room according to what is shown
   if I add a background colour to the caption text block and a
   different colour for the static region.
 * Btw, when running the application in IntelliJ all the overflow
   messages show as being at position(-1, -1), so that was rather
   confusing.

And another definitions of overflow: the log of my full-chapter fo was 450M!


On 07/20/2012 04:37 AM, Vincent Hennebert wrote:

I've run out of the time I can allocate to this issue I'm afraid. I have
a fix but it needs to be cleaned up and tested.

The best way to avoid the problem is to fix all the overflow warnings
that you are getting. You probably want to fix them anyway since it may
lead to a better output.

If constraints prevent you from fixing them all, then you can try the
attached patch against the latest trunk. It should be fairly safe in the
sense that it doesn't modify the layout engine's behaviour, only the
overflow reporting mechanism. That said, it's untested and unsupported
:-)

In the future, one thing that would be of great help when you submit FO
files would be to replace all the custom fonts with the default ones:
serif, sans-serif, monospace. That will avoid a lot of noise in the
warnings, but most of all allow us to reproduce the exact same layout as
you have.


Thanks,
Vincent


On 19/07/12 22:09, Rob Sargent wrote:

A prince you are!

I do have many of those messages, some are very regular (same 7200pt overflow)
and must be from a repeated element.  Others are more varied are hence more
likely to be in the flow perhaps? Since as you point out they are not page
numbers, is there anything I can do, e.g. command line params, debug levels to
help me pin-point the errant content?

Counting this one as under control, I still have one more issue for which I
think there is an page break problem.  Still working on a small repeatable
offender.

Cheers,

rjs




On 07/19/2012 02:26 PM, Vincent Hennebert wrote:

Hi Rob,

Thanks for your efforts to reduce the size of the FO file, this is
really appreciated.

I believe I found the problem, but need to investigate a bit more. In
the meantime, try to modify the content so that it doesn't overflow the
page. Watch for messages saying 'Content overflows the viewport of the
fo:region-body on page n'. Except that 'n' is not the page number... but
the column number!

If you can avoid page overflows, you should avoid triggering the issue
and get appropriate page numbers.

HTH,
Vincent


On 19/07/12 20:33, Rob Sargent wrote:

I have whittled the fo down further (shorter-fop.xml, now 35%) of original,
but this is as small as I can go to reproduce the exact 3-page stutter.  I can
remover one more page and get a single stutter (shortest-fop.xml)

I pray this will be enough.

Thanks a bunch.


On 07/19/2012 12:51 PM, Rob Sargent wrote:

I truly regret the large fo;  I know it hampers things at debug time.  I had
to find a particular starting point such that the content was still aligned
with the original placements.  I'll try to trim more pages from after the
page numbering problem.

rjs


On 07/19/2012 01:31 AM, Pascal Sancho wrote:

Hi,

To be efficient, a short fo helping to reproduce the issue should be
attached to the bug entry, so opening a bug rather than ask on this
list doesn't help anymore if the material remains the same.
I (or somebody else) have to look closer into the fo you attached
here,  then perhaps I (or somebody else) will, or will not, find a bug
causing this issue. Since the use case is quite big, that will take
some extra time :/

2012/7/18 Rob Sargent :

My apologies, but I've been unable to shrink this to a small test.  I'm
forced to send a rather large fo, but that's my level of desperation. Or
should I open a bug report?

rjs




On 07/12/2012 09:20 AM, Rob Sargent wrote:

I will do my best, but I see nothing in the generated fo that strikes me as
suspicious.

See other post on not getting identical output from commandline, which is
hampering generating reliable tests.

Anecdote:  prior to the 3 pages of stutter there are three pages (correctly
numbered) which have no text (entirely region-before), so this may also be
relate

Re: page-number is stuttering

2012-07-20 Thread Rob Sargent 

Thanks for all your efforts.

Will test your patch, deploy if happiness abounds.

I'm sorry about the custom fonts.  Trouble is pulling them out will in 
many cases changing the font can cause shake in the text layout and undo 
the problem one is trying to report.  Would it be possible to include 
fonts when necessary?


rjs

On 07/20/2012 04:37 AM, Vincent Hennebert wrote:

I've run out of the time I can allocate to this issue I'm afraid. I have
a fix but it needs to be cleaned up and tested.

The best way to avoid the problem is to fix all the overflow warnings
that you are getting. You probably want to fix them anyway since it may
lead to a better output.

If constraints prevent you from fixing them all, then you can try the
attached patch against the latest trunk. It should be fairly safe in the
sense that it doesn't modify the layout engine's behaviour, only the
overflow reporting mechanism. That said, it's untested and unsupported
:-)

In the future, one thing that would be of great help when you submit FO
files would be to replace all the custom fonts with the default ones:
serif, sans-serif, monospace. That will avoid a lot of noise in the
warnings, but most of all allow us to reproduce the exact same layout as
you have.


Thanks,
Vincent


On 19/07/12 22:09, Rob Sargent wrote:

A prince you are!

I do have many of those messages, some are very regular (same 7200pt overflow)
and must be from a repeated element.  Others are more varied are hence more
likely to be in the flow perhaps? Since as you point out they are not page
numbers, is there anything I can do, e.g. command line params, debug levels to
help me pin-point the errant content?

Counting this one as under control, I still have one more issue for which I
think there is an page break problem.  Still working on a small repeatable
offender.

Cheers,

rjs




On 07/19/2012 02:26 PM, Vincent Hennebert wrote:

Hi Rob,

Thanks for your efforts to reduce the size of the FO file, this is
really appreciated.

I believe I found the problem, but need to investigate a bit more. In
the meantime, try to modify the content so that it doesn't overflow the
page. Watch for messages saying 'Content overflows the viewport of the
fo:region-body on page n'. Except that 'n' is not the page number... but
the column number!

If you can avoid page overflows, you should avoid triggering the issue
and get appropriate page numbers.

HTH,
Vincent


On 19/07/12 20:33, Rob Sargent wrote:

I have whittled the fo down further (shorter-fop.xml, now 35%) of original,
but this is as small as I can go to reproduce the exact 3-page stutter.  I can
remover one more page and get a single stutter (shortest-fop.xml)

I pray this will be enough.

Thanks a bunch.


On 07/19/2012 12:51 PM, Rob Sargent wrote:

I truly regret the large fo;  I know it hampers things at debug time.  I had
to find a particular starting point such that the content was still aligned
with the original placements.  I'll try to trim more pages from after the
page numbering problem.

rjs


On 07/19/2012 01:31 AM, Pascal Sancho wrote:

Hi,

To be efficient, a short fo helping to reproduce the issue should be
attached to the bug entry, so opening a bug rather than ask on this
list doesn't help anymore if the material remains the same.
I (or somebody else) have to look closer into the fo you attached
here,  then perhaps I (or somebody else) will, or will not, find a bug
causing this issue. Since the use case is quite big, that will take
some extra time :/

2012/7/18 Rob Sargent :

My apologies, but I've been unable to shrink this to a small test.  I'm
forced to send a rather large fo, but that's my level of desperation. Or
should I open a bug report?

rjs




On 07/12/2012 09:20 AM, Rob Sargent wrote:

I will do my best, but I see nothing in the generated fo that strikes me as
suspicious.

See other post on not getting identical output from commandline, which is
hampering generating reliable tests.

Anecdote:  prior to the 3 pages of stutter there are three pages (correctly
numbered) which have no text (entirely region-before), so this may also be
related to issue

If you're anxious for an example, I can certainly post the 40-page chapter
fo but the last one made Vincent um, er, grumpy :).

rjs

On 07/12/2012 02:35 AM, Pascal Sancho wrote:

Hi,

One needs to see what there is in the XSL-FO (XML + XSLT transfo
result) fed to FOP.
Can you have a look on it, or provide a minimal version of it, so one
can reproduce the described issue?

2012/7/11 Rob Sargent :

In the middle of my document that page numbering goes 19, 20, 24,24,24,24,
25.  Further more the table-of-contents generated by
fo:page-number-citation
uses the bogus 24s for elements on actual page 21,23.

Anyone seen this before?  Hints on rooting out the cause?

FOP-1.0

rjs


-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: fop-users-h..

Re: page-number is stuttering

2012-07-20 Thread Vincent Hennebert 
I’ve run out of the time I can allocate to this issue I’m afraid. I have
a fix but it needs to be cleaned up and tested.

The best way to avoid the problem is to fix all the overflow warnings
that you are getting. You probably want to fix them anyway since it may
lead to a better output.

If constraints prevent you from fixing them all, then you can try the
attached patch against the latest trunk. It should be fairly safe in the
sense that it doesn’t modify the layout engine’s behaviour, only the
overflow reporting mechanism. That said, it’s untested and unsupported
:-)

In the future, one thing that would be of great help when you submit FO
files would be to replace all the custom fonts with the default ones:
serif, sans-serif, monospace. That will avoid a lot of noise in the
warnings, but most of all allow us to reproduce the exact same layout as
you have.


Thanks,
Vincent


On 19/07/12 22:09, Rob Sargent wrote:
> A prince you are!
> 
> I do have many of those messages, some are very regular (same 7200pt overflow)
> and must be from a repeated element.  Others are more varied are hence more
> likely to be in the flow perhaps? Since as you point out they are not page
> numbers, is there anything I can do, e.g. command line params, debug levels to
> help me pin-point the errant content?
> 
> Counting this one as under control, I still have one more issue for which I
> think there is an page break problem.  Still working on a small repeatable
> offender.
> 
> Cheers,
> 
> rjs
> 
> 
> 
> 
> On 07/19/2012 02:26 PM, Vincent Hennebert wrote:
>> Hi Rob,
>>
>> Thanks for your efforts to reduce the size of the FO file, this is
>> really appreciated.
>>
>> I believe I found the problem, but need to investigate a bit more. In
>> the meantime, try to modify the content so that it doesn’t overflow the
>> page. Watch for messages saying ‘Content overflows the viewport of the
>> fo:region-body on page n’. Except that ‘n’ is not the page number... but
>> the column number!
>>
>> If you can avoid page overflows, you should avoid triggering the issue
>> and get appropriate page numbers.
>>
>> HTH,
>> Vincent
>>
>>
>> On 19/07/12 20:33, Rob Sargent wrote:
>>> I have whittled the fo down further (shorter-fop.xml, now 35%) of original,
>>> but this is as small as I can go to reproduce the exact 3-page stutter.  I 
>>> can
>>> remover one more page and get a single stutter (shortest-fop.xml)
>>>
>>> I pray this will be enough.
>>>
>>> Thanks a bunch.
>>>
>>>
>>> On 07/19/2012 12:51 PM, Rob Sargent wrote:
 I truly regret the large fo;  I know it hampers things at debug time.  I 
 had
 to find a particular starting point such that the content was still aligned
 with the original placements.  I'll try to trim more pages from after the
 page numbering problem.

 rjs


 On 07/19/2012 01:31 AM, Pascal Sancho wrote:
> Hi,
>
> To be efficient, a short fo helping to reproduce the issue should be
> attached to the bug entry, so opening a bug rather than ask on this
> list doesn't help anymore if the material remains the same.
> I (or somebody else) have to look closer into the fo you attached
> here,  then perhaps I (or somebody else) will, or will not, find a bug
> causing this issue. Since the use case is quite big, that will take
> some extra time :/
>
> 2012/7/18 Rob Sargent :
>> My apologies, but I've been unable to shrink this to a small test.  I'm
>> forced to send a rather large fo, but that's my level of desperation. Or
>> should I open a bug report?
>>
>> rjs
>>
>>
>>
>>
>> On 07/12/2012 09:20 AM, Rob Sargent wrote:
>>
>> I will do my best, but I see nothing in the generated fo that strikes me 
>> as
>> suspicious.
>>
>> See other post on not getting identical output from commandline, which is
>> hampering generating reliable tests.
>>
>> Anecdote:  prior to the 3 pages of stutter there are three pages 
>> (correctly
>> numbered) which have no text (entirely region-before), so this may also 
>> be
>> related to issue
>>
>> If you're anxious for an example, I can certainly post the 40-page 
>> chapter
>> fo but the last one made Vincent um, er, grumpy :).
>>
>> rjs
>>
>> On 07/12/2012 02:35 AM, Pascal Sancho wrote:
>>
>> Hi,
>>
>> One needs to see what there is in the XSL-FO (XML + XSLT transfo
>> result) fed to FOP.
>> Can you have a look on it, or provide a minimal version of it, so one
>> can reproduce the described issue?
>>
>> 2012/7/11 Rob Sargent :
>>
>> In the middle of my document that page numbering goes 19, 20, 
>> 24,24,24,24,
>> 25.  Further more the table-of-contents generated by
>> fo:page-number-citation
>> uses the bogus 24s for elements on actual page 21,23.
>>
>> Anyone seen this before?  Hints on rooting out the cause?
>>
>> FOP

Re: page-number is stuttering

2012-07-19 Thread Rob Sargent 

A prince you are!

I do have many of those messages, some are very regular (same 7200pt 
overflow) and must be from a repeated element.  Others are more varied 
are hence more likely to be in the flow perhaps? Since as you point out 
they are not page numbers, is there anything I can do, e.g. command line 
params, debug levels to help me pin-point the errant content?


Counting this one as under control, I still have one more issue for 
which I think there is an page break problem.  Still working on a small 
repeatable offender.


Cheers,

rjs




On 07/19/2012 02:26 PM, Vincent Hennebert wrote:

Hi Rob,

Thanks for your efforts to reduce the size of the FO file, this is
really appreciated.

I believe I found the problem, but need to investigate a bit more. In
the meantime, try to modify the content so that it doesn’t overflow the
page. Watch for messages saying ‘Content overflows the viewport of the
fo:region-body on page n’. Except that ‘n’ is not the page number... but
the column number!

If you can avoid page overflows, you should avoid triggering the issue
and get appropriate page numbers.

HTH,
Vincent


On 19/07/12 20:33, Rob Sargent wrote:

I have whittled the fo down further (shorter-fop.xml, now 35%) of original,
but this is as small as I can go to reproduce the exact 3-page stutter.  I can
remover one more page and get a single stutter (shortest-fop.xml)

I pray this will be enough.

Thanks a bunch.


On 07/19/2012 12:51 PM, Rob Sargent wrote:

I truly regret the large fo;  I know it hampers things at debug time.  I had
to find a particular starting point such that the content was still aligned
with the original placements.  I'll try to trim more pages from after the
page numbering problem.

rjs


On 07/19/2012 01:31 AM, Pascal Sancho wrote:

Hi,

To be efficient, a short fo helping to reproduce the issue should be
attached to the bug entry, so opening a bug rather than ask on this
list doesn't help anymore if the material remains the same.
I (or somebody else) have to look closer into the fo you attached
here,  then perhaps I (or somebody else) will, or will not, find a bug
causing this issue. Since the use case is quite big, that will take
some extra time :/

2012/7/18 Rob Sargent :

My apologies, but I've been unable to shrink this to a small test.  I'm
forced to send a rather large fo, but that's my level of desperation. Or
should I open a bug report?

rjs




On 07/12/2012 09:20 AM, Rob Sargent wrote:

I will do my best, but I see nothing in the generated fo that strikes me as
suspicious.

See other post on not getting identical output from commandline, which is
hampering generating reliable tests.

Anecdote:  prior to the 3 pages of stutter there are three pages (correctly
numbered) which have no text (entirely region-before), so this may also be
related to issue

If you're anxious for an example, I can certainly post the 40-page chapter
fo but the last one made Vincent um, er, grumpy :).

rjs

On 07/12/2012 02:35 AM, Pascal Sancho wrote:

Hi,

One needs to see what there is in the XSL-FO (XML + XSLT transfo
result) fed to FOP.
Can you have a look on it, or provide a minimal version of it, so one
can reproduce the described issue?

2012/7/11 Rob Sargent :

In the middle of my document that page numbering goes 19, 20, 24,24,24,24,
25.  Further more the table-of-contents generated by fo:page-number-citation
uses the bogus 24s for elements on actual page 21,23.

Anyone seen this before?  Hints on rooting out the cause?

FOP-1.0

rjs


-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]





-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]




-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Re: page-number is stuttering

2012-07-19 Thread Vincent Hennebert 
Hi Rob,

Thanks for your efforts to reduce the size of the FO file, this is
really appreciated.

I believe I found the problem, but need to investigate a bit more. In
the meantime, try to modify the content so that it doesn’t overflow the
page. Watch for messages saying ‘Content overflows the viewport of the
fo:region-body on page n’. Except that ‘n’ is not the page number... but
the column number!

If you can avoid page overflows, you should avoid triggering the issue
and get appropriate page numbers.

HTH,
Vincent


On 19/07/12 20:33, Rob Sargent wrote:
> I have whittled the fo down further (shorter-fop.xml, now 35%) of original,
> but this is as small as I can go to reproduce the exact 3-page stutter.  I can
> remover one more page and get a single stutter (shortest-fop.xml)
> 
> I pray this will be enough.
> 
> Thanks a bunch.
> 
> 
> On 07/19/2012 12:51 PM, Rob Sargent wrote:
>> I truly regret the large fo;  I know it hampers things at debug time.  I had
>> to find a particular starting point such that the content was still aligned
>> with the original placements.  I'll try to trim more pages from after the
>> page numbering problem.
>>
>> rjs
>>
>>
>> On 07/19/2012 01:31 AM, Pascal Sancho wrote:
>>> Hi,
>>>
>>> To be efficient, a short fo helping to reproduce the issue should be
>>> attached to the bug entry, so opening a bug rather than ask on this
>>> list doesn't help anymore if the material remains the same.
>>> I (or somebody else) have to look closer into the fo you attached
>>> here,  then perhaps I (or somebody else) will, or will not, find a bug
>>> causing this issue. Since the use case is quite big, that will take
>>> some extra time :/
>>>
>>> 2012/7/18 Rob Sargent :
 My apologies, but I've been unable to shrink this to a small test.  I'm
 forced to send a rather large fo, but that's my level of desperation. Or
 should I open a bug report?

 rjs




 On 07/12/2012 09:20 AM, Rob Sargent wrote:

 I will do my best, but I see nothing in the generated fo that strikes me as
 suspicious.

 See other post on not getting identical output from commandline, which is
 hampering generating reliable tests.

 Anecdote:  prior to the 3 pages of stutter there are three pages (correctly
 numbered) which have no text (entirely region-before), so this may also be
 related to issue

 If you're anxious for an example, I can certainly post the 40-page chapter
 fo but the last one made Vincent um, er, grumpy :).

 rjs

 On 07/12/2012 02:35 AM, Pascal Sancho wrote:

 Hi,

 One needs to see what there is in the XSL-FO (XML + XSLT transfo
 result) fed to FOP.
 Can you have a look on it, or provide a minimal version of it, so one
 can reproduce the described issue?

 2012/7/11 Rob Sargent :

 In the middle of my document that page numbering goes 19, 20, 24,24,24,24,
 25.  Further more the table-of-contents generated by 
 fo:page-number-citation
 uses the bogus 24s for elements on actual page 21,23.

 Anyone seen this before?  Hints on rooting out the cause?

 FOP-1.0

 rjs
>>
>>
>> -
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 


-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Re: page-number is stuttering

2012-07-19 Thread Rob Sargent 
I truly regret the large fo;  I know it hampers things at debug time.  I 
had to find a particular starting point such that the content was still 
aligned with the original placements.  I'll try to trim more pages from 
after the page numbering problem.


rjs


On 07/19/2012 01:31 AM, Pascal Sancho wrote:

Hi,

To be efficient, a short fo helping to reproduce the issue should be
attached to the bug entry, so opening a bug rather than ask on this
list doesn't help anymore if the material remains the same.
I (or somebody else) have to look closer into the fo you attached
here,  then perhaps I (or somebody else) will, or will not, find a bug
causing this issue. Since the use case is quite big, that will take
some extra time :/

2012/7/18 Rob Sargent :

My apologies, but I've been unable to shrink this to a small test.  I'm
forced to send a rather large fo, but that's my level of desperation. Or
should I open a bug report?

rjs




On 07/12/2012 09:20 AM, Rob Sargent wrote:

I will do my best, but I see nothing in the generated fo that strikes me as
suspicious.

See other post on not getting identical output from commandline, which is
hampering generating reliable tests.

Anecdote:  prior to the 3 pages of stutter there are three pages (correctly
numbered) which have no text (entirely region-before), so this may also be
related to issue

If you're anxious for an example, I can certainly post the 40-page chapter
fo but the last one made Vincent um, er, grumpy :).

rjs

On 07/12/2012 02:35 AM, Pascal Sancho wrote:

Hi,

One needs to see what there is in the XSL-FO (XML + XSLT transfo
result) fed to FOP.
Can you have a look on it, or provide a minimal version of it, so one
can reproduce the described issue?

2012/7/11 Rob Sargent :

In the middle of my document that page numbering goes 19, 20, 24,24,24,24,
25.  Further more the table-of-contents generated by fo:page-number-citation
uses the bogus 24s for elements on actual page 21,23.

Anyone seen this before?  Hints on rooting out the cause?

FOP-1.0

rjs



-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Re: page-number is stuttering

2012-07-19 Thread Pascal Sancho 
Hi,

To be efficient, a short fo helping to reproduce the issue should be
attached to the bug entry, so opening a bug rather than ask on this
list doesn't help anymore if the material remains the same.
I (or somebody else) have to look closer into the fo you attached
here,  then perhaps I (or somebody else) will, or will not, find a bug
causing this issue. Since the use case is quite big, that will take
some extra time :/

2012/7/18 Rob Sargent :
> My apologies, but I've been unable to shrink this to a small test.  I'm
> forced to send a rather large fo, but that's my level of desperation. Or
> should I open a bug report?
>
> rjs
>
>
>
>
> On 07/12/2012 09:20 AM, Rob Sargent wrote:
>
> I will do my best, but I see nothing in the generated fo that strikes me as
> suspicious.
>
> See other post on not getting identical output from commandline, which is
> hampering generating reliable tests.
>
> Anecdote:  prior to the 3 pages of stutter there are three pages (correctly
> numbered) which have no text (entirely region-before), so this may also be
> related to issue
>
> If you're anxious for an example, I can certainly post the 40-page chapter
> fo but the last one made Vincent um, er, grumpy :).
>
> rjs
>
> On 07/12/2012 02:35 AM, Pascal Sancho wrote:
>
> Hi,
>
> One needs to see what there is in the XSL-FO (XML + XSLT transfo
> result) fed to FOP.
> Can you have a look on it, or provide a minimal version of it, so one
> can reproduce the described issue?
>
> 2012/7/11 Rob Sargent :
>
> In the middle of my document that page numbering goes 19, 20, 24,24,24,24,
> 25.  Further more the table-of-contents generated by fo:page-number-citation
> uses the bogus 24s for elements on actual page 21,23.
>
> Anyone seen this before?  Hints on rooting out the cause?
>
> FOP-1.0
>
> rjs

-- 
pascal

-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Re: page-number is stuttering

2012-07-12 Thread Rob Sargent 
I will do my best, but I see nothing in the generated fo that strikes me 
as suspicious.


See other post 
 
on not getting identical output from commandline, which is hampering 
generating reliable tests.


Anecdote:  prior to the 3 pages of stutter there are three pages 
(correctly numbered) which have no text (entirely region-before), so 
this may also be related to issue 



If you're anxious for an example, I can certainly post the 40-page 
chapter fobut the last one made Vincent um, er, grumpy :).


rjs

On 07/12/2012 02:35 AM, Pascal Sancho wrote:

Hi,

One needs to see what there is in the XSL-FO (XML + XSLT transfo
result) fed to FOP.
Can you have a look on it, or provide a minimal version of it, so one
can reproduce the described issue?

2012/7/11 Rob Sargent :

In the middle of my document that page numbering goes 19, 20, 24,24,24,24,
25.  Further more the table-of-contents generated by fo:page-number-citation
uses the bogus 24s for elements on actual page 21,23.

Anyone seen this before?  Hints on rooting out the cause?

FOP-1.0

rjs

Re: page-number is stuttering

2012-07-12 Thread Pascal Sancho 
Hi,

One needs to see what there is in the XSL-FO (XML + XSLT transfo
result) fed to FOP.
Can you have a look on it, or provide a minimal version of it, so one
can reproduce the described issue?

2012/7/11 Rob Sargent :
> In the middle of my document that page numbering goes 19, 20, 24,24,24,24,
> 25.  Further more the table-of-contents generated by fo:page-number-citation
> uses the bogus 24s for elements on actual page 21,23.
>
> Anyone seen this before?  Hints on rooting out the cause?
>
> FOP-1.0
>
> rjs


-- 
pascal

-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]