Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler .java
On 02.02.2006 12:37:13 Manuel Mall wrote: > On Thursday 02 February 2006 16:49, Jeremias Maerki wrote: > > My gut feeling here is that it is now more correct than before but > > there are still two trailing spaces in the area tree that I'd > > expected not to be there. But then, I still haven't done my homework > > concerning whitespace handling. :-( > > Jeremias, > > looks good to me - which two spaces are you unsure about? My fault. I did an "svn up" from the command-line and didn't refresh the sources in Eclipse. Everything's in order. Jeremias Maerki
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler .java
On Thursday 02 February 2006 16:49, Jeremias Maerki wrote: > My gut feeling here is that it is now more correct than before but > there are still two trailing spaces in the area tree that I'd > expected not to be there. But then, I still haven't done my homework > concerning whitespace handling. :-( Jeremias, looks good to me - which two spaces are you unsure about? > > On 01.02.2006 22:14:11 Andreas L Delmelle wrote: > > On Feb 1, 2006, at 21:51, Andreas L Delmelle wrote: > > > ... > > > Alright! The space has finally disappeared, but... > > > I still end up with the same failing testcase: > > > inline_border_padding.xml > > > > > > If you look at the sixth block, somehow an ipd of 118.83pt is > > > expected, but I currently get an ipd of 113.27pt. Can anyone > > > explain where the expected value comes from? If I look at the > > > resulting area tree, then I'm under the impression that the > > > output is A-OK... Am I missing something? > > > May it be altered to 113.27pt? (= *my* expectation :-)) > > > > > > Anyway, I'm reluctant to commit until this one final riddle is > > > solved. > > > > On second thought, I'm just going to change the expected value... > > What's 5.56/72 (+/- 2mm) anyway? Right! Peanuts. > > > > If anyone feels differently, they're most welcome to explain why > > :-) > > Andreas, the test was not written to check whitespace handling. Therefore the ipd test was based on the incorrect whitespace present before. You now correctly remove the two trailing spaces (2780mpt * 2) and therefore the ipd shrinks by 5560mpt. IMO my opinion all is fine and yes you had to adjust the test. > > Cheers, > > > > Andreas > > Jeremias Maerki Manuel
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler .java
My gut feeling here is that it is now more correct than before but there are still two trailing spaces in the area tree that I'd expected not to be there. But then, I still haven't done my homework concerning whitespace handling. :-( On 01.02.2006 22:14:11 Andreas L Delmelle wrote: > On Feb 1, 2006, at 21:51, Andreas L Delmelle wrote: > > > ... > > Alright! The space has finally disappeared, but... > > I still end up with the same failing testcase: > > inline_border_padding.xml > > > > If you look at the sixth block, somehow an ipd of 118.83pt is > > expected, but I currently get an ipd of 113.27pt. Can anyone > > explain where the expected value comes from? If I look at the > > resulting area tree, then I'm under the impression that the output > > is A-OK... Am I missing something? > > May it be altered to 113.27pt? (= *my* expectation :-)) > > > > Anyway, I'm reluctant to commit until this one final riddle is solved. > > On second thought, I'm just going to change the expected value... > What's 5.56/72 (+/- 2mm) anyway? Right! Peanuts. > > If anyone feels differently, they're most welcome to explain why :-) > > Cheers, > > Andreas Jeremias Maerki
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler .java
On Feb 1, 2006, at 21:51, Andreas L Delmelle wrote: ... Alright! The space has finally disappeared, but... I still end up with the same failing testcase: inline_border_padding.xml If you look at the sixth block, somehow an ipd of 118.83pt is expected, but I currently get an ipd of 113.27pt. Can anyone explain where the expected value comes from? If I look at the resulting area tree, then I'm under the impression that the output is A-OK... Am I missing something? May it be altered to 113.27pt? (= *my* expectation :-)) Anyway, I'm reluctant to commit until this one final riddle is solved. On second thought, I'm just going to change the expected value... What's 5.56/72 (+/- 2mm) anyway? Right! Peanuts. If anyone feels differently, they're most welcome to explain why :-) Cheers, Andreas
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler .java
On Feb 1, 2006, at 19:50, Andreas L Delmelle wrote: ... I'll see if I get to debugging this further. Stay tuned. No real debugging done yet. I just commented out the mentioned conditional in TextLM, so eventual remaining spaces are always mapped to the no-BAP element list. The result is identical, so ... back to square one. Alright! The space has finally disappeared, but... I still end up with the same failing testcase: inline_border_padding.xml If you look at the sixth block, somehow an ipd of 118.83pt is expected, but I currently get an ipd of 113.27pt. Can anyone explain where the expected value comes from? If I look at the resulting area tree, then I'm under the impression that the output is A-OK... Am I missing something? May it be altered to 113.27pt? (= *my* expectation :-)) Anyway, I'm reluctant to commit until this one final riddle is solved. Cheers, Andreas
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler .java
On Feb 1, 2006, at 18:34, Andreas L Delmelle wrote: On Feb 1, 2006, at 02:25, Manuel Mall wrote: If BAP != 0 then a Knuth box element is inserted. This acts as a fence for removeTrailingSpaces(), that is removeTrailingSapces() cannot distinguish if the Box represents an actual word in the text or is a border/ padding space reservation and stops removal once it sees a Box. So, yes IMO your algorithm does not produce a proper result but removeTrailingSpaces() hides this unless we have border/padding intervening. Not sure if I got this correctly, but LineLM.removeTrailingSpaces() has been completely removed/disabled in my local sandbox, so this box doesn't serve any purpose currently (?) That's exactly why this is puzzling me... In one case, no borders/ padding, it does produce a correct result --layout doesn't remove trailing spaces anymore, and in the no-BAP case it appears it doesn't have to-- while in the other a space remains. I'll see if I get to debugging this further. Stay tuned. No real debugging done yet. I just commented out the mentioned conditional in TextLM, so eventual remaining spaces are always mapped to the no-BAP element list. The result is identical, so ... back to square one. Later, Andreas
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler .java
On Feb 1, 2006, at 02:25, Manuel Mall wrote: If BAP != 0 then a Knuth box element is inserted. This acts as a fence for removeTrailingSpaces(), that is removeTrailingSapces() cannot distinguish if the Box represents an actual word in the text or is a border/ padding space reservation and stops removal once it sees a Box. So, yes IMO your algorithm does not produce a proper result but removeTrailingSpaces() hides this unless we have border/padding intervening. Not sure if I got this correctly, but LineLM.removeTrailingSpaces() has been completely removed/disabled in my local sandbox, so this box doesn't serve any purpose currently (?) That's exactly why this is puzzling me... In one case, no borders/ padding, it does produce a correct result --layout doesn't remove trailing spaces anymore, and in the no-BAP case it appears it doesn't have to-- while in the other a space remains. I'll see if I get to debugging this further. Stay tuned. Cheers, Andreas
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler .java
> On Jan 31, 2006, at 06:12, Manuel Mall wrote: > >> >> Just curious if you had a chance to have a look yet. > > Errm... A look yes, but I haven't found the time to correct it yet. > BTW: does anyone know whether the removeTrailingSpaces() method was > the only part of layout concerned with space removal? The funny thing > is that if I remove the border and padding props, the remaining space > disappears. If that is so, then AFAICT, it's possible that my > algorithm still doesn't produce the proper result, but layout > corrects this (unless there's border-and-padding involved --which, > IIC, leads to a different element list being constructed for spaces > (?) see TextLayoutManager at line 832 "if (lineStartBAP != 0 || > lineEndBAP != 0)"; I presume BAP is short for Border And Padding) > If BAP != 0 then a Knuth box element is inserted. This acts as a fence for removeTrailingSpaces(), that is removeTrailingSapces() cannot distinguish if the Box represents an actual word in the text or is a border/padding space reservation and stops removal once it sees a Box. So, yes IMO your algorithm does not produce a proper result but removeTrailingSpaces() hides this unless we have border/padding intervening. > Cheers, > > Andreas > Manuel
Re: svn commit: r367395 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/XMLWhiteSpaceHandler .java
On Jan 31, 2006, at 06:12, Manuel Mall wrote: Just curious if you had a chance to have a look yet. Errm... A look yes, but I haven't found the time to correct it yet. BTW: does anyone know whether the removeTrailingSpaces() method was the only part of layout concerned with space removal? The funny thing is that if I remove the border and padding props, the remaining space disappears. If that is so, then AFAICT, it's possible that my algorithm still doesn't produce the proper result, but layout corrects this (unless there's border-and-padding involved --which, IIC, leads to a different element list being constructed for spaces (?) see TextLayoutManager at line 832 "if (lineStartBAP != 0 || lineEndBAP != 0)"; I presume BAP is short for Border And Padding) Cheers, Andreas
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 > Just curious if you had a chance to have a look yet. > Cheers, > > Andreas > Regards Manuel
