Yes, in this case, it is too simple. 8^)
XEP ships with the font metrics for the base 14 fonts (the .afm files in the fonts subdirectory of XEP's installation area), but it does not include the font outlines (the .pfb files), which must be available to XEP in order to embed the fonts. With just the .afm files, XEP can position the characters properly, but the actual glyph must be available on the rendering device to show it. As far as I know, most PDF browsers and printers have the base 14 font glyphs, but apparently that is not your case. For Zapf Dingbats, whoever is generating the PDF must purchase the font from Adobe to get the font outlines so they can be embedded.
Bob Stayton
Sagehill Enterprises
bobs@sagehill.net
----- Original Message -----
From: Cutter
To: xep-support@renderx.com
Sent: Wednesday, May 13, 2009 9:11 AM
Subject: RE: [xep-support] ZapfDingbats.afm
If that is the case is the solution as simple as changing this line
<font-group label=”Base 14” embed=”false”>
To
<font-group label=”Base 14” embed=”true”>
That seems too simple.
From: owner-xep-support@renderx.com [mailto:owner-xep-support@renderx.com] On Behalf Of ben.m.wynn@rrd.com
Sent: Wednesday, May 13, 2009 11:00 AM
To: xep-support@renderx.com
Subject: Re: [xep-support] ZapfDingbats.afm
Hi Cutter,
From reading both your emails, your problem lies in the default configuration of your 'xep.xml'... which includes ZapfDingbats, but not as an embedded font.
Your clients quoted sentence is correct, as far as I know. A PDF file is not a raster image like TIFF, any text data it includes must be rendered with a font... That font must be made available to it somehow: either installed on the system or embedded in the PDF itself.
The xep.xml configuration file controls which fonts will be embedded in a pdf. The default xep.xml configures a 'Base 14' set of fonts that are expected to be available everywhere without embedding it, so to save space, do not embed it. These fonts include Times, Helvetica, etc... and I believe ZapfDingbats as well.
Your best bet is to go reconfigure your (and your clients) xep.xml to embed the ZapfDingbats into the PDF. Make sure you have license to embed it, I havn't looked at it recently to know if it's public domain or otherwise freely distributable, but it's one of the 'Base 14' that is expected to be available anywhere.
-Ben
Cutter <cutter1994@gmail.com>
Sent by: owner-xep-support@renderx.com
05/12/2009 10:52 PM
Please respond to
xep-support@renderx.com
To
xep-support@renderx.com
cc
Subject
[xep-support] ZapfDingbats.afm
I am using XEP (unsure of the version #) to create PDF from XSLT. The output looks correct on my system but when the client runs the same XSLT/FO (using a different version of XEP, unsure what #) none of the ZapfDingbats characters output. We have gone round and round about this but currently the client is coming back with “If the font is not embedded, the rendered file can only be viewed on systems that have the font configured for use with viewing or printing the application.”
My understanding is, once the PDF is rendered, and unless it is then reopened in some program capable of editing it, the PDF is set in stone. So any PDF viewer on any machine (Linux, Mac, Windows) with any (or no) fonts installed will show it as rendered. The problem with rendering the font is located on the machine doing the rendering not the machines later doing the viewing. Is this correct and could someone explain the quoted sentence above with an example?
What else might be making their rendering not output the correct fonts while my output (using the exact same transformations) renders correctly?
Thanks!
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html
Received on Wed May 13 10:38:05 2009
This archive was generated by hypermail 2.1.8 : Wed May 13 2009 - 10:38:06 PDT