Uploaded image for project: 'FOP'
  1. FOP
  2. FOP-1270

Left-align oddness with long, unbreakable strings following

    Details

    • Type: Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: layout/unqualified
    • Labels:
      None
    • Environment:
      Operating System: Linux
      Platform: PC
    • External issue ID:
      41019

      Description

      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.

      1. footnotes.fo
        5 kB
        Chuck Bearden
      2. footnotes.pdf
        24 kB
        Chuck Bearden
      3. bug_41019_partial_patch.diff
        3 kB
        Luca Furini

        Issue Links

          Activity

          Hide
          gadams Glenn Adams added a comment -

          batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

          Show
          gadams Glenn Adams added a comment - batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed
          Hide
          lfurini@cs.unibo.it Luca Furini added a comment -

          This should now be fixed in revision 501453.

          Thanks for signalling this bug!

          Show
          lfurini@cs.unibo.it Luca Furini added a comment - This should now be fixed in revision 501453. Thanks for signalling this bug!
          Hide
          lfurini@cs.unibo.it Luca Furini added a comment -

          Attachment bug_41019_partial_patch.diff has been added with description: Partial fix, patching the BreakingAlgorithm

          Show
          lfurini@cs.unibo.it Luca Furini added a comment - Attachment bug_41019_partial_patch.diff has been added with description: Partial fix, patching the BreakingAlgorithm
          Hide
          lfurini@cs.unibo.it Luca Furini added a comment -

          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

          Show
          lfurini@cs.unibo.it Luca Furini added a comment - 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
          Hide
          manuel Manuel Mall added a comment -

          Enabling hyphenation also seems to prevent the problem.

          Show
          manuel Manuel Mall added a comment - Enabling hyphenation also seems to prevent the problem.
          Hide
          robin@chaptereight.com Robin Harvey added a comment -

          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

          Show
          robin@chaptereight.com Robin Harvey added a comment - 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
          Hide
          cbowditch Chris Bowditch added a comment -
              • FOP-1299 has been marked as a duplicate of this bug. ***
          Show
          cbowditch Chris Bowditch added a comment - FOP-1299 has been marked as a duplicate of this bug. ***
          Hide
          lfurini@cs.unibo.it Luca Furini added a comment -
              • FOP-1274 has been marked as a duplicate of this bug. ***
          Show
          lfurini@cs.unibo.it Luca Furini added a comment - FOP-1274 has been marked as a duplicate of this bug. ***
          Hide
          cbearden@rice.edu Chuck Bearden added a comment -

          PDF file manifesting the problem

          Show
          cbearden@rice.edu Chuck Bearden added a comment - PDF file manifesting the problem
          Hide
          cbearden@rice.edu Chuck Bearden added a comment -

          Attachment footnotes.pdf has been added with description: PDF file I built that manifests the problem

          Show
          cbearden@rice.edu Chuck Bearden added a comment - Attachment footnotes.pdf has been added with description: PDF file I built that manifests the problem
          Hide
          cbearden@rice.edu Chuck Bearden added a comment -

          Convert this file to PDF with trunk r477112 to see the problem.

          Show
          cbearden@rice.edu Chuck Bearden added a comment - Convert this file to PDF with trunk r477112 to see the problem.
          Hide
          cbearden@rice.edu Chuck Bearden added a comment -

          Attachment footnotes.fo has been added with description: FO file illustrating the problem

          Show
          cbearden@rice.edu Chuck Bearden added a comment - Attachment footnotes.fo has been added with description: FO file illustrating the problem

            People

            • Assignee:
              fop-dev@xmlgraphics.apache.org fop-dev
              Reporter:
              cbearden@rice.edu Chuck Bearden
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development