Bug 41019 - Left-align oddness with long, unbreakable strings following
Summary: Left-align oddness with long, unbreakable strings following
Status: CLOSED FIXED
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: page-master/layout (show other bugs)
Version: all
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
: 41121 41460 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-11-22 08:25 UTC by Chuck Bearden
Modified: 2012-04-01 06:42 UTC (History)
1 user (show)



Attachments
FO file illustrating the problem (4.57 KB, text/xml)
2006-11-22 08:29 UTC, Chuck Bearden
Details
PDF file I built that manifests the problem (24.25 KB, application/pdf)
2006-11-22 08:31 UTC, Chuck Bearden
Details
Partial fix, patching the BreakingAlgorithm (3.23 KB, patch)
2007-01-25 06:36 UTC, Luca Furini
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chuck Bearden 2006-11-22 08:25:36 UTC
I used trunk at r477112.

If in a left-aligned block some typical text words are followed by a string
longer than the line-length and containing no spaces (e.g. a long URL), then the
foregoing text will have premature line breaks, i.e. halfway to two-thirds the
way into the line.  See attached files or
<http://www.ece.rice.edu/~cbearden/fop/> for an example.
Comment 1 Chuck Bearden 2006-11-22 08:29:29 UTC
Created attachment 19160 [details]
FO file illustrating the problem

Convert this file to PDF with trunk r477112 to see the problem.
Comment 2 Chuck Bearden 2006-11-22 08:31:02 UTC
Created attachment 19161 [details]
PDF file I built that manifests the problem

PDF file manifesting the problem
Comment 3 Luca Furini 2006-12-12 06:42:53 UTC
*** Bug 41121 has been marked as a duplicate of this bug. ***
Comment 4 Chris Bowditch 2007-01-25 04:08:45 UTC
*** Bug 41460 has been marked as a duplicate of this bug. ***
Comment 5 Robin Harvey 2007-01-25 04:42:57 UTC
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
Comment 6 Manuel Mall 2007-01-25 04:53:35 UTC
Enabling hyphenation also seems to prevent the problem.
Comment 7 Luca Furini 2007-01-25 06:35:57 UTC
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
Comment 8 Luca Furini 2007-01-25 06:36:44 UTC
Created attachment 19459 [details]
Partial fix, patching the BreakingAlgorithm
Comment 9 Luca Furini 2007-01-30 08:41:48 UTC
This should now be fixed in revision 501453.

Thanks for signalling this bug!
Comment 10 Glenn Adams 2012-04-01 06:42:12 UTC
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed