FOP
  1. FOP
  2. FOP-2045

[PATCH] block container overflow error message

    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: All
    • External issue ID:
      53094

      Description

      If a block-container element has the overflow attribute set to error-if-overflow and the content inside the container does overflow then FOP:

      • throws an exception if the overflow is BPD (block progression direction)
      • emits a warning if the overflow is IPD (inline progression direction)
        The attached patch tries to fix this inconsistency in behavior by issuing an error message in both cases; also, if the overflow attribute is set to something else, a warning message is issued instead.
      1. block_container_overflow.patch
        12 kB
        Luis Bernardo
      2. resources.tar.gz
        6 kB
        Luis Bernardo

        Activity

        Hide
        Luis Bernardo added a comment -

        Attachment block_container_overflow.patch has been added with description: patch

        Show
        Luis Bernardo added a comment - Attachment block_container_overflow.patch has been added with description: patch
        Hide
        Luis Bernardo added a comment -

        Attachment resources.tar.gz has been added with description: test case and output

        Show
        Luis Bernardo added a comment - Attachment resources.tar.gz has been added with description: test case and output
        Hide
        Luis Bernardo added a comment -

        The attached files are:

        • a test.fo file to check the issue
        • the console output before and after the fix
        • the PDF output file
        Show
        Luis Bernardo added a comment - The attached files are: a test.fo file to check the issue the console output before and after the fix the PDF output file
        Hide
        Glenn Adams added a comment -

        patch landed at http://svn.apache.org/viewvc?rev=1327157&view=rev

        thanks, and good work luis!

        Show
        Glenn Adams added a comment - patch landed at http://svn.apache.org/viewvc?rev=1327157&view=rev thanks, and good work luis!
        Hide
        Vincent Hennebert added a comment -

        The inconsistency is still there if the overflow property has been set on a region (e.g., region-before).

        The overflow shouldn't be handled by LineLM at all as that class does not have the necessary information to decide whether to issue a warning or throw an error. Some overflow event should instead be triggered on its parent LM that will handle it if it can, or pass it on to its parent and so on.

        Vincent

        Show
        Vincent Hennebert added a comment - The inconsistency is still there if the overflow property has been set on a region (e.g., region-before). The overflow shouldn't be handled by LineLM at all as that class does not have the necessary information to decide whether to issue a warning or throw an error. Some overflow event should instead be triggered on its parent LM that will handle it if it can, or pass it on to its parent and so on. Vincent
        Hide
        Glenn Adams added a comment -

        (In reply to comment #3)
        > The inconsistency is still there if the overflow property has been set on a
        > region (e.g., region-before).
        >
        > The overflow shouldn't be handled by LineLM at all as that class does not have
        > the necessary information to decide whether to issue a warning or throw an
        > error. Some overflow event should instead be triggered on its parent LM that
        > will handle it if it can, or pass it on to its parent and so on.

        luis, can you provide a new patch to address this?

        Show
        Glenn Adams added a comment - (In reply to comment #3) > The inconsistency is still there if the overflow property has been set on a > region (e.g., region-before). > > The overflow shouldn't be handled by LineLM at all as that class does not have > the necessary information to decide whether to issue a warning or throw an > error. Some overflow event should instead be triggered on its parent LM that > will handle it if it can, or pass it on to its parent and so on. luis, can you provide a new patch to address this?
        Hide
        Luis Bernardo added a comment -

        sure, but this patch was intentionally of limited scope. as the title and the description says, it was only meant to address the inconsistency in error/warn messages in a block container with the overflow attribute set to error-if-overflow. the fact that it does not address possible similar inconsistencies when overflow happens in other elements is not a surprise. in fact I knew it didn't address that. nevertheless, I do agree that extending this patch to handle some other overflow situations is a good idea and I will look into that.

        for testing purposes then, it would be helpful to have a sample FO file that causes all kinds of overflows messages meant to be handled by the new patch. so Vincent, since you raised the issue, would you like to provide the example FO file?

        Show
        Luis Bernardo added a comment - sure, but this patch was intentionally of limited scope. as the title and the description says, it was only meant to address the inconsistency in error/warn messages in a block container with the overflow attribute set to error-if-overflow. the fact that it does not address possible similar inconsistencies when overflow happens in other elements is not a surprise. in fact I knew it didn't address that. nevertheless, I do agree that extending this patch to handle some other overflow situations is a good idea and I will look into that. for testing purposes then, it would be helpful to have a sample FO file that causes all kinds of overflows messages meant to be handled by the new patch. so Vincent, since you raised the issue, would you like to provide the example FO file?
        Hide
        Glenn Adams added a comment -

        i would rather close this bug and open a new bug to address a similar problem in region-*; that new bug can include a reference to this bug in its descriptive information

        Show
        Glenn Adams added a comment - i would rather close this bug and open a new bug to address a similar problem in region-*; that new bug can include a reference to this bug in its descriptive information

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development