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).
excuse me, where it says embed="file:gothic.ttf" please read embed-url="file:gothic.ttf"
Erm erm erm, any news on this one? Tx /Jeroen
(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".
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.
(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.
This bug should be fixed/addressed by [PATCH] http://issues.apache.org/bugzilla/show_bug.cgi?id=41514
Should be fixed in rev. 507539.
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed