FOP
  1. FOP
  2. FOP-1985

Extra spacing between characters while rendering text output

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: unqualified
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: PC
    • External issue ID:
      52114

      Description

      Some font sizes, such as 10 pt, seem to produce good output. However, when other font sizes are used, spacing on <inlines> becomes unpredictable.

      1. apos_wrap.txt
        0.3 kB
        Shawn
      2. apos_wrap.fo
        0.5 kB
        Shawn
      3. apos_wrap_alt.txt
        0.2 kB
        Shawn
      4. apos_wrap_alt.fo
        0.5 kB
        Shawn

        Activity

        Hide
        Shawn added a comment -

        Attachment apos_wrap.fo has been added with description: Example FO to recreate the problem

        Show
        Shawn added a comment - Attachment apos_wrap.fo has been added with description: Example FO to recreate the problem
        Hide
        Pascal Sancho added a comment -

        (In reply to comment #0)

        > Some font sizes, such as 10 pt, seem to produce good output. However, when
        > other font sizes are used, spacing on <inlines> becomes unpredictable.

        Can you give a more accurate description of what you get, I see nothing wrong on what I get (against either FOP 1.0 or FOR trunk).

        • what FOP version do you use?
        • diff between expected et get result?
        Show
        Pascal Sancho added a comment - (In reply to comment #0) > Some font sizes, such as 10 pt, seem to produce good output. However, when > other font sizes are used, spacing on <inlines> becomes unpredictable. Can you give a more accurate description of what you get, I see nothing wrong on what I get (against either FOP 1.0 or FOR trunk). what FOP version do you use? diff between expected et get result?
        Hide
        Pascal Sancho added a comment -

        forgot to change status

        Show
        Pascal Sancho added a comment - forgot to change status
        Hide
        Shawn added a comment -

        we are currently using version 0.95beta-1. We did test against the 1.0 version as well and it was still an issue for us.

        Basically the word with the apostrophes gets a bunch of extra spaces put in between them when producing text output

        Show
        Shawn added a comment - we are currently using version 0.95beta-1. We did test against the 1.0 version as well and it was still an issue for us. Basically the word with the apostrophes gets a bunch of extra spaces put in between them when producing text output
        Hide
        Pascal Sancho added a comment -

        One cause should be line breaks between inline elements in original FO.

        If this is the case, then the behavior is normal: line breaks are considered as blank spaces in XML content (unless explicitly specified LF treatment).

        Can you check that point?

        Show
        Pascal Sancho added a comment - One cause should be line breaks between inline elements in original FO. If this is the case, then the behavior is normal: line breaks are considered as blank spaces in XML content (unless explicitly specified LF treatment). Can you check that point?
        Hide
        Shawn added a comment -

        Sorry for the long delay, but I attached the original FO and i dont see any that in it.

        Show
        Shawn added a comment - Sorry for the long delay, but I attached the original FO and i dont see any that in it.
        Hide
        Glenn Adams added a comment -

        resolved invalid due to lack of information (PDF output file)

        Show
        Glenn Adams added a comment - resolved invalid due to lack of information (PDF output file)
        Hide
        Shawn added a comment -

        Could you provide additional questions? I thought I provided what was requested before.

        Show
        Shawn added a comment - Could you provide additional questions? I thought I provided what was requested before.
        Hide
        Glenn Adams added a comment -

        (In reply to comment #7)
        > Could you provide additional questions? I thought I provided what was requested
        > before.

        you have not provided a PDF output file produced by the version of FOP you are testing/using with the sample input file you did provide

        Show
        Glenn Adams added a comment - (In reply to comment #7) > Could you provide additional questions? I thought I provided what was requested > before. you have not provided a PDF output file produced by the version of FOP you are testing/using with the sample input file you did provide
        Hide
        Pascal Sancho added a comment -

        (In reply to comment #5)
        > Sorry for the long delay, but I attached the original FO and i dont see any
        > that in it.

        I see nothing wrong in PDF output, against FOP v0.95, v1.0, or trunk.
        So I persist that there are some extra spaces in your original XSL-FO that are not in your test case.

        As Glenn said, there is no output file or description, showing/explaining what is wrong.

        Show
        Pascal Sancho added a comment - (In reply to comment #5) > Sorry for the long delay, but I attached the original FO and i dont see any > that in it. I see nothing wrong in PDF output, against FOP v0.95, v1.0, or trunk. So I persist that there are some extra spaces in your original XSL-FO that are not in your test case. As Glenn said, there is no output file or description, showing/explaining what is wrong.
        Hide
        Shawn added a comment -

        Sorry for the delayed response. Here is an example TXT file FOP produced from the example FO file already attached. The issue is not producing PDF its producing plain text output. PDF is just fine. I apologize for the confusion. Is there anything else I can provide?

        Show
        Shawn added a comment - Sorry for the delayed response. Here is an example TXT file FOP produced from the example FO file already attached. The issue is not producing PDF its producing plain text output. PDF is just fine. I apologize for the confusion. Is there anything else I can provide?
        Hide
        Shawn added a comment -

        Attachment apos_wrap.txt has been added with description: Example TXT file that FOP produces

        Show
        Shawn added a comment - Attachment apos_wrap.txt has been added with description: Example TXT file that FOP produces
        Hide
        Glenn Adams added a comment -

        only fixed font usage is supported for the TXT renderer; see

        http://xmlgraphics.apache.org/fop/1.0/output.html#txt

        Show
        Glenn Adams added a comment - only fixed font usage is supported for the TXT renderer; see http://xmlgraphics.apache.org/fop/1.0/output.html#txt
        Hide
        Shawn added a comment -

        My FO is using a fixed width font (Courier). I updated it based on the recommendations on the page provided. I changed the font size and the line height and it made it even worse.

        Show
        Shawn added a comment - My FO is using a fixed width font (Courier). I updated it based on the recommendations on the page provided. I changed the font size and the line height and it made it even worse.
        Hide
        Shawn added a comment -

        Attachment apos_wrap_alt.fo has been added with description: Updated FO based based on recoomendations

        Show
        Shawn added a comment - Attachment apos_wrap_alt.fo has been added with description: Updated FO based based on recoomendations
        Hide
        Shawn added a comment -

        Attachment apos_wrap_alt.txt has been added with description: Output based on updated FO - Event worse

        Show
        Shawn added a comment - Attachment apos_wrap_alt.txt has been added with description: Output based on updated FO - Event worse
        Hide
        Glenn Adams added a comment -

        (In reply to comment #13)
        > Created attachment 28596 [details]
        > Output based on updated FO - Event worse

        (In reply to comment #11)
        > only fixed font usage is supported for the TXT renderer; see
        >
        > http://xmlgraphics.apache.org/fop/1.0/output.html#txt

        it appears the data in that page is out of date; please try font-size="10pt"; also, you may need to play with line-height; i reduced the page width to force line breaks, then experimented with line height to produce reasonable results; oddly, i found that line-height='6pt' seemed to work best when font-size was 10pt

        in any case, the caveat emptor found in the description of the TXT rendereer "The renderer is very limited, so do not be surprised if it gives unsatisfactory results." should be kept in mind

        Show
        Glenn Adams added a comment - (In reply to comment #13) > Created attachment 28596 [details] > Output based on updated FO - Event worse (In reply to comment #11) > only fixed font usage is supported for the TXT renderer; see > > http://xmlgraphics.apache.org/fop/1.0/output.html#txt it appears the data in that page is out of date; please try font-size="10pt"; also, you may need to play with line-height; i reduced the page width to force line breaks, then experimented with line height to produce reasonable results; oddly, i found that line-height='6pt' seemed to work best when font-size was 10pt in any case, the caveat emptor found in the description of the TXT rendereer "The renderer is very limited, so do not be surprised if it gives unsatisfactory results." should be kept in mind
        Hide
        Shawn added a comment -

        That definitely seemed to work. Thanks!

        I do need to know if this could potentially break existing text we might be sending through this renderer that come out looking just fine. If we made this change this would effectively be used for all plain text renderer we need to do. we could get any combination of text. Basically we hard code the font size, but allow the client to override it.

        We hard code it to 10.5 with no line height specified. Im trying to figure out if your recommendation should be our new default or if we should just instruct the client to override our default.

        Show
        Shawn added a comment - That definitely seemed to work. Thanks! I do need to know if this could potentially break existing text we might be sending through this renderer that come out looking just fine. If we made this change this would effectively be used for all plain text renderer we need to do. we could get any combination of text. Basically we hard code the font size, but allow the client to override it. We hard code it to 10.5 with no line height specified. Im trying to figure out if your recommendation should be our new default or if we should just instruct the client to override our default.
        Hide
        Glenn Adams added a comment -

        http://svn.apache.org/viewvc?view=revision&revision=1325394

        fixed bug in TXT renderer's handling of row height computation due to it not taking into account space before/after produced by leading (before and after)

        at this time, use of the following appears to produce desired results:

        font-family = "Courier"
        font-size = "10pt"
        line-height = "10pt"

        note that the default line height if not specified will be 1.2*font-size = 12pt, which will not produce the correct results

        also updated site documentation (which i will publish to apache shortly)

        Show
        Glenn Adams added a comment - http://svn.apache.org/viewvc?view=revision&revision=1325394 fixed bug in TXT renderer's handling of row height computation due to it not taking into account space before/after produced by leading (before and after) at this time, use of the following appears to produce desired results: font-family = "Courier" font-size = "10pt" line-height = "10pt" note that the default line height if not specified will be 1.2*font-size = 12pt, which will not produce the correct results also updated site documentation (which i will publish to apache shortly)
        Hide
        Shawn added a comment -

        Hey Glenn, it looks like you found a way to fix it? I don't suppose you could provide any more details about what you think was causing it could you?

        Also, will there be any issues if I don't specify a line height? The way our cod works today we typically are not specifying a line height. When looking at the result the text looks fine, but the space allocated for the height is certainly larger than what we need, but i don't necessarily see anything wrong with it.

        If it is fixed, do you have an anticipated release date? Or a version I could try out?

        Thanks a lot, I really appreciate it!

        Show
        Shawn added a comment - Hey Glenn, it looks like you found a way to fix it? I don't suppose you could provide any more details about what you think was causing it could you? Also, will there be any issues if I don't specify a line height? The way our cod works today we typically are not specifying a line height. When looking at the result the text looks fine, but the space allocated for the height is certainly larger than what we need, but i don't necessarily see anything wrong with it. If it is fixed, do you have an anticipated release date? Or a version I could try out? Thanks a lot, I really appreciate it!
        Hide
        Glenn Adams added a comment -

        (In reply to comment #17)
        > Hey Glenn, it looks like you found a way to fix it? I don't suppose you could
        > provide any more details about what you think was causing it could you?

        see the link i put in the prior comment, repeated here [1]:

        [1] http://svn.apache.org/viewvc?view=revision&revision=1325394

        > Also, will there be any issues if I don't specify a line height? The way our
        > cod works today we typically are not specifying a line height.

        yes, as i indicate, the default line height is 1.2*font-size, so that will produce incorrect row computation, resulting in unexpected blank lines on TXT rendering; note that since line-height is inheritable, you only need to specify it once, e.g., on fo:flow or on fo:page-sequence or fo:root, to have it inherited by descendant fo:blocks

        > When looking at
        > the result the text looks fine, but the space allocated for the height is
        > certainly larger than what we need, but i don't necessarily see anything wrong
        > with it.
        >
        > If it is fixed, do you have an anticipated release date? Or a version I could
        > try out?

        the fix will be incorporated into the nightly builds [2] and the upcoming FOP1.1 release (no date set)

        [2] http://ci.apache.org/projects/xmlgraphics/fop/snapshots/

        > Thanks a lot, I really appreciate it!

        Show
        Glenn Adams added a comment - (In reply to comment #17) > Hey Glenn, it looks like you found a way to fix it? I don't suppose you could > provide any more details about what you think was causing it could you? see the link i put in the prior comment, repeated here [1] : [1] http://svn.apache.org/viewvc?view=revision&revision=1325394 > Also, will there be any issues if I don't specify a line height? The way our > cod works today we typically are not specifying a line height. yes, as i indicate, the default line height is 1.2*font-size, so that will produce incorrect row computation, resulting in unexpected blank lines on TXT rendering; note that since line-height is inheritable, you only need to specify it once, e.g., on fo:flow or on fo:page-sequence or fo:root, to have it inherited by descendant fo:blocks > When looking at > the result the text looks fine, but the space allocated for the height is > certainly larger than what we need, but i don't necessarily see anything wrong > with it. > > If it is fixed, do you have an anticipated release date? Or a version I could > try out? the fix will be incorporated into the nightly builds [2] and the upcoming FOP1.1 release (no date set) [2] http://ci.apache.org/projects/xmlgraphics/fop/snapshots/ > Thanks a lot, I really appreciate it!

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development