DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
------- Additional Comments From [EMAIL PROTECTED] 2007-01-25 06:35 -------
I have created a patch fixing the BreakingAlgorithm, so that, when a restart is
needed, the algorithm starts from a previously deactivated node (if it exists)
instead of using either a short break or a long one (there are a few messages in
fop-dev concerning this).
This should solve the bug, but makes the testcase block_uax14_linebreaking.xml
fail; in particular, the block testing exclamation and question marks creates a
different set of breaks that looks quite worse than the expected one, while
still being correct.
I already have a couple of suspects:
- the LineLM can call findBreakingPoints() with a threshold equal to 20: this
allows a huge "overstretch", especially with unjustified text when the glue
elements have some conventional (and quite high) stretch value
- the element sequences created by the TextLM have some "unintentional feasible
breaks" that could be actually chosen while the algorithm is ignoring the
For the moment I'm attaching the partial patch, as I'm reluctant to apply it
before fixing the other details; I should have some time to finish it tomorrow
afternoon, but if someone else is quicker .... :-)
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.