Fop
  1. Fop
  2. FOP-1489

relative font-size (smaller/larger) does not work with percentages

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: 0.94
    • Fix Version/s: None
    • Component/s: pdf
    • Labels:
      None
    • Environment:
      Operating System: Windows XP
      Platform: PC
    • External issue ID:
      44343

      Description

      Error occurs in the combination of <fo:inline> of font-size="smaller"/"bigger"
      within <fo:block> of font-size in percentage. The error is "getBaselength
      called without context".

      <fo:block font-style="normal" font-size="80%" role="html:div"
      <fo:inline baseline-shift="super" font-size="smaller"
      role="html:sup">th</fo:inline>of each month.
      </fo:block>

      =====Original Post on fop-users mailing list===========
      On Feb 1, 2008, at 18:36, Li, Hao wrote:

      > You are right. The sample I posted actually works. I apologize not
      > recognizing the real problem. It is tricky and only occurs in the
      > combination of <fo:inline> of font-size="smaller"/"bigger" within
      > <fo:block> of font-size in percentage:

      OK, now I see it too.

      I'll run it through the debugger, but already think I know what is going on.
      The property resolution mechanism tries to resolve to smaller/larger font-
      sizes too early. Percentages are resolved (mostly
      anyway) during the layout-stage, where FOP tries to already resolve
      the "smaller" keyword long before that.

      I haven't tried yet, but using em's could also lead to trouble in combination
      with percentages, as in:

      <fo:block>
      <fo:block font-size="80%">
      <fo:inline font-size="8em">

      Will keep you posted.

      Cheers

      Andreas

        Activity

        Hide
        Andreas L. Delmelle added a comment -

        Already had a quick look, and just one question.
        Does FOP also hang on your end? FOP Trunk indeed shows the error you mention, then simply hangs
        here... Seems like this is going to take some time figuring out.

        Show
        Andreas L. Delmelle added a comment - Already had a quick look, and just one question. Does FOP also hang on your end? FOP Trunk indeed shows the error you mention, then simply hangs here... Seems like this is going to take some time figuring out.
        Hide
        Andreas L. Delmelle added a comment -

        (In reply to comment #1)
        > ... Seems like this is going to take some time figuring out.

        I take that back. Already found the related piece of code.

        For other interested parties: in case the parent's font-size is a percentage, the getValue() call in
        FontSizePropertyMaker.convertProperty() returns a base-size of 0. This case does not seem to be
        catered for in the loop in computeClosestAbsoluteFontSize() a bit further below, which becomes infinite
        so the method never returns.

        It seems like percentage font-sizes can already be resolved at parse-time. There seems to be no need
        to create PercentLengths and delay the resolution until the layout-context is available. I'm going to
        investigate this. In the meantime, if anyone has ideas or insights... always welcome.

        Show
        Andreas L. Delmelle added a comment - (In reply to comment #1) > ... Seems like this is going to take some time figuring out. I take that back. Already found the related piece of code. For other interested parties: in case the parent's font-size is a percentage, the getValue() call in FontSizePropertyMaker.convertProperty() returns a base-size of 0. This case does not seem to be catered for in the loop in computeClosestAbsoluteFontSize() a bit further below, which becomes infinite so the method never returns. It seems like percentage font-sizes can already be resolved at parse-time. There seems to be no need to create PercentLengths and delay the resolution until the layout-context is available. I'm going to investigate this. In the meantime, if anyone has ideas or insights... always welcome.
        Hide
        Andreas L. Delmelle added a comment -

        Fixed in FOP Trunk.

        see: http://svn.apache.org/viewvc?rev=617708&view=rev

        Thanks for reporting.

        Show
        Andreas L. Delmelle added a comment - Fixed in FOP Trunk. see: http://svn.apache.org/viewvc?rev=617708&view=rev Thanks for reporting.
        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:
            li hao
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development