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=41671>. 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=41671 ------- Additional Comments From [EMAIL PROTECTED] 2007-02-22 15:23 ------- Its just software so anything is possible :-) Historcally the hyphen is one of those characters which is vastly overloaded with different meaning in different contexts. The UAX#14 spec has taken one particular approach to its interpretation which admittedly doesn't match well in some legacy situations, i.e. situations in which the hyphen is used in a context different to what the Unicode standard expect it to be used in. The quick and dirty hack (untested of course) would be to add in org.apache.fop.text.linebreak.LineBreakStatus in the method nextChar() at the beginning something like: if (c == '-') c = '\u2013'; That is whenever we give a hyphen to the line breaker convert it into a EN DASH before the line breaker deals with it. A probably better solution, but requiring some understanding of the UAX#14 spec, would be to change the actual pair table in src/codegen/unicode/data/LineBreakPairTable.txt and to regenerate the java code using the codegen-unicode ant target. For example change the cell (row HY / col NU) from % (indirect break opportunity) to _ (direct break opportunity). That would allow a break between a hyphen followed directly by a numeric. Hope this helps. -- 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.
