On Dec 30, 2005, at 14:33, [EMAIL PROTECTED] wrote:
Author: adelmelle
Date: Fri Dec 30 05:33:18 2005
New Revision: 360083
URL: http://svn.apache.org/viewcvs?rev=360083&view=rev
Log:
Revision of refinement white-space handling (cfr. Bugzilla 37639)
Brief description of the changes:
1) extraction of the handleWhiteSpace() method into a separate class
(org.apache.fop.fo.XMLWhiteSpaceHandler)
2) altering the algorithm to trigger white-space handling for all FOs
that can contain FOText or Character children (= all FObjMixed, with
the notable exception of Leader), at two points:
* addChildNode()
* endOfNode()
Case not covered by the altered code (but I didn't think it to be a
showstopper):
If you have:
<fo:block>
<fo:inline>some inline text _
____</fo:inline>_
__</fo:block>
Currently, the first series of underlined white-space is not
completely suppressed. It will at most be collapsed to a single
space. The second series --between endInline() and endBlock()-- is
completely suppressed because handleWhiteSpace() was called from
Block.endOfNode().
I explicitly excluded fo:leaders from white-space handling, because
for example:
<fo:leader leader-pattern="use-content"> xxx </fo:leader>
Collapsing the three spaces to one may produce unintended results.
OTOH, if you have a nested inline in a leader, then the white-space
for the inline will be treated...
For the rest only a few minor updates to related test-cases:
- block_white-space-collapse_2.xml: see info disabled-testcases.xml
- leader_text-align.xml / leader_toc.xml: update of the expected ipd
values; they seemed to ignore preserved spaces
Things left to consider:
* the Iterator structure: as it stands, we only need to iterate over
FOText and Character, so it seems like there is a possibility for
radical simplification in that area.
* using a similar strategy for text-transform, so we can get rid of
the static FOText.lastFOTextProcessed
Cheers,
Andreas
