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

Reply via email to