DO NOT REPLY [Bug 32174] - Rendering fails with IndexOutOfBoundsException in LineLayoutManager
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
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
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()?
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()?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 :(
