xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Fixing leading whitespace on a line (was: How about a release?)
Date Sun, 09 Apr 2006 12:13:36 GMT

On 08.04.2006 10:29:33 Manuel Mall wrote:
> On Friday 07 April 2006 23:13, Manuel Mall wrote:
> > On Friday 07 April 2006 19:14, Manuel Mall wrote:
> > > On Friday 07 April 2006 16:06, Jeremias Maerki wrote:
> > > > On 06.04.2006 20:50:18 Peter S. Housel wrote:
> >
> > <snip/>
> >
> Committed my changes.

Looks good! Thanks a lot!

> As far as I can tell the various text-align property values work 
> correctly even if white space is not collapsed. That is assuming we 
> have something like:
> 	word1<sp><sp><sp>word2<sp><sp>word3
> and do not collapse whitespace but specify text-align="justify" each 
> <sp> is treated as a separate word space.
> 
> I think the disabled test case block_white-space-collapse_2.xml is also 
> fixed. At least the failure reason given in disabled_testcases.xml is 
> addressed now.

Yes. I'm a little confused about the text in there. Anyway, the
behaviour seems correct as are the generated element lists.

I think I'm going to enhance the test a little and add a new one that
tests a few specialities. I've found a bug, too: If I use
text-align-last="justify" the nbsp characters are not adjustable. I've
locally added nbsp to the list of adjustable characters in CharUtilities.
I'll upload as soon as I've got the checks ready.

> However, I am not sure if the spaces 'embedded' in the 
> <fo:character character=" " /> elements are dealt with correctly. 

No, they are not. :-( It seems we don't have the ability to generated
adjustable spaces from fo:character. This got me thinking about how to
improve this: I think we should investigate a way that would allow us to
fold the characters from fo:character elements into the main text array
of an FOText. Maybe a flyweight pattern approach could help specifying
the applicable properties for each character. That means that the
character borders and such should be dealt with in TextLM (CharLM would
go). The code might get a little more complicated but it would solve the
problem above and would address the fact that all characters should be
internally converted to fo:character objects as the spec suggests. Only
we'd be doing this the other way around. Not sure. Maybe there's also an
easier way by enhancing CharLM. WDYT?

> Therefore I haven't removed that testcase from the disabled list. A 
> similar comment applies to block_linefeed-treatment.xml. The comment in 
> disabled_testcases.xml that the testcase fails because of incorrect 
> handling of ZWSP is not correct any more. However, the <fo:character 
> issue probably still remains. May be someone else can cast their eyes 
> over these two cases and their current behaviour?

<snip/>

> > PS: Good to be back working on FOP - really missed it for the last
> > couple of months.

I'm glad to hear that and to have you back.


Jeremias Maerki


Mime
View raw message