Summary: | Left-align oddness with long, unbreakable strings following | ||
---|---|---|---|
Product: | Fop - Now in Jira | Reporter: | Chuck Bearden <cbearden> |
Component: | page-master/layout | Assignee: | fop-dev |
Status: | CLOSED FIXED | ||
Severity: | normal | CC: | robin |
Priority: | P2 | ||
Version: | all | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Attachments: |
FO file illustrating the problem
PDF file I built that manifests the problem Partial fix, patching the BreakingAlgorithm |
Description
Chuck Bearden
2006-11-22 08:25:36 UTC
Created attachment 19160 [details] FO file illustrating the problem Convert this file to PDF with trunk r477112 to see the problem. Created attachment 19161 [details]
PDF file I built that manifests the problem
PDF file manifesting the problem
*** Bug 41121 has been marked as a duplicate of this bug. *** *** Bug 41460 has been marked as a duplicate of this bug. *** I've noticed that the premature line breaking only happens inside the <fo:block> element which contains the long string. A work around is to embed the long string inside it's own fo:block. hth --Robin Enabling hyphenation also seems to prevent the problem. 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 hyphenation points 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 .... :-) Luca Created attachment 19459 [details]
Partial fix, patching the BreakingAlgorithm
This should now be fixed in revision 501453. Thanks for signalling this bug! batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed |