Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler.java
On Fri, 13 Jan 2006 08:01 am, Manuel Mall wrote: On Fri, 13 Jan 2006 12:49 am, Andreas L Delmelle wrote: On Jan 12, 2006, at 01:14, Manuel Mall wrote: On Thu, 12 Jan 2006 05:34 am, Andreas L Delmelle wrote: snip / without your patch I cannot really replicate this. When I run through the debugger now I can see the space being given from the FO to the TextLayoutManager (look at the textarray in the TextLM constructor) therefore to me its still a refinement issue. But if your latest modifications fixes that then I would need that patch to further investigate. Try the diff in attach (modifications to XMLWhiteSpaceHandler and LineLayoutManager) Applied the diff but it didn't change my observation in the debugger. The extra space you noticed is coming from the FO. Therefore IMO the patch is not quite doing what you would like it to do. I haven't looked at your code yet. Andreas, The following change in XMLWhiteSpaceHandler (/*nonWhiteSpacePresent ||*/ nextChild != null)) seems to fix it. That is I just commented out the test for nonWhiteSpacePresent. I do not fully understand the implications of this change. I'll leave it up to you to further explore. Manuel Manuel
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler.java
On Jan 13, 2006, at 15:47, Manuel Mall wrote: Applied the diff but it didn't change my observation in the debugger. The extra space you noticed is coming from the FO. Therefore IMO the patch is not quite doing what you would like it to do. I haven't looked at your code yet. Andreas, The following change in XMLWhiteSpaceHandler (/*nonWhiteSpacePresent ||*/ nextChild != null)) seems to fix it. OK. I'll have a closer look at it this weekend Cheers, Andreas
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler.java
Andreas L Delmelle wrote:
On Jan 11, 2006, at 17:56, Andreas L Delmelle wrote:
snip/
OK. So apparently, this has nothing to do with refinement white-space-
handling, IIC.
snip/
If I remove the border-* and padding-* properties, the trailing space
area for the latter disappears...?
Of course, the expected result could simply be modified, but it would
be much better if this were fixed in the related code. No idea where
precisely.
= Q: Disable it FTM, or alter the expectation to make it pass?
I don't like the sound of this at all. May I suggest an alternative
approach to finding the cause of the problem? Could you create a diff of
all changed files and post it up here, so others may aid in the
investigation?
snip/
I changed the related code in BreakingAlgorithm from:
while(alignment != EN_CENTER
! ((KnuthElement) par.get(firstBoxIndex)).isBox()) {
firstBoxIndex++;
...
to:
if(alignment != EN_CENTER
while(par.size() firstBoxIndex
! ((KnuthElement) par.get(firstBoxIndex)).isBox()) {
firstBoxIndex++;
...
That solved this particular little problem, but it is more of a quick
fix, I guess.
I think we need to understand the root cause of this before making this
change. Unfortunately Jeremias isn't around for the next 2/3 days, so
may I suggest holding off making this change until he returns. He has a
very good understand of this bit of code ;)
Chris
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler.java
On Fri, 13 Jan 2006 12:49 am, Andreas L Delmelle wrote: On Jan 12, 2006, at 01:14, Manuel Mall wrote: On Thu, 12 Jan 2006 05:34 am, Andreas L Delmelle wrote: snip / without your patch I cannot really replicate this. When I run through the debugger now I can see the space being given from the FO to the TextLayoutManager (look at the textarray in the TextLM constructor) therefore to me its still a refinement issue. But if your latest modifications fixes that then I would need that patch to further investigate. Try the diff in attach (modifications to XMLWhiteSpaceHandler and LineLayoutManager) Applied the diff but it didn't change my observation in the debugger. The extra space you noticed is coming from the FO. Therefore IMO the patch is not quite doing what you would like it to do. I haven't looked at your code yet. Manuel
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler.java
On Jan 11, 2006, at 17:56, Andreas L Delmelle wrote:
On Jan 10, 2006, at 14:02, Manuel Mall wrote:
I got the lastest svn version of fop and then commented out the
removeElementsForTrailingSpaces() method in LineLayoutManager as
theoretically your patch should make this unnecessary. However, we
get
a erroneous trailing space in the block_white-space-collapse_1.xml
test
case.
Just a quick FYI: I think I've found the problem, and almost solved
it... Almost, since now the mentioned testcase works fine, but in
inline_border_padding.xml, I now get an error, and the reason for
it completely eludes me. On the one hand, the error indicates an
inlineParent area with an IPD that is *less* than the expected
value. On the other hand, that same inlineParent apparently has an
offending trailing space area --while the conditions in the FOTree
are identical AFAICT (it's the last inline in the last block).
Once I succeed in tracking this one down, I'll commit again.
OK. So apparently, this has nothing to do with refinement white-space-
handling, IIC.
I tried commenting out removeElementsForTrailingSpaces() and ran a FO
containing the following two blocks:
fo:block background-color=silver margin=1pt 0pt 1pt 0pt
fo:inline background-color=orange
inline level
fo:inline background-color=red
nested inline level
/fo:inline
/fo:inline
/fo:block
fo:block background-color=silver margin=3pt 0pt 3pt 0pt
Demonstrates nested
fo:inline background-color=yellow border=solid 2pt red
padding-start=2pt padding-end=2pt inlines
fo:inline background-color=orange border=solid 1pt green
padding-start=2pt padding-end=2pt finishing together
/fo:inline
/fo:inline
/fo:block
and for the two inner inlines, I get the following area tree fragments:
inlineparent ...
text ...
space offset=0 /space
word offset=0nested/word
space offset=0 /space
word offset=0inline/word
space offset=0 /space
word offset=0level/word
/text
/inlineparent
inlineparent ...
text ...
word offset=0finishing/word
space offset=0 /space
word offset=0together/word
space offset=0 /space
/text
/inlineparent
If I remove the border-* and padding-* properties, the trailing space
area for the latter disappears...?
Of course, the expected result could simply be modified, but it would
be much better if this were fixed in the related code. No idea where
precisely.
= Q: Disable it FTM, or alter the expectation to make it pass?
Also, I got an error on testcase table_width.xml:
[junit] Testcase: table_width.xml
(org.apache.fop.layoutengine.LayoutEngineTestSuite$1): Caused an
ERROR
[junit] java.lang.IndexOutOfBoundsException: Index: 6, Size: 6
[junit] ; SystemID: file:///Developer/javatools/xml-fop/test/
layoutengine/testcase2fo.xsl; Line#: 34; Column#: 60
[junit] javax.xml.transform.TransformerException:
java.lang.IndexOutOfBoundsException: Index: 6, Size: 6
...
[junit] Caused by: java.lang.IndexOutOfBoundsException: Index: 6,
Size: 6
[junit] at java.util.ArrayList.RangeCheck(ArrayList.java:507)
[junit] at java.util.ArrayList.get(ArrayList.java:324)
[junit] at
org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints
(BreakingAlgorithm.java:367)
[junit] at
org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints
(BreakingAlgorithm.java:339)
[junit] at org.apache.fop.layoutmgr.inline.LineLayoutManager
$LineBreakingAlgorithm.findBreakingPoints
(LineLayoutManager.java:537)
[junit] at org.apache.fop.layoutmgr.inline.LineLayoutManager
.findOptimalBreakingPoints(LineLayoutManager.java:1000)
I changed the related code in BreakingAlgorithm from:
while(alignment != EN_CENTER
! ((KnuthElement) par.get(firstBoxIndex)).isBox()) {
firstBoxIndex++;
...
to:
if(alignment != EN_CENTER
while(par.size() firstBoxIndex
! ((KnuthElement) par.get(firstBoxIndex)).isBox()) {
firstBoxIndex++;
...
That solved this particular little problem, but it is more of a quick
fix, I guess.
All other tests pass, so if my above tiny question is answered, and
no-one objects to the described change in BreakingAlgorithm.java,
I'll do the commit.
Cheers,
Andreas
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler.java
On Thu, 12 Jan 2006 05:34 am, Andreas L Delmelle wrote: On Jan 11, 2006, at 17:56, Andreas L Delmelle wrote: On Jan 10, 2006, at 14:02, Manuel Mall wrote: I got the lastest svn version of fop and then commented out the removeElementsForTrailingSpaces() method in LineLayoutManager as theoretically your patch should make this unnecessary. However, we get a erroneous trailing space in the block_white-space-collapse_1.xml test case. Just a quick FYI: I think I've found the problem, and almost solved it... Almost, since now the mentioned testcase works fine, but in inline_border_padding.xml, I now get an error, and the reason for it completely eludes me. On the one hand, the error indicates an inlineParent area with an IPD that is *less* than the expected value. On the other hand, that same inlineParent apparently has an offending trailing space area --while the conditions in the FOTree are identical AFAICT (it's the last inline in the last block). Once I succeed in tracking this one down, I'll commit again. OK. So apparently, this has nothing to do with refinement white-space- handling, IIC. I tried commenting out removeElementsForTrailingSpaces() and ran a FO containing the following two blocks: fo:block background-color=silver margin=1pt 0pt 1pt 0pt fo:inline background-color=orange inline level fo:inline background-color=red nested inline level /fo:inline /fo:inline /fo:block fo:block background-color=silver margin=3pt 0pt 3pt 0pt Demonstrates nested fo:inline background-color=yellow border=solid 2pt red padding-start=2pt padding-end=2pt inlines fo:inline background-color=orange border=solid 1pt green padding-start=2pt padding-end=2pt finishing together /fo:inline /fo:inline /fo:block and for the two inner inlines, I get the following area tree fragments: inlineparent ... text ... space offset=0 /space word offset=0nested/word space offset=0 /space word offset=0inline/word space offset=0 /space word offset=0level/word /text /inlineparent inlineparent ... text ... word offset=0finishing/word space offset=0 /space word offset=0together/word space offset=0 /space /text /inlineparent If I remove the border-* and padding-* properties, the trailing space area for the latter disappears...? Of course, the expected result could simply be modified, but it would be much better if this were fixed in the related code. No idea where precisely. = Q: Disable it FTM, or alter the expectation to make it pass? Andreas, without your patch I cannot really replicate this. When I run through the debugger now I can see the space being given from the FO to the TextLayoutManager (look at the textarray in the TextLM constructor) therefore to me its still a refinement issue. But if your latest modifications fixes that then I would need that patch to further investigate. Also, I got an error on testcase table_width.xml: [junit] Testcase: table_width.xml (org.apache.fop.layoutengine.LayoutEngineTestSuite$1): Caused an ERROR [junit] java.lang.IndexOutOfBoundsException: Index: 6, Size: 6 Do we know which patch (SVN revision) introduced this issue? snip / Cheers, Andreas Manuel
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler.java
On Tue, 10 Jan 2006 05:24 am, Andreas L Delmelle wrote: On Jan 9, 2006, at 22:20, [EMAIL PROTECTED] wrote: Author: adelmelle Date: Mon Jan 9 13:20:07 2006 New Revision: 367395 URL: http://svn.apache.org/viewcvs?rev=367395view=rev OK folks, This should solve the 'trailing white-space for trailing (nested) inlines' issue recently discussed ad nauseam here :-) I got the lastest svn version of fop and then commented out the removeElementsForTrailingSpaces() method in LineLayoutManager as theoretically your patch should make this unnecessary. However, we get a erroneous trailing space in the block_white-space-collapse_1.xml test case. It seems the nested inline trailing space removal in the case of fo:block background-color=silver margin=1pt 0pt 1pt 0pt fo:inline background-color=orange inline level fo:inline background-color=red nested inline level /fo:inline /fo:inline /fo:block is not yet quite right unless I misinterpret the results. snip/ Cheers, Andreas Regards Manuel
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler.java
On Jan 9, 2006, at 22:20, [EMAIL PROTECTED] wrote: Author: adelmelle Date: Mon Jan 9 13:20:07 2006 New Revision: 367395 URL: http://svn.apache.org/viewcvs?rev=367395view=rev OK folks, This should solve the 'trailing white-space for trailing (nested) inlines' issue recently discussed ad nauseam here :-) I was a bit doubtful at first about using mark() for this, since I received a couple of concurrent modification errors. Those turned out to be caused by blocks being added to the pendingInlines list, so concurrent modification of the underlying list of white-space was to be expected. Once this was fixed, all regression tests passed w/o complications. It should work since *iff* there is remaining white- space (inWhiteSpace==true), then the element at which the iterator was marked, is guaranteed to be present (and the rest of the list unchanged if white-space-collapse=false). Again, no noticeable change in the iterators yet. Strictly speaking, at least the InlineCharIterator could already be removed, I think (not used anymore), but I consider the iterators a task in itself, so will take care of it then and there. Markers, as Manuel suggested, are currently still white-space-treated according to their possibly erroneous property values, since that would still cover most of the use-cases. Obvious work-around is to use a block simply as a container for the related properties to be inherited by the marker-content. Cheers, Andreas
