xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 40120] New: - font-base wrongly interpreted when embedding font and input in folder
Date Wed, 26 Jul 2006 18:29:12 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40120>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40120

           Summary: font-base wrongly interpreted when embedding font and
                    input in folder
           Product: Fop
           Version: 0.92
          Platform: PC
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: general
        AssignedTo: fop-dev@xmlgraphics.apache.org
        ReportedBy: jmeijer@notice.nu


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).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Mime
View raw message