DO NOT REPLY [Bug 33801] New: - FOP 0.20.5 AWTRenderer: Sometimes rendering fails in the middle of a table with no error message

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33801

   Summary: FOP 0.20.5 AWTRenderer: Sometimes rendering fails in the
middle of a table with no error message
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: major
  Priority: P2
 Component: awt renderer
AssignedTo: fop-dev@xml.apache.org
ReportedBy: [EMAIL PROTECTED]


My french team and I work on a Java project and we plan to embed FOP
0.20.5 for the needed print reports.

We experience a problem when we are using the AWT renderer with
documents that contain tables.  Sometimes, a page is "cut" in the
middle of a table and its header (fo:region-before) is missing.

As far as we have investigated we can say that:

* We have neither abnormal output message, nor exception stack
  trace.

* We only experience this problem with the AWT renderer.  Using
  the PCL renderer works fine (but it lacks multibyte characters
  support that is critical for some of our translated releases).

* We only experience this problem on a true printer (we have tried
  several models from HP and OKI).  We never reproduced the
  problem using a fake printer such as Adobe Acrobat Distiller.

* With the FO document (bug.fo) that is attached, we experience
  the problem 20% of the time when launching the printing from our
  application (we tried both java.awt.print and javax.print APIs).

  When using the `fop.bat' script, we experience the problem 100%
  of the time with the same FO document.

  fop.bat -fo bug.fo -print

  We tried JDK 1.4.1_07 and 1.4.2_07.

* So far, 100% of the time it happened, tables were involved in
  the document.

* Using the same FO document and the same FOP command line several
  times may result in having the bug occuring on different pages
  of the document.  The printing does not fail systematically at
  the same point of the document.


I have attached:

You can download http://www.guillaumeponce.org/fop/bug.fo.zip

The reference FO document we have used to investigate this
problem (zipped).


You can also download http://www.guillaumeponce.org/fop/bug.pdf

It is 12 Mb large.  It is an actual 8 pages long paper print
that has been scanned.  You can see that the problemI
describe occured on page 7 out of 8.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 33801] - FOP 0.20.5 AWTRenderer: Sometimes rendering fails in the middle of a table with no error message

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33801





--- Additional Comments From [EMAIL PROTECTED]  2005-03-02 10:11 ---
Created an attachment (id=14386)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14386&action=view)
Test case for the bug

fop.bat -fo bug.fo -print
Rendering should fail.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: page-breaking strategies and performance

[Chris Bowditch]

Jeremias Maerki wrote:
Hi Jeremias,
I finally have Knuth's "Digital Typography" and let myself enlighten by
his well-written words. In [1] Simon outlined different strategies for
page-breaking, obviously closely following the different approaches
defined by Knuth. At first glance, I'd say that "best-fit" is probably
the obvious strategy to select, especially if TeX is happy with it.
Obviously, it can't find the optimal solution like this but the
additional overhead (memory and CPU power) of a look-ahead/total-fit
strategy is simply too much and unnecessary for things like invoices and
insurance policies which are surely some of the most popular use cases
of XSL-FO. Here, speed is extremely important. People writing
documentation (maybe using DocBook) or glossy stock reports have
additional requirements and don't mind the longer processing time and
additional memory requirements. This leads me to the question if we
shouldn't actually implement two page-breaking strategies (in the end,
not both right now). For a speed-optimized algorithm, we could even
think about ignoring side-floats.
We have dozens of customers using an XSL-FO solution and I can confirm 
invoices and insurance policies are a common use case for XSL-FO. A lot of 
companies have performance as a priority and we have no one using side floats 
or even thinking about using them, so optimizing for speed by ignoring side 
floats sounds like a good idea! But this is just my 2 cents and may conflict 
with other people's wishes.

Obviously, in this model we would have to make sure that we use a common
model for both strategies. For example, we still have to make sure that
the line layout gets information on the available IPD on each line, but
probably this will not be a big problem to include later.
An enhanced/adjusted box/glue/penalty model sounds like a good idea to
me especially since Knuth hints at that in his book, too. There's also a
question if part of the infrastructure from line breaking can be reused
for page breaking, but I guess rather not.
Probably best to re-create an algorithm from scratch for page breaking but 
line breaking can be reviewed for ideas.

As for the plan to implement a new page-breaking mechanism: I've got to
do it now. :-) I'm sorry if this may put some pressure on some of you.
I'm also not sure if I'm fit already to tackle it, but I've got to
do it anyway. Since I don't want to work with a series of patches like
you guys did earlier, I'd like to create a branch to do that on as soon
as we've agreed on a strategy. Any objections to that?
If we are going to branch the code for this then we need to make sure we have 
a plan to merge the branch back once we are confident in the new page breaking 
algorithm. This plan (which should be agreed before branching takes place) 
should include an acceptance procedure, e.g. will a single -1 be able to 
prevent the code being merged back? We dont want to end up with another 
alt-design, which eventually moved to source forge!!!

Chris

Re: page-breaking strategies and performance

[Glen Mazza]

--- Chris Bowditch <[EMAIL PROTECTED]> wrote:

> > 
> > As for the plan to implement a new page-breaking
> mechanism: I've got to
> > do it now. :-) I'm sorry if this may put some
> pressure on some of you.
> > I'm also not sure if I'm fit already to tackle it,
> but I've got to
> > do it anyway. Since I don't want to work with a
> series of patches like
> > you guys did earlier, I'd like to create a branch
> to do that on as soon
> > as we've agreed on a strategy. Any objections to
> that?
> 
> If we are going to branch the code for this then we
> need to make sure we have 
> a plan to merge the branch back once we are
> confident in the new page breaking 
> algorithm. This plan (which should be agreed before
> branching takes place) 
> should include an acceptance procedure, e.g. will a
> single -1 be able to 
> prevent the code being merged back? We dont want to
> end up with another 
> alt-design, which eventually moved to source
> forge!!!
> 
> Chris
> 

Either way is fine with me, but Chris brings up a very
valid point.  If you can tolerate and keep up with my
minor code housekeeping from time to time in some of
the layout managers (currently mostly PSLM), feel free
to work from HEAD directly instead if you wish.

Glen

DO NOT REPLY [Bug 33801] - FOP 0.20.5 AWTRenderer: Sometimes rendering fails in the middle of a table with no error message

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33801





--- Additional Comments From [EMAIL PROTECTED]  2005-03-02 13:39 ---
(In reply to comment #0)

I could also reproduce the bug using FOP 0.20.5 and the provided bug.fo. It
occured on page 2 out of 8.

> As far as we have investigated we can say that:
> 
> * We have neither abnormal output message, nor exception stack
>   trace.
Same here for me (also using the command line option -d)

> * We only experience this problem with the AWT renderer.  Using
>   the PCL renderer works fine (but it lacks multibyte characters
>   support that is critical for some of our translated releases).
Haven't tried it.
 
> * We only experience this problem on a true printer (we have tried
>   several models from HP and OKI).  We never reproduced the
>   problem using a fake printer such as Adobe Acrobat Distiller.
Same here: the output in the Window of the AWT-Renderer looks fine. Only at
printing comes a problem.

If you (FOP Team) suspect that the problem lies in the AWT-Renderer, I could try
to investigate.

HTH,
Renaud

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 33808] New: - problem with large number-rows-spanned

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33808

   Summary: problem with large number-rows-spanned
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: pdf renderer
AssignedTo: fop-dev@xml.apache.org
ReportedBy: [EMAIL PROTECTED]


I am experiencing trouble when trying to create a table with FOP.

My first table column has a number-rows-spanned that is larger than the
number of rows fitting on a page. This leads to several problems:

1. The cell border is drawn across the page footer (does not end with the
last table-row on the page, but is drawn into nowhere if you have even more
rows).
2. The cell border for the (continued) first cell on the next page is
missing completely.

3. An extra page is being added at the beginning of my document. (?!)

Whether there is a patch correcting this mistake ?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: page-breaking strategies and performance

[Jeremias Maerki]

I'd rather not work on HEAD directly because after creating the basics
for the new mechanism the whole thing will probably not work for some
time (probably 2-4 weeks). But I'd like to be able to check in early so
people can review. I expect that the life time of the branch will not
exceed 8 weeks. So there's almost no chance that alt-design is repeated,
especially since the basic LM infrastructure will not be altered big
time and it looks like we are all going in the same direction for the
new page-breaking. It's clear that it has to be done and it seems to be
moveing in the direction of a derived Knuth approach. It's much like the
migration to the Knuth line breaking and it's mostly the block-level LMs
that will be affected. People can continue to work on HEAD during that
time as long as nothing serious is altered in the block-level LMs which
would make merging difficult.

Before I can kick off we need to agree to the general approach for the
algorithm and clear a few details so we are reasonably sure that it'll
work. Once we have that the plan for the branch should not be a big deal
if we take the above into account.

On 02.03.2005 13:16:42 Glen Mazza wrote:
> 
> --- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> 
> > > 
> > > As for the plan to implement a new page-breaking
> > mechanism: I've got to
> > > do it now. :-) I'm sorry if this may put some
> > pressure on some of you.
> > > I'm also not sure if I'm fit already to tackle it,
> > but I've got to
> > > do it anyway. Since I don't want to work with a
> > series of patches like
> > > you guys did earlier, I'd like to create a branch
> > to do that on as soon
> > > as we've agreed on a strategy. Any objections to
> > that?
> > 
> > If we are going to branch the code for this then we
> > need to make sure we have 
> > a plan to merge the branch back once we are
> > confident in the new page breaking 
> > algorithm. This plan (which should be agreed before
> > branching takes place) 
> > should include an acceptance procedure, e.g. will a
> > single -1 be able to 
> > prevent the code being merged back? We dont want to
> > end up with another 
> > alt-design, which eventually moved to source
> > forge!!!
> > 
> > Chris
> > 
> 
> Either way is fine with me, but Chris brings up a very
> valid point.  If you can tolerate and keep up with my
> minor code housekeeping from time to time in some of
> the layout managers (currently mostly PSLM), feel free
> to work from HEAD directly instead if you wish.
> 
> Glen



Jeremias Maerki

Re: page-breaking strategies and performance

[Glen Mazza]

Just a sanity check here, the XSL specification seems
to suggest always the first-fit strategy for page
breaking *except* where keeps are explicitly
specified.  Am I correct here?  And, if so, is what
you're planning going to result in an algorithm that
will help us do this?

Thanks,
Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> I'd rather not work on HEAD directly because after
> creating the basics
> for the new mechanism the whole thing will probably
> not work for some
> time (probably 2-4 weeks). But I'd like to be able
> to check in early so
> people can review. I expect that the life time of
> the branch will not
> exceed 8 weeks. So there's almost no chance that
> alt-design is repeated,
> especially since the basic LM infrastructure will
> not be altered big
> time and it looks like we are all going in the same
> direction for the
> new page-breaking. It's clear that it has to be done
> and it seems to be
> moveing in the direction of a derived Knuth
> approach. It's much like the
> migration to the Knuth line breaking and it's mostly
> the block-level LMs
> that will be affected. People can continue to work
> on HEAD during that
> time as long as nothing serious is altered in the
> block-level LMs which
> would make merging difficult.
> 
> Before I can kick off we need to agree to the
> general approach for the
> algorithm and clear a few details so we are
> reasonably sure that it'll
> work. Once we have that the plan for the branch
> should not be a big deal
> if we take the above into account.
> 
> On 02.03.2005 13:16:42 Glen Mazza wrote:
> > 
> > --- Chris Bowditch <[EMAIL PROTECTED]>
> wrote:
> > 
> > > > 
> > > > As for the plan to implement a new
> page-breaking
> > > mechanism: I've got to
> > > > do it now. :-) I'm sorry if this may put some
> > > pressure on some of you.
> > > > I'm also not sure if I'm fit already to tackle
> it,
> > > but I've got to
> > > > do it anyway. Since I don't want to work with
> a
> > > series of patches like
> > > > you guys did earlier, I'd like to create a
> branch
> > > to do that on as soon
> > > > as we've agreed on a strategy. Any objections
> to
> > > that?
> > > 
> > > If we are going to branch the code for this then
> we
> > > need to make sure we have 
> > > a plan to merge the branch back once we are
> > > confident in the new page breaking 
> > > algorithm. This plan (which should be agreed
> before
> > > branching takes place) 
> > > should include an acceptance procedure, e.g.
> will a
> > > single -1 be able to 
> > > prevent the code being merged back? We dont want
> to
> > > end up with another 
> > > alt-design, which eventually moved to source
> > > forge!!!
> > > 
> > > Chris
> > > 
> > 
> > Either way is fine with me, but Chris brings up a
> very
> > valid point.  If you can tolerate and keep up with
> my
> > minor code housekeeping from time to time in some
> of
> > the layout managers (currently mostly PSLM), feel
> free
> > to work from HEAD directly instead if you wish.
> > 
> > Glen
> 
> 
> 
> Jeremias Maerki
> 
> 

Re: page-breaking strategies and performance

[Jeremias Maerki]

Where did you find such a suggestion? I'd be interested to know if
there's a hint in this direction in the spec. I thought it was up to the
implementation to decide the strategy.

I think the way we're now taking in our discussion suggests that we're
not going to do a first-fit strategy at all. If we're really going down
the two-strategy path we'll probably end up with a best-fit strategy and
a total-fit or best-fit plus look-ahead. (See Simon's list [1]) But
that's something we still need to figure out together.

[1] http://wiki.apache.org/xmlgraphics-fop/PageLayout

On 02.03.2005 14:48:17 Glen Mazza wrote:
> Just a sanity check here, the XSL specification seems
> to suggest always the first-fit strategy for page
> breaking *except* where keeps are explicitly
> specified.  Am I correct here?  And, if so, is what
> you're planning going to result in an algorithm that
> will help us do this?


Jeremias Maerki

Re: page-breaking strategies and performance

[Glen Mazza]

I'm unsure here.  My interpretation comes from two
places: 

1.) Section 4.8, the last paragraph of [1]:

"The area tree is constrained to satisfy all break
conditions imposed. ***Each keep condition must also
be satisfied***, except when this would cause a break
condition or a stronger keep condition to fail to be
satisfied."

i.e., keep conditions need to be satisfied.

2.) The definitions of the three keep-[] properties
[2] each have a initial value of "auto", meaning
"There are no keep-[] conditions imposed by this
property."

So by default, if the user does not explicitly specify
keep properties, e.g., "keep-together.within-page", no
text, pictures, etc. are to be kept together on the
same page, if they wouldn't already be so due to
free-flowing (i.e., first-fit) text.  Everything would
become free-flowing in order to obey the stylesheet
writer's specifications.

Just my $0.02.

Thanks,
Glen

[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#keepbreak

[2]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#keep-together


--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Where did you find such a suggestion? I'd be
> interested to know if
> there's a hint in this direction in the spec. I
> thought it was up to the
> implementation to decide the strategy.
> 
> I think the way we're now taking in our discussion
> suggests that we're
> not going to do a first-fit strategy at all. If
> we're really going down
> the two-strategy path we'll probably end up with a
> best-fit strategy and
> a total-fit or best-fit plus look-ahead. (See
> Simon's list [1]) But
> that's something we still need to figure out
> together.
> 

If we ever have multiple page-breaking options, it can
be a user-defined configuration switch.  No problem
there.

Glen


> [1]
> http://wiki.apache.org/xmlgraphics-fop/PageLayout
> 
> On 02.03.2005 14:48:17 Glen Mazza wrote:
> > Just a sanity check here, the XSL specification
> seems
> > to suggest always the first-fit strategy for page
> > breaking *except* where keeps are explicitly
> > specified.  Am I correct here?  And, if so, is
> what
> > you're planning going to result in an algorithm
> that
> > will help us do this?
> 
> 
> Jeremias Maerki
> 
> 

Re: page-breaking strategies and performance

[Jeremias Maerki]

Thanks. I think this has only to do with the rules to handle keeps and
breaks and how to resolve conflicts. I don't think, however, that these
parts create a restriction which tells us what page-breaking strategy to
pursue. We could probably run with a first-fit strategy and still
fulfill the rules below if we accept a lot of backtracking. But as Simon
suggested, this seems to be a poor approach.

Keeps and breaks are only part of what a page breaking algorithm has to
deal with. See [3].

[3] http://wiki.apache.org/xmlgraphics-fop/PageLayout/InfluencingFeatures

On 02.03.2005 16:44:17 Glen Mazza wrote:
> I'm unsure here.  My interpretation comes from two
> places: 
> 
> 1.) Section 4.8, the last paragraph of [1]:
> 
> "The area tree is constrained to satisfy all break
> conditions imposed. ***Each keep condition must also
> be satisfied***, except when this would cause a break
> condition or a stronger keep condition to fail to be
> satisfied."
> 
> i.e., keep conditions need to be satisfied.
> 
> 2.) The definitions of the three keep-[] properties
> [2] each have a initial value of "auto", meaning
> "There are no keep-[] conditions imposed by this
> property."
> 
> So by default, if the user does not explicitly specify
> keep properties, e.g., "keep-together.within-page", no
> text, pictures, etc. are to be kept together on the
> same page, if they wouldn't already be so due to
> free-flowing (i.e., first-fit) text.  Everything would
> become free-flowing in order to obey the stylesheet
> writer's specifications.
> 
> Just my $0.02.
> 
> Thanks,
> Glen
> 
> [1]
> http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#keepbreak
> 
> [2]
> http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#keep-together
> 
> 
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> > Where did you find such a suggestion? I'd be
> > interested to know if
> > there's a hint in this direction in the spec. I
> > thought it was up to the
> > implementation to decide the strategy.
> > 
> > I think the way we're now taking in our discussion
> > suggests that we're
> > not going to do a first-fit strategy at all. If
> > we're really going down
> > the two-strategy path we'll probably end up with a
> > best-fit strategy and
> > a total-fit or best-fit plus look-ahead. (See
> > Simon's list [1]) But
> > that's something we still need to figure out
> > together.
> > 
> 
> If we ever have multiple page-breaking options, it can
> be a user-defined configuration switch.  No problem
> there.
> 
> Glen
> 
> 
> > [1]
> > http://wiki.apache.org/xmlgraphics-fop/PageLayout
> > 
> > On 02.03.2005 14:48:17 Glen Mazza wrote:
> > > Just a sanity check here, the XSL specification
> > seems
> > > to suggest always the first-fit strategy for page
> > > breaking *except* where keeps are explicitly
> > > specified.  Am I correct here?  And, if so, is
> > what
> > > you're planning going to result in an algorithm
> > that
> > > will help us do this?
> > 
> > 
> > Jeremias Maerki
> > 
> > 



Jeremias Maerki

Re: page-breaking strategies and performance

[Glen Mazza]

Yes, I'm not in Simon's league here--I know very
little about TeX--so I'll defer to you two on this
issue.  Just try to make sure that the final algorithm
will help us support the keep-* properties.

Thanks,
Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Thanks. I think this has only to do with the rules
> to handle keeps and
> breaks and how to resolve conflicts. I don't think,
> however, that these
> parts create a restriction which tells us what
> page-breaking strategy to
> pursue. We could probably run with a first-fit
> strategy and still
> fulfill the rules below if we accept a lot of
> backtracking. But as Simon
> suggested, this seems to be a poor approach.
> 
> Keeps and breaks are only part of what a page
> breaking algorithm has to
> deal with. See [3].
> 
> [3]
>
http://wiki.apache.org/xmlgraphics-fop/PageLayout/InfluencingFeatures
> 
> On 02.03.2005 16:44:17 Glen Mazza wrote:
> > I'm unsure here.  My interpretation comes from two
> > places: 
> > 
> > 1.) Section 4.8, the last paragraph of [1]:
> > 
> > "The area tree is constrained to satisfy all break
> > conditions imposed. ***Each keep condition must
> also
> > be satisfied***, except when this would cause a
> break
> > condition or a stronger keep condition to fail to
> be
> > satisfied."
> > 
> > i.e., keep conditions need to be satisfied.
> > 
> > 2.) The definitions of the three keep-[]
> properties
> > [2] each have a initial value of "auto", meaning
> > "There are no keep-[] conditions imposed by this
> > property."
> > 
> > So by default, if the user does not explicitly
> specify
> > keep properties, e.g.,
> "keep-together.within-page", no
> > text, pictures, etc. are to be kept together on
> the
> > same page, if they wouldn't already be so due to
> > free-flowing (i.e., first-fit) text.  Everything
> would
> > become free-flowing in order to obey the
> stylesheet
> > writer's specifications.
> > 
> > Just my $0.02.
> > 
> > Thanks,
> > Glen
> > 
> > [1]
> >
>
http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#keepbreak
> > 
> > [2]
> >
>
http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#keep-together
> > 
> > 
> > --- Jeremias Maerki <[EMAIL PROTECTED]>
> wrote:
> > 
> > > Where did you find such a suggestion? I'd be
> > > interested to know if
> > > there's a hint in this direction in the spec. I
> > > thought it was up to the
> > > implementation to decide the strategy.
> > > 
> > > I think the way we're now taking in our
> discussion
> > > suggests that we're
> > > not going to do a first-fit strategy at all. If
> > > we're really going down
> > > the two-strategy path we'll probably end up with
> a
> > > best-fit strategy and
> > > a total-fit or best-fit plus look-ahead. (See
> > > Simon's list [1]) But
> > > that's something we still need to figure out
> > > together.
> > > 
> > 
> > If we ever have multiple page-breaking options, it
> can
> > be a user-defined configuration switch.  No
> problem
> > there.
> > 
> > Glen
> > 
> > 
> > > [1]
> > >
> http://wiki.apache.org/xmlgraphics-fop/PageLayout
> > > 
> > > On 02.03.2005 14:48:17 Glen Mazza wrote:
> > > > Just a sanity check here, the XSL
> specification
> > > seems
> > > > to suggest always the first-fit strategy for
> page
> > > > breaking *except* where keeps are explicitly
> > > > specified.  Am I correct here?  And, if so, is
> > > what
> > > > you're planning going to result in an
> algorithm
> > > that
> > > > will help us do this?
> > > 
> > > 
> > > Jeremias Maerki
> > > 
> > > 
> 
> 
> 
> Jeremias Maerki
> 
> 

Re: page-breaking strategies and performance

[Jeremias Maerki]

On 02.03.2005 17:05:55 Glen Mazza wrote:
> Yes, I'm not in Simon's league here--I know very
> little about TeX--so I'll defer to you two on this
> issue.

I'm also still struggling. :-)

>  Just try to make sure that the final algorithm
> will help us support the keep-* properties.

Yes, the algorithm MUST be able to handle full keep support (among other
things). That's part of why we need a new approach. The present one
doesn't quite fit the picture, yet. Thankfully, with the new design we
don't have to again rewrite the whole FOP. The present approach was very
good to point us in the right direction and most of the effort already
invested is not lost. We just have to improve a specific part.

Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Simon Pepping]

On Tue, Mar 01, 2005 at 09:15:37PM -0800, Glen Mazza wrote:
> OH!!!   
> 
> Yes, you're right, Chris--now I see the issue.  I
> implemented validation for about 80% of the FOs, but
> 80% is not 100%.  fo:table-body never had any
> validation implemented, hence the NPE's that were
> occurring.  

Your new validation code invalidates valid fo files. If you would have
run the layoutengine tests, you would have noticed. The test file
table-body1.xml no longer passes. I have committed a correction. I
have also made TableFooter use TableBody's validation code, as
TableHeader does.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java TableFooter.java

[Glen Mazza]

Thanks Simon.

Glen

--- [EMAIL PROTECTED] wrote:
>
> spepping2005/03/02 13:03:25
> 
>   Modified:src/java/org/apache/fop/fo/flow
> TableBody.java
> TableFooter.java
>   Log:
>   Corrected a validation problem. Made TableFooter
> use TableBody's validation.
>   

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Chris Bowditch]

Glen Mazza wrote:
Hi Glen,
OH!!!   

Yes, you're right, Chris--now I see the issue.  I
implemented validation for about 80% of the FOs, but
80% is not 100%.  fo:table-body never had any
validation implemented, hence the NPE's that were
occurring.  
I'm glad this issue has finally been resolved, thanks for taking the time to 
research a bit deeper.

Sorry, Jeremias, I thought you had just gratuitously
*removed* the validation from fo:table-body -- I
should have researched that it wasn't there to begin
with.
Well, that would have been a bit rude, but like you said there wasnt any 
validation on . Now hopefully we are all a bit more comfortable 
with the situation.

Thanks,
Glen
Chris