FOP
  1. FOP
  2. FOP-1217

font-base wrongly interpreted when embedding font and input in folder

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: 0.92
    • Fix Version/s: None
    • Component/s: unqualified
    • Labels:
      None
    • Environment:
      Operating System: other
      Platform: PC
    • External issue ID:
      40120

      Description

      Environment: jre1.5.0_06, any fo (or xml-xsl) file rendered to pdf using a non
      standard and embedded font.
      Under the following conditions:

      • NOT specifying a font-base in the userconfig
      • Specifying base as "." (probably irrelevant)
      • Embedding a font through userconfig.xml, assuming the current directory for
        both the .ttf as well as the metrics xml, ie embed="file:gothic.ttf" and of
        course those font files sitting there
      • Actually using that font in the fo
      • the fo (or xml in a xml/xsl setup) being in a separate folder (ie fop "-fo
        store/my.fo"). The file being specified relatively to the current directory is
        probably irrelevant.

      the resulting pdf is generated without complained, but actually does not have
      the .ttf embedded, resulting in a font not found when opening the pdf. Further
      investigating showed if the .ttf is ALSO copied to the relative path of the
      source .fo (or xml), it DOES embed in the pdf.

      Main problem is the renderer does not complain, combined with the fop
      documentation stating "(font-base) specifies the base URL based on which
      relative font URLs will be resolved. If not specified defaults to the base URL
      above", which is obvisouly not true when the source file is in a folder.

      Workaround is to specify a font-base in the userconfig, even if it's a simple
      ".". Refering to the .ttf in an absolute way worked too (eeww).

        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
        Vincent Hennebert added a comment -

        Should be fixed in rev. 507539.

        Show
        Vincent Hennebert added a comment - Should be fixed in rev. 507539.
        Hide
        Adrian Cumiskey added a comment -

        This bug should be fixed/addressed by [PATCH]
        http://issues.apache.org/bugzilla/show_bug.cgi?id=41514

        Show
        Adrian Cumiskey added a comment - This bug should be fixed/addressed by [PATCH] http://issues.apache.org/bugzilla/show_bug.cgi?id=41514
        Hide
        Simon Pepping added a comment -

        (In reply to comment #4)
        > Oh gosh, that solved the problem too, just as my workaround did. I keep on being
        > confused about url's and uri's, esp when it is file based. Thank you.
        >
        > But..... I still think it's a bug as using the "file:xxx.ttf" form it will
        > generate a pdf without any complaint and the resulting file doesn't work. There
        > is probably a semantic explanation why that behavior is completely valid, but
        > still. Anyway, no big deal as the issue can be fixed/worked around. I humbly
        > suggest at least an error message if the format given in this specific scenario
        > leads to a crippled PDF file.

        It is a bug if "file:xxx.ttf" is silently accepted and leads to a useless result
        file. It is an erroneous URI and should be signalled as such.

        Show
        Simon Pepping added a comment - (In reply to comment #4) > Oh gosh, that solved the problem too, just as my workaround did. I keep on being > confused about url's and uri's, esp when it is file based. Thank you. > > But..... I still think it's a bug as using the "file:xxx.ttf" form it will > generate a pdf without any complaint and the resulting file doesn't work. There > is probably a semantic explanation why that behavior is completely valid, but > still. Anyway, no big deal as the issue can be fixed/worked around. I humbly > suggest at least an error message if the format given in this specific scenario > leads to a crippled PDF file. It is a bug if "file:xxx.ttf" is silently accepted and leads to a useless result file. It is an erroneous URI and should be signalled as such.
        Hide
        Jeroen added a comment -

        Oh gosh, that solved the problem too, just as my workaround did. I keep on being
        confused about url's and uri's, esp when it is file based. Thank you.

        But..... I still think it's a bug as using the "file:xxx.ttf" form it will
        generate a pdf without any complaint and the resulting file doesn't work. There
        is probably a semantic explanation why that behavior is completely valid, but
        still. Anyway, no big deal as the issue can be fixed/worked around. I humbly
        suggest at least an error message if the format given in this specific scenario
        leads to a crippled PDF file.

        Thanks Simon for pointing out! Won't change the status as I don't know if the
        developers will incorporate that.

        Show
        Jeroen added a comment - Oh gosh, that solved the problem too, just as my workaround did. I keep on being confused about url's and uri's, esp when it is file based. Thank you. But..... I still think it's a bug as using the "file:xxx.ttf" form it will generate a pdf without any complaint and the resulting file doesn't work. There is probably a semantic explanation why that behavior is completely valid, but still. Anyway, no big deal as the issue can be fixed/worked around. I humbly suggest at least an error message if the format given in this specific scenario leads to a crippled PDF file. Thanks Simon for pointing out! Won't change the status as I don't know if the developers will incorporate that.
        Hide
        Simon Pepping added a comment -

        (In reply to comment #1)
        > embed-url="file:gothic.ttf"
        Is this a valid URI? I think it should read either embed-url="gothic.ttf" or
        embed-url="file:/path/to/gothic.ttf".

        Show
        Simon Pepping added a comment - (In reply to comment #1) > embed-url="file:gothic.ttf" Is this a valid URI? I think it should read either embed-url="gothic.ttf" or embed-url="file:/path/to/gothic.ttf".
        Hide
        Jeroen added a comment -

        Erm erm erm, any news on this one? Tx /Jeroen

        Show
        Jeroen added a comment - Erm erm erm, any news on this one? Tx /Jeroen
        Hide
        Jeroen added a comment -

        excuse me, where it says

        embed="file:gothic.ttf"

        please read

        embed-url="file:gothic.ttf"

        Show
        Jeroen added a comment - excuse me, where it says embed="file:gothic.ttf" please read embed-url="file:gothic.ttf"
        Jeroen created issue -

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development