DO NOT REPLY [Bug 32174] - Rendering fails with IndexOutOfBoundsException in LineLayoutManager

2004-11-11 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=32174.
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=32174

Rendering fails with IndexOutOfBoundsException in LineLayoutManager





--- Additional Comments From [EMAIL PROTECTED]  2004-11-11 09:54 ---
The fo file would be very useful to see what goes wrong, but a minimal fo file 
showing this bug would be even better! :-)

It seems that the problem concerns a fo:block in the 5th fo:page-sequence: if 
possible, please attach the shortest fo file still presenting this bug.

Thanks!

Luca


DO NOT REPLY [Bug 32174] - Rendering fails with IndexOutOfBoundsException in LineLayoutManager

2004-11-11 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=32174.
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=32174

Rendering fails with IndexOutOfBoundsException in LineLayoutManager





--- Additional Comments From [EMAIL PROTECTED]  2004-11-11 11:11 ---
Hi Luca,

I have been running into the same problem, and haven't been able to fully 
isolate the cause just yet, but I strongly suspect this has something to do 
with fo:blocks containing nothing but a non-breaking space (#xA0;). 

If you take a look at line 522 in LineLayoutManager, it would seem that the 
IOOBException is being thrown because the list of possible linebreak positions 
is empty...

Attached the most basic FO I could think of :-)

Greetz,

Andreas


DO NOT REPLY [Bug 32174] - Rendering fails with IndexOutOfBoundsException in LineLayoutManager

2004-11-11 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=32174.
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=32174

Rendering fails with IndexOutOfBoundsException in LineLayoutManager





--- Additional Comments From [EMAIL PROTECTED]  2004-11-11 11:13 ---
Created an attachment (id=13396)
FO demonstrating possible cause


Re: remove LayoutManager.initialize()?

2004-11-11 Thread Glen Mazza
Finn Bock wrote:
[Glen]
Does anyone have a problem if I worked towards
removing the initialize() method from our
LayoutManager interface?  

There is two way of looking at it. The code in initProperties() which 
can be moved to the ctor should be. That is no loss at all and will 
reduce complexity of the LMs a tiny bit.

Yes, any initialization that the LM can do internally I'd like to get 
out of initProperties(), so I can better see where external 
initialization is needed.

BTW, we're down to four usages, of which I think three I can easily move 
to the constructor [1], [2], [3].  (Please glance at them and see if you 
see anything obvious that would suggest otherwise.)  I'm thinking this 
way because I believe the new implementation of the properties keeps the 
values of the particular traits being called immutable. 

[1]  
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/LineLayoutManager.java?annotate=1.32#76
[2]  
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/InlineLayoutManager.java?annotate=1.2#54
[3]  
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java?annotate=1.26#67

The fourth LM [4] I believe is being reused for multiple fo:blocks 
during processing--and uses initProperties() to update its state--so 
this one will take more scrutiny.  I would like that classes' 
initProperties() to be renamed to something more self-documenting, such 
as reloadTraitsForNextFOBlock() or something similar.  But this one can 
be looked at later.

[4]  
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/BlockLayoutManager.java?annotate=1.32#77

Thanks,
Glen


Re: remove LayoutManager.initialize()?

2004-11-11 Thread Glen Mazza
Finn Bock wrote:
But removing the initialize() method will reduce the flexibility that 
LMs currently has to retrieve information from the parent LM. Perhaps 
that flexibility is not used at the moment but I suspect that it will 
be needed to implement the irregular inheritence of properties like 
text-decoration.

Well, an LM has a parentLM member variable that it can always access.  
But you may have discovered initialize()'s intended use.  In the five 
cases in the code where initialize() is being called (there's a stray 
apparently unneeded case in LineLM I'm not counting here), immediately 
before or after setParent() is also called e.g. [1] [2].

[1] 
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/ContentLayoutManager.java?annotate=1.15#268

[2] 
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java?annotate=1.12#497

[I think the after cases like [2] are erroneous BTW--it appears we 
should be calling setParent() first.]

But for those LM's which may need to have their trait values refreshed 
whenever a new parent LM is attached, wouldn't it be better for the LM 
to refresh *itself* internally and automatically whenever setParent() is 
called, rather than have this resynching be directed externally?  (It 
would appear that a well-designed LM would do this regardless rather 
than let itself remain in a corrupted state upon a setParent() call.)  
So, I'm still not convinced on initialize()'s benefits--this appears to 
be something we should remove now, and bring back once we have a 
documented use for it (and preferably with a more descriptive name e.g., 
refreshTraitValues() or something similar.)

Thanks,
Glen


DO NOT REPLY [Bug 32153] - Unwanted whitespace around image

2004-11-11 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=32153.
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=32153

Unwanted whitespace around image

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Major   |Minor



--- Additional Comments From [EMAIL PROTECTED]  2004-11-11 17:02 ---
I have a workaround for my particular situation. I have a table, which then has 
nested tables inside it, these tables have cells with the images / other 
content. The small lines of white are still there but because it's in a cell I  
then set the bkgrd color similar to image and it's practically invisible.


Re: commenting the Knuth code/centering issue

2004-11-11 Thread Luca Furini

I have tried to add some comments to the Knuth[Element, Box, Glue,
Penalty] classes.

As I am not sure they are clear enough (I'm not even sure they are written
in a proper English! :-) ) I'd like to hear your opinions before
committing them.

Regards,
Luca


Index: KnuthBox.java
===
RCS file: 
/home/cvspublic/xml-fop/src/java/org/apache/fop/layoutmgr/KnuthBox.java,v
retrieving revision 1.2
diff -u -r1.2 KnuthBox.java
--- KnuthBox.java   6 Sep 2004 19:07:12 -   1.2
+++ KnuthBox.java   11 Nov 2004 17:56:22 -
@@ -18,6 +18,16 @@
 
 package org.apache.fop.layoutmgr;
 
+/**
+ * An instance of this class represents an unbreakable piece of content with
+ * fixed width: for example an image, a syllable (but only if letter spacing
+ * is constant), ...
+ *  A KnuthBox is never a feasible breaking point.
+ *  The represented piece of content is never suppressed.
+ *  Besides the inherited methods and attributes, this class has some more
+ * attributes to store information about the content height and its vertical
+ * positioning, and the methods used to get them.
+ */
 public class KnuthBox extends KnuthElement {
 private int lead;
 private int total;
Index: KnuthElement.java
===
RCS file: 
/home/cvspublic/xml-fop/src/java/org/apache/fop/layoutmgr/KnuthElement.java,v
retrieving revision 1.2
diff -u -r1.2 KnuthElement.java
--- KnuthElement.java   6 Sep 2004 19:07:12 -   1.2
+++ KnuthElement.java   11 Nov 2004 17:56:23 -
@@ -18,6 +18,13 @@
 
 package org.apache.fop.layoutmgr;
 
+/**
+ * This is the super class for KnuthBox, KnuthGlue and KnuthPenalty.
+ *  It stores information common to all sub classes, and the methods to get it:
+ * the width, a Position and a boolean marking KnuthElements used for some
+ * special feature (for example, the additional elements used to represent
+ * a space when text alignment is right, left or center).
+ */
 public abstract class KnuthElement {
 
 public static final int KNUTH_BOX = 0;
Index: KnuthGlue.java
===
RCS file: 
/home/cvspublic/xml-fop/src/java/org/apache/fop/layoutmgr/KnuthGlue.java,v
retrieving revision 1.2
diff -u -r1.2 KnuthGlue.java
--- KnuthGlue.java  6 Sep 2004 19:07:12 -   1.2
+++ KnuthGlue.java  11 Nov 2004 17:56:23 -
@@ -18,6 +18,28 @@
 
 package org.apache.fop.layoutmgr;
 
+/**
+ * An instance of this class represents a piece of content with adjustable 
+ * width: for example a space between words of justified text.
+ *  A KnuthGlue is a feasible breaking point only if it immediately follows
+ * a KnuthBox.
+ *  The represented piece of content is suppressed if either the KnuthGlue
+ * is a chosen breaking point or there isn't any KnuthBox between the
+ * previous breaking point and the KnuthGlue itself.
+ *  So, an unsuppressible piece of content with adjustable width, for example
+ * a leader or a word with adjustable letter space, cannot be represented
+ * by a single KnuthGlue; it can be represented using the sequence:
+ *   KnuthBox(width = 0)
+ *   KnuthPenalty(width = 0, penalty = infinity)
+ *   KnuthGlue(...)
+ *   KnuthBox(width = 0)
+ * where the infinity penalty avoids choosing the KnuthGlue as a breaking point
+ * and the 0-width KnuthBoxes prevent suppression.
+ *  Besides the inherited methods and attributes, this class has two attributes
+ * used to store the stretchability (difference between max and opt width) and
+ * the shrinkability (difference between opt and min width), and the methods
+ * to get these values.
+ */
 public class KnuthGlue extends KnuthElement {
 private int stretchability;
 private int shrinkability;
Index: KnuthPenalty.java
===
RCS file: 
/home/cvspublic/xml-fop/src/java/org/apache/fop/layoutmgr/KnuthPenalty.java,v
retrieving revision 1.2
diff -u -r1.2 KnuthPenalty.java
--- KnuthPenalty.java   6 Sep 2004 19:07:12 -   1.2
+++ KnuthPenalty.java   11 Nov 2004 17:56:23 -
@@ -18,6 +18,21 @@
 
 package org.apache.fop.layoutmgr;
 
+/**
+ * An instance of this class represents information about a feasible
+ * breaking point; it does not represent any piece of content.
+ *  A KnuthPenalty is a feasible breaking point unless its value is infinity;
+ * a KnuthPenalty whose value is -infinity represents a forced break.
+ *  A KnuthPenalty is suppressed, and its width is ignored, if it is not a
+ * chosen breaking point; for example, a KnuthPenalty representing a
+ * hyphenation point has a width (the - width), which must be ignored if
+ * that point is not chosen as a breaking point.
+ *  Besides the inherited methods and attributes, this class has two more
+ * attributes and the methods used to get them: the penalty value, which is
+ * a kind of aesthetic cost (the higher the value, the more 

Re: commenting the Knuth code/centering issue

2004-11-11 Thread Clay Leeds
On Nov 11, 2004, at 10:03 AM, Luca Furini wrote:
I have tried to add some comments to the Knuth[Element, Box, Glue,
Penalty] classes.
As I am not sure they are clear enough (I'm not even sure they are 
written
in a proper English! :-) ) I'd like to hear your opinions before
committing them.
The English appears good to me. There are even words in there I've 
never even used (unsuppressible?! stretchability?! shrinkability?!) 
although they appear to be used correctly! This will be well-commented 
(IMHO) when you're done...

Web Maestro Clay
--
Clay Leeds - [EMAIL PROTECTED]
Webmaster/Developer - Medata, Inc. - http://www.medata.com/
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


Re: commenting the Knuth code/centering issue

2004-11-11 Thread Glen Mazza
Excellent, although indentation of paragraphs in comments is somewhat 
less common (but if done, should probably be three or four spaces indent 
instead of just one).  Instead of indenting, it would probably be better 
(easier to read) if you placed a blank line between paragraphs.  Also, 
if you can comment the methods -- one sentence each for the simple ones 
are OK -- that would also be appreciated.  I know it's a chore but it 
has to be done for the JavaDocs.

BTW, got the Digital Typography book in the mail yesterday--started 
reading it yesterday, very interesting so far.  Hope to be able to add 
to the comments myself sometime soon!

Thanks,
Glen
Luca Furini wrote:
I have tried to add some comments to the Knuth[Element, Box, Glue,
Penalty] classes.
As I am not sure they are clear enough (I'm not even sure they are written
in a proper English! :-) ) I'd like to hear your opinions before
committing them.
Regards,
   Luca
 


Index: KnuthBox.java
===
RCS file: 
/home/cvspublic/xml-fop/src/java/org/apache/fop/layoutmgr/KnuthBox.java,v
retrieving revision 1.2
diff -u -r1.2 KnuthBox.java
--- KnuthBox.java   6 Sep 2004 19:07:12 -   1.2
+++ KnuthBox.java   11 Nov 2004 17:56:22 -
@@ -18,6 +18,16 @@
package org.apache.fop.layoutmgr;
+/**
+ * An instance of this class represents an unbreakable piece of content with
+ * fixed width: for example an image, a syllable (but only if letter spacing
+ * is constant), ...
+ *  A KnuthBox is never a feasible breaking point.
+ *  The represented piece of content is never suppressed.
+ *  Besides the inherited methods and attributes, this class has some more
+ * attributes to store information about the content height and its vertical
+ * positioning, and the methods used to get them.
+ */
public class KnuthBox extends KnuthElement {
private int lead;
private int total;
Index: KnuthElement.java
===
RCS file: 
/home/cvspublic/xml-fop/src/java/org/apache/fop/layoutmgr/KnuthElement.java,v
retrieving revision 1.2
diff -u -r1.2 KnuthElement.java
--- KnuthElement.java   6 Sep 2004 19:07:12 -   1.2
+++ KnuthElement.java   11 Nov 2004 17:56:23 -
@@ -18,6 +18,13 @@
package org.apache.fop.layoutmgr;
+/**
+ * This is the super class for KnuthBox, KnuthGlue and KnuthPenalty.
+ *  It stores information common to all sub classes, and the methods to get it:
+ * the width, a Position and a boolean marking KnuthElements used for some
+ * special feature (for example, the additional elements used to represent
+ * a space when text alignment is right, left or center).
+ */
public abstract class KnuthElement {
public static final int KNUTH_BOX = 0;
Index: KnuthGlue.java
===
RCS file: 
/home/cvspublic/xml-fop/src/java/org/apache/fop/layoutmgr/KnuthGlue.java,v
retrieving revision 1.2
diff -u -r1.2 KnuthGlue.java
--- KnuthGlue.java  6 Sep 2004 19:07:12 -   1.2
+++ KnuthGlue.java  11 Nov 2004 17:56:23 -
@@ -18,6 +18,28 @@
package org.apache.fop.layoutmgr;
+/**
+ * An instance of this class represents a piece of content with adjustable 
+ * width: for example a space between words of justified text.
+ *  A KnuthGlue is a feasible breaking point only if it immediately follows
+ * a KnuthBox.
+ *  The represented piece of content is suppressed if either the KnuthGlue
+ * is a chosen breaking point or there isn't any KnuthBox between the
+ * previous breaking point and the KnuthGlue itself.
+ *  So, an unsuppressible piece of content with adjustable width, for example
+ * a leader or a word with adjustable letter space, cannot be represented
+ * by a single KnuthGlue; it can be represented using the sequence:
+ *   KnuthBox(width = 0)
+ *   KnuthPenalty(width = 0, penalty = infinity)
+ *   KnuthGlue(...)
+ *   KnuthBox(width = 0)
+ * where the infinity penalty avoids choosing the KnuthGlue as a breaking point
+ * and the 0-width KnuthBoxes prevent suppression.
+ *  Besides the inherited methods and attributes, this class has two attributes
+ * used to store the stretchability (difference between max and opt width) and
+ * the shrinkability (difference between opt and min width), and the methods
+ * to get these values.
+ */
public class KnuthGlue extends KnuthElement {
private int stretchability;
private int shrinkability;
Index: KnuthPenalty.java
===
RCS file: /home/cvspublic/xml-fop/src/java/org/apache/fop/layoutmgr/KnuthPenalty.java,v
retrieving revision 1.2
diff -u -r1.2 KnuthPenalty.java
--- KnuthPenalty.java	6 Sep 2004 19:07:12 -	1.2
+++ KnuthPenalty.java	11 Nov 2004 17:56:23 -
@@ -18,6 +18,21 @@

package org.apache.fop.layoutmgr;
+/**
+ * An instance of this class represents information 

Re: commenting the Knuth code/centering issue

2004-11-11 Thread Simon Pepping
Luca,

On Thu, Nov 11, 2004 at 07:03:33PM +0100, Luca Furini wrote:
 
 I have tried to add some comments to the Knuth[Element, Box, Glue,
 Penalty] classes.
 
 As I am not sure they are clear enough (I'm not even sure they are written
 in a proper English! :-) ) I'd like to hear your opinions before
 committing them.

These comments are fine.

Simon

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



DO NOT REPLY [Bug 32193] New: - NullPointerException when using non-Apache XML parser (Xerces) and/or JXTransformer

2004-11-11 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=32193.
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=32193

NullPointerException when using non-Apache XML parser (Xerces) and/or 
JXTransformer

   Summary: NullPointerException when using non-Apache XML parser
(Xerces) and/or JXTransformer
   Product: Fop
   Version: 0.20.5
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Critical
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


On my cite we had an XML parser created by Oracle
(oracle.xml.parser.v2.SAXParser) installed in the system, so FOP was picking it
up and using it before it found Xerces.  Same for the JXTransformer class in
oracle.xml.jaxp.JXTransformer.  This created a NullPointerException in
JXTransformer.reportXSLException().

My kludge solution was to modify fop.sh and to include both xercesImpl.jar and
xalan.jar in -Xbootclasspath/p: (so they are searched before ANY other JARs). 
This eliminated the NullPointerException and everything worked perfectly.

In this bugzilla form I listed this under with OS Linux, but I suspect it would
produce the same effects on any other system where Xerces and Xalan aren't found
first.


DO NOT REPLY [Bug 32174] - Rendering fails with IndexOutOfBoundsException in LineLayoutManager

2004-11-11 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=32174.
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=32174

Rendering fails with IndexOutOfBoundsException in LineLayoutManager





--- Additional Comments From [EMAIL PROTECTED]  2004-11-11 22:23 ---
Created an attachment (id=13411)
Very cut down example, same error. fop 0.20.5 renders it fine


DO NOT REPLY [Bug 32174] - Rendering fails with IndexOutOfBoundsException in LineLayoutManager

2004-11-11 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=32174.
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=32174

Rendering fails with IndexOutOfBoundsException in LineLayoutManager





--- Additional Comments From [EMAIL PROTECTED]  2004-11-11 22:27 ---
I've added a new testcase, which is attached. Very interesting: If i delete the
line:

fo:marker marker-class-name=section.head.markerSORCER/fo:marker

It renders fine. If i leave it in there it crashes (Index out of bounds)


DO NOT REPLY [Bug 32193] - NullPointerException when using non-Apache XML parser (Xerces) and/or JXTransformer

2004-11-11 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=32193.
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=32193

NullPointerException when using non-Apache XML parser (Xerces) and/or 
JXTransformer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-11-11 22:32 ---
I'm not sure what FOP can do here to fix this problem; we don't code the Oracle
parsers, and the choosing of the specific XML libraries is done by the Java
classloader, not FOP.

There are buggy versions of Xalan and Xerces that will also create NPE's; our
solution in these cases are to recommend the user replace those libraries with
more recent versions from the Xalan / Xerces web sites.

Glen


DO NOT REPLY [Bug 32174] - Rendering fails with IndexOutOfBoundsException in LineLayoutManager

2004-11-11 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=32174.
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=32174

Rendering fails with IndexOutOfBoundsException in LineLayoutManager





--- Additional Comments From [EMAIL PROTECTED]  2004-11-11 22:35 ---
You do know that 1.0 is in development right now, correct?  I am very doubtful
that it can handle the docbook xsl stylesheets--there are probably dozen of
issues right now (after the one below) that still need fixing/implementation.

Glen


DO NOT REPLY [Bug 32174] - Rendering fails with IndexOutOfBoundsException in LineLayoutManager

2004-11-11 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=32174.
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=32174

Rendering fails with IndexOutOfBoundsException in LineLayoutManager





--- Additional Comments From [EMAIL PROTECTED]  2004-11-11 23:13 ---
Glen,

I realize that there will be multiple issues. Even if I delete all the
fo:marker  lines from my .fo file (which makes it actually work!) the output
is far from perfect. 

But in the end fop 1.0 should be able to render my document. And as far as I
understand (please correct me if i am wrong on this), unless the issue is
already documented as missing / not working in some test case this is the place
to report it.


DO NOT REPLY [Bug 32174] - Rendering fails with IndexOutOfBoundsException in LineLayoutManager

2004-11-11 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=32174.
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=32174

Rendering fails with IndexOutOfBoundsException in LineLayoutManager





--- Additional Comments From [EMAIL PROTECTED]  2004-11-11 23:51 ---
All right! So now it's narrowed down to two cases for which the code needs a 
bit of fine-tuning:

- markers: however, it's a distinct possibility that there's a slightly 
different cause for this --I don't really see how a marker that isn't retrieved 
can trigger the creation of a LineLayoutManager in the first place. That should 
only happen *if* and *when* the marker is retrieved.

- (pseudo-)empty blocks (mainly used in case one has empty table-cells)

BTW: Max, you are absolutely right in that this is THE place to report such 
errors, and of course we appreciate your input --how else would we be able to 
arrive at a working solution in the end?


DO NOT REPLY [Bug 32174] - Rendering fails with IndexOutOfBoundsException in LineLayoutManager

2004-11-11 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=32174.
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=32174

Rendering fails with IndexOutOfBoundsException in LineLayoutManager





--- Additional Comments From [EMAIL PROTECTED]  2004-11-12 02:48 ---
Q
I understand (please correct me if i am wrong on this), unless the issue is
already documented as missing / not working in some test case this is the place
to report it.
/Q

Absolutely, Max, you are doing the right thing in reporting the bugs.  Please
continue!  I just don't want you to be *surprised* that there are bugs in the
1.0 release--that you're aware that the 1.0 system isn't complete ATM.

Thanks,
Glen


DO NOT REPLY [Bug 32174] - Rendering fails with IndexOutOfBoundsException in LineLayoutManager

2004-11-11 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=32174.
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=32174

Rendering fails with IndexOutOfBoundsException in LineLayoutManager





--- Additional Comments From [EMAIL PROTECTED]  2004-11-12 04:43 ---
Glen,

sorry I appear to have misunderstood you. I know that the software will not be
perfect for a while.

The reason I filed this bug because I needed some other functionality, wanted to
write a patch for it. But there is no point in patching the stable branch, so I
am stuck with 1.0dev.

As for this bug, I've looked into the code but I am missing the necessary
understanding of this project to make any useful contributions :(