Re: svn commit: r320826 - /xmlgraphics/fop/branches/Temp_SpaceResolution/
Both are bugs. Thanks for finding them. I'm currently working on
testing for them and fixing them.
On 19.10.2005 22:04:47 Simon Pepping wrote:
Jeremias,
Two questions, about SpaceResolver.resolve():
1. performSpaceResolutionRules2to3(firstPart, firstPartLengths);
Should the resolution not be applied to the reverse of firstPart
and firstPartLengths, because you may be locating the last space
specifier in the original order?
2. if (isFirst || isLast) {
performSpaceResolutionRule1(secondPart, secondPartLengths);
}
If isLast, then the edge of the reference area is at the
end. Should then the resolution not be applied to the reverse
of secondPart and secondPartLengths?
Regards, Simon
On Thu, Oct 13, 2005 at 08:23:50PM +0200, Jeremias Maerki wrote:
I finally uploaded my space resolution work so far. It's still not
finished. When you go through the details you always find more stuff to
look into and to fix. But most of it works now and is available for
review while I work on the remaining issues. I assume there is room for
optimization here and there. So don't hesitate to jump in and help. The
enabled test cases all pass.
--
Simon Pepping
home page: http://www.leverkruid.nl
Jeremias Maerki
Re: svn commit: r320826 - /xmlgraphics/fop/branches/Temp_SpaceResolution/
Thanks for your feedback, Simon. I know about the empty block problem. I even documented it (sort of) in the commit message (block w=0 causes a fence right now although it shouldn't.). I think it relatively easily dealt with. The box with w=0 can easily be recognized in SpaceResolver and handled as needed. I'll document this with a test case. On 17.10.2005 20:24:43 Simon Pepping wrote: On Thu, Oct 13, 2005 at 08:23:50PM +0200, Jeremias Maerki wrote: I finally uploaded my space resolution work so far. It's still not finished. When you go through the details you always find more stuff to look into and to fix. But most of it works now and is available for review while I work on the remaining issues. I assume there is room for optimization here and there. So don't hesitate to jump in and help. The enabled test cases all pass. What I forgot to include in the commit message: I changed from empty block areas to space-before and space-after traits! This caused a lot of changed checks in the test cases. That was a project on its own. :-) But the area trees are much clearer now. That is a lot of code. The result looks very robust. The following case seems to present a problem: ... /fo:block fo:block/ fo:block space-before=10pt background-color=#B5 ... The empty block seems to split the stacking constraint into two constraints, one containing the space-after of the preceding block, and another containing the space-before of the following block. IMHO, this should be a single stacking constraint, case 3d in the spec., section 4.2.5, Stacking Constraints. When the empty block has space-before and/or space-after, it results even in a rule in the output. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl Jeremias Maerki
Re: svn commit: r320826 - /xmlgraphics/fop/branches/Temp_SpaceResolution/
On Thu, Oct 13, 2005 at 08:23:50PM +0200, Jeremias Maerki wrote: I finally uploaded my space resolution work so far. It's still not finished. When you go through the details you always find more stuff to look into and to fix. But most of it works now and is available for review while I work on the remaining issues. I assume there is room for optimization here and there. So don't hesitate to jump in and help. The enabled test cases all pass. What I forgot to include in the commit message: I changed from empty block areas to space-before and space-after traits! This caused a lot of changed checks in the test cases. That was a project on its own. :-) But the area trees are much clearer now. That is a lot of code. The result looks very robust. The following case seems to present a problem: ... /fo:block fo:block/ fo:block space-before=10pt background-color=#B5 ... The empty block seems to split the stacking constraint into two constraints, one containing the space-after of the preceding block, and another containing the space-before of the following block. IMHO, this should be a single stacking constraint, case 3d in the spec., section 4.2.5, Stacking Constraints. When the empty block has space-before and/or space-after, it results even in a rule in the output. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
