FOP
  1. FOP
  2. FOP-1142

Non-breaking space in PDF title output

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: 0.91
    • Fix Version/s: None
    • Component/s: renderer/pdf
    • Labels:
      None
    • Environment:
      Operating System: Linux
      Platform: PC
    • External issue ID:
      38507

      Description

      The <quote> XML tag is converted in French with a « followed with a non-breaking
      space. In the body (<para>) text, non-breaking space seems to be respected.
      But I have this sequence in a chapter title (Eg: <chapter><title>Some
      <quote>text</quote></title></chapter>). In this case, the PDF output of the
      title did not respect the non breaking space and broke the line just after the "«".
      I've checked the fo source produced by XSL and it contains really the
      non-breaking space sequence.

      FYI, fop 0-20-5 did this correctly.

      1. Chap1.fo
        38 kB
        Claude Paroz

        Activity

        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
        Hide
        Luca Furini added a comment -

        Fixed in the revision 375585 (http://svn.apache.org/viewcvs?rev=375585&view=rev).

        Thank you for finding and signalling this bug!

        Show
        Luca Furini added a comment - Fixed in the revision 375585 ( http://svn.apache.org/viewcvs?rev=375585&view=rev ). Thank you for finding and signalling this bug!
        Hide
        Manuel Mall added a comment -

        Jeremias, no that is not it IMO. Knuth doesn't break between elements as such.
        The glue or penalty element itself is the break opportunity and is discarded
        when used as a break. Therefore, IMO we are not breaking before or after a
        space or NBSP but at the space/NBSP.

        The problem is the coding model used for Knuth element element generation for
        spaces is flawed. What is done is that the only difference between normal space
        and NBSP is an infinite penalty at the beginning of the sequence. However, some
        sequences are pretty long and involve multiple pen-glue combinations and
        therefore break opportunities further into the sequence. We probably need to
        separate this more cleanly. Have one function for non breaking elastic elements
        (e.g. NBSP) and one function for breaking eleastic elements (e.g. SPACE). The
        non breaking sequences are probably very simple:

        1. Justified text: pen INF + elastic glue
        2. All other justification modes: either just a box of the width of the space
        or pen INF + fixed width glue.

        Curious what Luca and others think. Are the above two cases OK for NBSP or have
        I oversimplified and missed something, that is for the text-align values other
        then "justify", that is "start", "center", "end", is it enough to just reserve
        a fixed width for the NBSP?

        Show
        Manuel Mall added a comment - Jeremias, no that is not it IMO. Knuth doesn't break between elements as such. The glue or penalty element itself is the break opportunity and is discarded when used as a break. Therefore, IMO we are not breaking before or after a space or NBSP but at the space/NBSP. The problem is the coding model used for Knuth element element generation for spaces is flawed. What is done is that the only difference between normal space and NBSP is an infinite penalty at the beginning of the sequence. However, some sequences are pretty long and involve multiple pen-glue combinations and therefore break opportunities further into the sequence. We probably need to separate this more cleanly. Have one function for non breaking elastic elements (e.g. NBSP) and one function for breaking eleastic elements (e.g. SPACE). The non breaking sequences are probably very simple: 1. Justified text: pen INF + elastic glue 2. All other justification modes: either just a box of the width of the space or pen INF + fixed width glue. Curious what Luca and others think. Are the above two cases OK for NBSP or have I oversimplified and missed something, that is for the text-align values other then "justify", that is "start", "center", "end", is it enough to just reserve a fixed width for the NBSP?
        Hide
        Andreas L. Delmelle added a comment -

        ad comment #2:
        "... when a NBSP is encountered a normal sequence as for an ordinary space is generated and simply
        prefixed with an infinite penalty."

        So, does this 'prefixed' mean a NBSP currently only prevents breaking before the space (breaking after it
        -or before the next glue/box- could still be considered 'possible/desirable')? If so, the effect we need to
        achieve would be something analogous to having:
        <fo:character character=" " keep-with-next.within-line="always" />

        Show
        Andreas L. Delmelle added a comment - ad comment #2: "... when a NBSP is encountered a normal sequence as for an ordinary space is generated and simply prefixed with an infinite penalty." So, does this 'prefixed' mean a NBSP currently only prevents breaking before the space (breaking after it - or before the next glue/box - could still be considered 'possible/desirable')? If so, the effect we need to achieve would be something analogous to having: <fo:character character=" " keep-with-next.within-line="always" />
        Hide
        Jeremias Maerki added a comment -

        First step towards fixing the problem is adding a test case:
        http://svn.apache.org/viewcvs?rev=374892&view=rev

        If anyone is interested I've got a quick fix / hack for this. It doesn't fix the
        test case as it should but it fixes the symptom in FOP Trunk. But better do it
        right. That's why I didn't commit the fix.

        Show
        Jeremias Maerki added a comment - First step towards fixing the problem is adding a test case: http://svn.apache.org/viewcvs?rev=374892&view=rev If anyone is interested I've got a quick fix / hack for this. It doesn't fix the test case as it should but it fixes the symptom in FOP Trunk. But better do it right. That's why I didn't commit the fix.
        Hide
        Manuel Mall added a comment -

        Claude,

        thank you for the problem report. I had a quick look at it and can confirm that
        it appears to be a bug in Fop 0.91.

        Technical background: The Knuth sequences generated for a NBSP do not actually
        prevent (in some cases at least) for the line to be broken at the NBSP. In
        TextLayoutManager.createElementsForASpace when a NBSP is encountered a normal
        sequence as for an ordinary space is generated and simply prefixed with an
        infinite penalty. This is not enough to prevent breaks within some of the
        sequences. However, it needs some more thought on how to best fix it.

        Show
        Manuel Mall added a comment - Claude, thank you for the problem report. I had a quick look at it and can confirm that it appears to be a bug in Fop 0.91. Technical background: The Knuth sequences generated for a NBSP do not actually prevent (in some cases at least) for the line to be broken at the NBSP. In TextLayoutManager.createElementsForASpace when a NBSP is encountered a normal sequence as for an ordinary space is generated and simply prefixed with an infinite penalty. This is not enough to prevent breaks within some of the sequences. However, it needs some more thought on how to best fix it.
        Hide
        Claude Paroz added a comment -

        Attachment Chap1.fo has been added with description: fo source for reproducing bug

        Show
        Claude Paroz added a comment - Attachment Chap1.fo has been added with description: fo source for reproducing bug

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development