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=37743>. 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=37743 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|exeption: border-style |exception: border-style |(shorthand) |(shorthand) ------- Additional Comments From [EMAIL PROTECTED] 2005-12-02 13:10 ------- The problem is (again) that the breaking text into lines and words logic crosses inline boundaries and our nested inline processing is getting really in the way. To get around this the code has to 'jump through hoops'. In this case the Knuth sequences returned by getNextKnuthElement are used to reverse engineer words which extend over an inline boundary. This in turn needs to be done to determine if an additional letter space needs to be added as the individual LMs don't do that at a boundary because they don't know if they start/end at the beginning/end of a word or in the middle of a word. Of course this "ranting" about the problem will not get us a solution. In the very short term may be Luca can have a look at this as he as fixed a similar problem before in a related area. After that we really need to redesign the line breaking stuff. Not the Knuth approach (and the implemented algorithms related to that) but the way we arrive at the Knuth sequences and iterate and process the text elements. This needs to be done to be able to do white-space-treatment, UAX#14 line breaking, start- /end- space resolution and generally to be able to handle some more aspects of Unicode (e.g. glyph merging). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
