[xep-support] ZapfDingbats.afm

Bob Stayton bobs at sagehill.net
Wed May 13 12:13:41 PDT 2009


> Hence, any application which claims support for PDF must be able

> to display/print files that contain references to ZapfDingbat fonts

> without those fonts being embedded. If it cannot, it is not a PDF 

> compliant application.



And indeed there are such situations.  I've worked with a print vendor for hard copy reproduction who will accept PDF files, but they require that *all* fonts be embedded, including the base 14.  They said they don't want to risk any possibility of font substitution, and that if all fonts are embedded, they can guarantee that their output will match your review of the PDF file.  This same company owns the entire Adobe font collection for their own composition purposes, but won't apply them to PDF files from customers.  I suspect they are in cahoots with Adobe to sell more Zapf Dingbats.  8^)



Bob Stayton
Sagehill Enterprises
bobs at sagehill.net


  ----- Original Message ----- 
  From: Kevin Brown 
  To: xep-support at renderx.com 
  Sent: Wednesday, May 13, 2009 10:11 AM
  Subject: RE: [xep-support] ZapfDingbats.afm


  No. In order to embed a Base font you must obtain the font data. RenderX only distributes the font metrics. These are not free, you would need to purchase a ZapfDingbat font.

   

  However, no application should require and Base 14 fonts to be embedded and claim that it is PDF consumer application unless they are being embedded for a specific application of the PDF specification such as PDF/A. In other words, you client is wrong unless they are producing PDF/A which requires all fonts to be embedded (for historical archiving). 

   

  A good brief summary is here at Wikipedia (http://en.wikipedia.org/wiki/PDF) under the heading Base 14 fonts. 

   

  Also, Chapter 2 of the PDF Reference, page 40 states:

   

  "• PDF prescribes a set of 14 standard fonts that can be used without prior defini-

  tion. These include four faces each of three Latin text typefaces (Courier, 

  Helvetica*, and Times*), as well as two symbolic fonts (Symbol and ITC Zapf 

  Dingbats®). 

   

  These fonts, or suitable substitute fonts with the same metrics, are 

  required to be available in all PDF consumer applications."

   

  Hence, any application which claims support for PDF must be able to display/print files that contain references to ZapfDingbat fonts without those fonts being embedded. If it cannot, it is not a PDF compliant application.

   

  Kevin

   

  From: owner-xep-support at renderx.com [mailto:owner-xep-support at renderx.com] On Behalf Of Cutter
  Sent: Wednesday, May 13, 2009 9:11 AM
  To: xep-support at renderx.com
  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 at renderx.com [mailto:owner-xep-support at renderx.com] On Behalf Of ben.m.wynn at rrd.com
  Sent: Wednesday, May 13, 2009 11:00 AM
  To: xep-support at 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 at gmail.com> 
        Sent by: owner-xep-support at renderx.com 

        05/12/2009 10:52 PM 

              Please respond to
              xep-support at renderx.com
             
       To
             xep-support at 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! 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.renderx.com/pipermail/xep-support/attachments/20090513/71f51617/attachment.html>


More information about the Xep-support mailing list