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
