You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Manuel Mall <mm...@arcus.com.au> on 2006/02/01 02:25:32 UTC
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
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Posted by Manuel Mall <mm...@arcus.com.au>.
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
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Posted by Andreas L Delmelle <a_...@pandora.be>.
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
Posted by Andreas L Delmelle <a_...@pandora.be>.
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
Posted by Andreas L Delmelle <a_...@pandora.be>.
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
Posted by Andreas L Delmelle <a_...@pandora.be>.
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