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, ... > > Jeremias Maerki Manuel
