Fop
  1. Fop
  2. FOP-1315

linefeed-treatment="preserve" not honored

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: 0.93
    • Fix Version/s: None
    • Component/s: fo/unqualified
    • Labels:
      None
    • Environment:
      Operating System: other
      Platform: Other
    • External issue ID:
      41652

      Description

      In the actual peace of code

      fo:block hyphenate="false" font-family="monospace" text-align="start"
      wrap-option="no-wrap" font-size="8pt" id="d0e3596" white-space-collapse="false"
      white-space-treatment="preserve" linefeed-treatment="preserve"
      line-stacking-strategy="font-height">xxxxxxxxxxxxxxxxxxxxx

      yyyyyyyyyyyy
      zzzzzzzzzzzzzzzzzzz</fo:block>

      the second (empty) line is "swallowed"

        Activity

        J created issue -
        Hide
        Andreas L. Delmelle added a comment -

        Confirmed with FOP Trunk.

        Interestingly, if you insert a space between the two consecutive linefeeds, you do get an empty line...
        leading me to think that the linefeed is preserved, but one ends up with a zero-height line.

        A way to fix this may exactly be to insert such a space-character in the code somewhere, whenever there
        are two consecutive linefeeds.

        Show
        Andreas L. Delmelle added a comment - Confirmed with FOP Trunk. Interestingly, if you insert a space between the two consecutive linefeeds, you do get an empty line... leading me to think that the linefeed is preserved, but one ends up with a zero-height line. A way to fix this may exactly be to insert such a space-character in the code somewhere, whenever there are two consecutive linefeeds.
        Hide
        Andreas L. Delmelle added a comment -

        Further investigation and debugging confirm my suspicion, I think:

        In both cases, with or without the intermediate space, the list returned by the TextLM consists of 4
        InlineKnuthSequences. Without the intermediate space, the second sequence contains only a
        KnuthPenalty corresponding to the preserved linefeed.

        My initial idea of Inserting a space character would lead to undesirable outcomes, in for instance the
        following case:

        <fo:block linefeed-treatment="preserve">xxxx
        <fo:inline background-color="blue">

        yyyy</fo:inline>
        zzzz</fo:block>

        in case there is a space on the 'empty' line, one would expect the blue background to appear for the
        width of one space character. In case it's just two consecutive linefeeds, the line should be completely
        empty, so no background should be visible...

        I see a possible fix in adding the following to fop.layoutmgr.InlineKnuthSequence.endSequence():

        if (!isClosed) {
        if (isEmpty())

        { add(new KnuthGlue(1, 0, 0, null, true)); }

        ...

        Or in English: if endSequence() is called on an empty sequence, add a dummy glue element.
        The glue will be suppressed because of the following infinite penalty, so will leave no trace behind
        when background colors are used, like in the above example, but it will trigger the generation of the
        expected empty line (in AreaTree terms: an empty linearea, or one containing only an empty
        inlineparent of zero ipd)

        I'm going to leave it open FTM, to allow others to comment in on the proposed change.

        Show
        Andreas L. Delmelle added a comment - Further investigation and debugging confirm my suspicion, I think: In both cases, with or without the intermediate space, the list returned by the TextLM consists of 4 InlineKnuthSequences. Without the intermediate space, the second sequence contains only a KnuthPenalty corresponding to the preserved linefeed. My initial idea of Inserting a space character would lead to undesirable outcomes, in for instance the following case: <fo:block linefeed-treatment="preserve">xxxx <fo:inline background-color="blue"> yyyy</fo:inline> zzzz</fo:block> in case there is a space on the 'empty' line, one would expect the blue background to appear for the width of one space character. In case it's just two consecutive linefeeds, the line should be completely empty, so no background should be visible... I see a possible fix in adding the following to fop.layoutmgr.InlineKnuthSequence.endSequence(): if (!isClosed) { if (isEmpty()) { add(new KnuthGlue(1, 0, 0, null, true)); } ... Or in English: if endSequence() is called on an empty sequence, add a dummy glue element. The glue will be suppressed because of the following infinite penalty, so will leave no trace behind when background colors are used, like in the above example, but it will trigger the generation of the expected empty line (in AreaTree terms: an empty linearea, or one containing only an empty inlineparent of zero ipd) I'm going to leave it open FTM, to allow others to comment in on the proposed change.
        Hide
        Andreas L. Delmelle added a comment -

        (In reply to comment #2)
        > I see a possible fix in adding the following to fop.layoutmgr.InlineKnuthSequence.endSequence():
        >

        On second thought, maybe it's better to do something similar in
        LineLayoutManager.collectInlineKnuthElements().

        At line 746, an attempt is made to deal with the situation of blank lines (~ InlineKnuthSequence
        containing nothing but a forced break), but the added KnuthInlineBox of w=0 still doesn't produce the
        expected result. It does work if you increase the width (to some value between 1 and iLineWidth).

        Still, using an auxiliary KnuthGlue instead of a box also works, and somehow seems more appropriate.

        Opinions anyone?

        Show
        Andreas L. Delmelle added a comment - (In reply to comment #2) > I see a possible fix in adding the following to fop.layoutmgr.InlineKnuthSequence.endSequence(): > On second thought, maybe it's better to do something similar in LineLayoutManager.collectInlineKnuthElements(). At line 746, an attempt is made to deal with the situation of blank lines (~ InlineKnuthSequence containing nothing but a forced break), but the added KnuthInlineBox of w=0 still doesn't produce the expected result. It does work if you increase the width (to some value between 1 and iLineWidth). Still, using an auxiliary KnuthGlue instead of a box also works, and somehow seems more appropriate. Opinions anyone?
        Hide
        Andreas L. Delmelle added a comment -

        Decided on the proposed change in LineLayoutManager.

        Bug fixed in FOP Trunk.
        see: http://svn.apache.org/viewvc?view=rev&rev=510626

        Thanks for reporting the bug!

        Show
        Andreas L. Delmelle added a comment - Decided on the proposed change in LineLayoutManager. Bug fixed in FOP Trunk. see: http://svn.apache.org/viewvc?view=rev&rev=510626 Thanks for reporting the bug!
        Hide
        Glenn Adams added a comment -

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

        Show
        Glenn Adams added a comment - batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

          People

          • Assignee:
            fop-dev
            Reporter:
            J
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development