FOP
  1. FOP
  2. FOP-1105

exception: border-style (shorthand)

    Details

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

      Description

      when using the border-style="solid" shorthand i get a
      Exception
      java.lang.ClassCastException

      using the four separate properties (border-before-style, ...) works ok.

      1. dorfchronik.fo
        3 kB
        gerhard oettl

        Issue Links

          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
          Manuel Mall added a comment -
              • FOP-1158 has been marked as a duplicate of this bug. ***
          Show
          Manuel Mall added a comment - FOP-1158 has been marked as a duplicate of this bug. ***
          Hide
          Manuel Mall added a comment -

          Fixed, actually more a hack/workaround.

          See: http://svn.apache.org/viewcvs?rev=359364&view=rev and
          http://svn.apache.org/viewcvs?rev=359368&view=rev

          Sorry, messed up the commits so the bug fix is spread over two svn commits.

          Show
          Manuel Mall added a comment - Fixed, actually more a hack/workaround. See: http://svn.apache.org/viewcvs?rev=359364&view=rev and http://svn.apache.org/viewcvs?rev=359368&view=rev Sorry, messed up the commits so the bug fix is spread over two svn commits.
          Hide
          Luca Furini added a comment -

          Sorry for not answering before, today I hope I'll be able to find some time to
          look at this.
          Thanks to you all, the problem has already been defined with precision.

          As Manuel rightly said, however, we should rethink this part of the process in
          order to solve this kind of problem once and for all.

          Show
          Luca Furini added a comment - Sorry for not answering before, today I hope I'll be able to find some time to look at this. Thanks to you all, the problem has already been defined with precision. As Manuel rightly said, however, we should rethink this part of the process in order to solve this kind of problem once and for all.
          Hide
          Manuel Mall added a comment -

          The problem is (again) that the breaking text into lines and words logic
          crosses inline boundaries and our nested inline processing is getting really in
          the way. To get around this the code has to 'jump through hoops'. In this case
          the Knuth sequences returned by getNextKnuthElement are used to reverse
          engineer words which extend over an inline boundary. This in turn needs to be
          done to determine if an additional letter space needs to be added as the
          individual LMs don't do that at a boundary because they don't know if they
          start/end at the beginning/end of a word or in the middle of a word.

          Of course this "ranting" about the problem will not get us a solution. In the
          very short term may be Luca can have a look at this as he as fixed a similar
          problem before in a related area.

          After that we really need to redesign the line breaking stuff. Not the Knuth
          approach (and the implemented algorithms related to that) but the way we arrive
          at the Knuth sequences and iterate and process the text elements. This needs to
          be done to be able to do white-space-treatment, UAX#14 line breaking, start-
          /end- space resolution and generally to be able to handle some more aspects of
          Unicode (e.g. glyph merging).

          Show
          Manuel Mall added a comment - The problem is (again) that the breaking text into lines and words logic crosses inline boundaries and our nested inline processing is getting really in the way. To get around this the code has to 'jump through hoops'. In this case the Knuth sequences returned by getNextKnuthElement are used to reverse engineer words which extend over an inline boundary. This in turn needs to be done to determine if an additional letter space needs to be added as the individual LMs don't do that at a boundary because they don't know if they start/end at the beginning/end of a word or in the middle of a word. Of course this "ranting" about the problem will not get us a solution. In the very short term may be Luca can have a look at this as he as fixed a similar problem before in a related area. After that we really need to redesign the line breaking stuff. Not the Knuth approach (and the implemented algorithms related to that) but the way we arrive at the Knuth sequences and iterate and process the text elements. This needs to be done to be able to do white-space-treatment, UAX#14 line breaking, start- /end- space resolution and generally to be able to handle some more aspects of Unicode (e.g. glyph merging).
          Hide
          Jeremias Maerki added a comment -

          Thanks, Gerhard! You're a very good bug hunter!

          I've been able to isolate the problem into a test case which I've just added to
          the repository:
          http://svn.apache.org/viewcvs?rev=351460&view=rev

          Looks like a more fine-grained method is needed to identify certain element
          patterns. addALetterSpace() wants to remove a certain pattern but failed to
          realize that the preceding box is representing a border element from the inline.
          Inline element list experts, please do your magic. Otherwise, I'll try to figure
          out a solution when my brain is fresh.

          Show
          Jeremias Maerki added a comment - Thanks, Gerhard! You're a very good bug hunter! I've been able to isolate the problem into a test case which I've just added to the repository: http://svn.apache.org/viewcvs?rev=351460&view=rev Looks like a more fine-grained method is needed to identify certain element patterns. addALetterSpace() wants to remove a certain pattern but failed to realize that the preceding box is representing a border element from the inline. Inline element list experts, please do your magic. Otherwise, I'll try to figure out a solution when my brain is fresh.
          Hide
          gerhard oettl added a comment -

          Attachment dorfchronik.fo has been added with description: examples

          Show
          gerhard oettl added a comment - Attachment dorfchronik.fo has been added with description: examples
          Hide
          gerhard oettl added a comment -

          i sayed that it works with separate properties - thats not true. The point
          seems to be the border-end-style in a inline-object. Here an example fo with
          one working and one not working paragraph.

          Show
          gerhard oettl added a comment - i sayed that it works with separate properties - thats not true. The point seems to be the border-end-style in a inline-object. Here an example fo with one working and one not working paragraph.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development