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:
> > >
> > 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, ...

> Jeremias Maerki


Reply via email to