xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas L Delmelle <a_l.delme...@pandora.be>
Subject Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/
Date Fri, 30 Dec 2005 13:38:07 GMT
On Dec 30, 2005, at 14:33, adelmelle@apache.org 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  
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  

If you have:
     <fo:inline>some inline text _

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  

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



View raw message