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:55:05 GMT

On 09.04.2006 14:32:39 Manuel Mall wrote:
> On Sunday 09 April 2006 20:13, Jeremias Maerki wrote:
> > 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/>
> > > 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?
> >
> 
> I think pulling it up to the TextLM is a step into the right direction 
> but as I said before I still do believe it needs to go up to the LineLM 
> level as character handling (white space handling, break decisions, 
> determine word boundaries for hyphenation, ...) spans inline 
> boundaries. Therefore a pattern like a character iterator to be exposed 
> by the inline LMs which would allow the LineLM to iterate through all 
> characters (with their properties) it has to deal with appears to me 
> more suitable. While this is all doable without too much difficulties 
> (although blocks in inlines, leaders, borders, and the like do pose 
> some challenges to this pattern) the decision if one would need to move 
> the Knuth element list generation to LineLM level as well is IMO the 
> critical one here. If we leave the Knuth element list generation at 
> inline LM level we have again problems with stuff crossing boundaries 
> and also need a means of signalling back to the LM who provided the 
> character through the above mentioned iterator what to do with it when 
> it comes to Knuth element generation. But if we move the element list 
> generation to LineLM level we break the generic LM interface (may be 
> its OK if inline type LMs expose a different interface than block level 
> LMs?).  Also if we let the LineLM build the Knuth element list it must 
> be provided with enough information (or suitable interfaces) to be able 
> to construct the "area info" objects required by the LMs to actually 
> build the areas during the add area phase.
> 
> Decisions, decisions, ...

Yes, yes. But that's the fun about it, right? :-) I didn't think about
the inline spanning when I wrote that. You've definitely got the better
"big picture" and your proposed direction certainly makes sense to me.

I don't think it's a problem if inline LMs expose a different interface.
We're definitely not bound to keeping everything as it is, if this
offers chance to do things right.

Jeremias Maerki


Mime
View raw message