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

2005-03-02 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33801.
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

2005-03-02 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33801.
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=14386action=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

2005-03-02 Thread 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

2005-03-02 Thread 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

2005-03-02 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33801.
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

2005-03-02 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33808.
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

2005-03-02 Thread 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

2005-03-02 Thread 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

2005-03-02 Thread 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

2005-03-02 Thread 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

2005-03-02 Thread 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

2005-03-02 Thread 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

2005-03-02 Thread 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

2005-03-02 Thread Simon Pepping
On Tue, Mar 01, 2005 at 09:15:37PM -0800, Glen Mazza wrote:
 OH!!!  lightBulb state=on wattage=25/ 
 
 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

2005-03-02 Thread 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

2005-03-02 Thread Chris Bowditch
Glen Mazza wrote:
Hi Glen,
OH!!!  lightBulb state=on wattage=25/ 

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 fo:table-body. Now hopefully we are all a bit more comfortable 
with the situation.

Thanks,
Glen
Chris