DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=31206>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31206 [PATCH] Improvements over the new line breaking algorithm ------- Additional Comments From [EMAIL PROTECTED] 2004-11-12 15:35 ------- I have created a new patch against HEAD. I have tested it and it seems to work, but at the moment I'm not yet ready to commit it, sorry; maybe someone could do this in my place? A few points which may need further work: - I renamed the new interface from InlineLM to InlineLevelLM. Merging it with the new InlineLM class would involve having TextLM and LeafNodeLM extend InlineLM instead of AbstractLM, and this seems a bit strange to me - the offset of the areas is set according to the value of the vertical-align property instead of alignment-baseline - the offset of the viewport area generated by svg graphics is not set, because I couldn't find its height - the offset of textAreas is set by the TextLM, which creates them; but vertical-align is a property of inline level formatting objects only, so the TextLM checks if the parent node is an Inline - the main problem in applying the changes to the new code involved leaders with use-content; in the old code, the method LeaderLM.getLeaderInlineArea() created a ContentLM and an InlineStackingLM: LeaderLM | | ContentLM | | InlineStackingLM ____|____ | | | (LMs handling the use-content) but now InlineStackingLM does no more implement getNextKnuthElements(), and the InlineLM constructor requires an Inline node; I temporarily fixed this by adding a constructor for InlineLM with a Leader parameter, but I don't like this very much. Regards, Luca
