Using output encoding "UTF-8" PDFlib GmbH München, Germany www.pdflib.com FontReporter 1.3 ® A plugin for analyzing fonts in PDF Copyright © 2005-2008 PDFlib GmbH. All rights reserved. PDFlib GmbH Franziska-Bilek-Weg 9, 80339 München, Germany www.pdflib.com This publication and the information herein is furnished as is, is subject to change without notice, and should not be construed as a commitment by PDFlib GmbH. PDFlib GmbH assumes no responsibility or liability for any errors or inaccuracies, makes no warranty of any kind (express, implied or statutory) with respect to this publication, and expressly disclaims any and all warranties of merchantability, fitness for particular purposes and noninfringement of third party rights. Adobe, Acrobat, and PostScript are trademarks of Adobe Systems Inc. AIX, IBM, OS/390, WebSphere, iSeries, and zSeries are trademarks of International Business Machines Corporation. ActiveX, Microsoft, Windows, and Windows NT are trademarks of Microsoft Corporation. Apple, Macintosh and TrueType are trademarks of Apple Computer, Inc. Unicode and the Unicode logo are trademarks of Unicode, Inc. Unix is a trademark of The Open Group. Java and Solaris are a trademark of Sun Microsystems, Inc. Other company product and service names may be trademarks or service marks of others. Thank you for using PDFlib FontReporter, a free Acrobat plugin provided by PDFlib GmbH. PDFlib GmbH offers software for creating and processing PDF documents. Please visit our Web site to learn more about our products. You can use PDFlib FontReporter free of charge; however, it is not in the public domain. This software cannot be sold or redistributed (whether for a fee or at no charge), either stand-alone or in combination with any other product, without the express written permission of PDFlib GmbH. Although PDFlib FontReporter is not a commercial product, we strive to provide high quality. If you run into problems you are encouraged to contact us at support@pdflib.com. Contents 1 Installing PDFlib FontReporter 5 2 Working with FontReporter 7 2.1 What can you do with FontReporter? 7 2.2 Overview of PDF Font Formats 9 2.3 Contents of a Font Report 11 2.4 Investigate PDF Problems with FontReporter 14 2.5 Error Messages 15 A Revision History 17 Contents 3 4 Contents 1 Installing PDFlib FontReporter Requirements. The PDFlib FontReporter plugin works with Acrobat 6/7/8 Standard and Professional on Windows and Mac, and Acrobat 9 Standard, Pro and Pro Extended on Windows. The plugin doesn’t work with Acrobat Elements or any version of Acrobat Reader/Adobe Reader. Installing FontReporter on Windows. All plugin-related files must be copied to the subdirectory »PDFlib FontReporter« in the Acrobat plugin folder. This is done automatically by the plugin installer, but can also be done manually. A typical location of the plugin folder is as follows: C:\Program Files\Adobe\Acrobat 9.0\Acrobat\plug_ins\PDFlib FontReporter Installing FontReporter for Acrobat 6/7/8 on the Mac. With Acrobat 6/7/8 the plugin folder is not visible in the finder. Make sure that Acrobat is not running and follow these steps: > Extract the plugin files by double-clicking the disk image (.dmg). > Locate the Acrobat application icon in the finder. It is usually located in a folder which has a name similar to the following: /Applications/Adobe Acrobat 8.0 Professional > Single-click on the Acrobat application icon and select File, Get Info. > In the window that pops up click the triangle next to Plug-ins. > Click Add... and select the FontReporter folder from the folder which has been created in the first step. Note that this folder will not immediately show up in the list of plugins, but only when you open the info window next time. Multi-lingual Interface. FontReporter supports multiple languages in the user interface and generated font reports. Depending on the application language of Acrobat, FontReporter will choose its interface language automatically. Currently English and German interfaces are available. If Acrobat runs in any other language mode, Font- Reporter will use the English interface. Trouble-shooting. If the FontReporter plugin doesn’t seem to work, make sure that in Edit, Preferences, [General...], Startup the »Use only certified plug-ins« box is unchecked. Chapter 1: Installing PDFlib FontReporter 5 6 Chapter 1: Installing PDFlib FontReporter 2 Working with FontReporter 2.1 What can you do with FontReporter? FontReporter is a useful tool if you are interested in fonts within PDF documents. It provides font- and encoding-related information which will helps in a variety of situations: > analyze printing problems (e.g. a particular font causes printing errors) > investigate text extraction problems (e.g. copying text from a PDF results in garbage) > visualize Unicode mappings for a font > find flaws in the PDF creation workflow (e.g. printer driver converted a PostScript Type 1 font to Type 3) > test whether ToUnicode mapping tables (required for PDF/A compliance) are present > identify logos and symbols which are represented as text in a PDF > learn which fonts are contained in a PDF, and which glyphs they contain (e.g. the file size is too large because some fonts ended up in the PDF unintentionally) > check font subsets to see which glyphs are contained in the subset > learn more about PDF font technology Using FontReporter is as easy as bringing up the menu Plug-Ins, PDFlib FontReporter..., Create Font Report in Acrobat. This will create a font report for all pages of the current PDF document as a separate PDF. Two pages from typical font reports are shown in Figure 2.1. Fig. 2.1 Sample font reports Chapter 2: Working with FontReporter 7 Supported PDF and font formats. FontReporter supports all PDF versions up to PDF 1.8, the file format created by Acrobat 9. All font and encoding formats available in PDF are supported, as well as all types of embedded font data. Advantages over Acrobat’s font properties panel. All versions of Acrobat including Adobe Reader provide font information via File, Document Properties..., Fonts. However, Acrobat’s font overview is limited in use; FontReporter provides the following advantages compared to Acrobat’s font list: > FontReporter provides much more information about each font > FontReporter deals with CJK font names even on Western systems > FontReporter provides glyph tables containing the glyphs of a font along with their widths, names, and Unicode values > FontReporter presents the output as a PDF document so that you can save or print it > FontReporter is guaranteed to process the full document, regardless of which pages have already been displayed in Acrobat PDF text extraction with PDFlib TET. FontReporter is an auxiliary tool to our PDFlib Text Extraction Toolkit (TET). TET is software for extracting the text contents of PDF documents. It is available both as a standalone program and a programming library/component which can be integrated into existing software. TET extracts text from all kinds of PDF documents and normalizes the text to Unicode. FontReporter can be used to create Unicode mapping tables for PDF documents which do not contain enough information for extracting text, or which contain wrong Unicode mapping tables. Fully functional evaluation versions of TET are available for download from www.pdflib.com. TET PDF IFilter. TET PDF IFilter extracts text and metadata from PDF documents and makes it available to search and retrieval software on Windows. This allows PDF documents to be searched on the local desktop, a corporate server, or the Web. TET PDF IFilter is based on the patented PDFlib Text Extraction Toolkit (TET). TET PDF IFilter is a robust implementation of Microsoft’s IFilter indexing interface. It works with all search and retrieval products which support the IFilter interface, e.g. SharePoint and SQL Server. Fully functional evaluation versions of TET PDF IFilter are available for download from www.pdflib.com. Free TET Plugin. The TET Plugin is a free companion to the FontReporter Plugin. It can be installed in Adobe Acrobat and allows interactive use of the Text Extraction Toolkit (TET) with any PDF document that is currently open in Acrobat. Using the TET plugin you can access TET’s functionality and experiment with TET options. The TET plugin can freely be downloaded from www.pdflib.com. 8 Chapter 2: Working with FontReporter A Revision History Revision history of this manual Date Changes July 3, 2008 > Minor changes for FontReporter 1.3 (new: support for Acrobat 9 on Windows) March 26, 2007 > Minor changes for FontReporter 1.2 (new: support for Acrobat 8 on Mac OS X) January 30, 2006 > Minor additions for FontReporter 1.1 February 14, 2005 > Initial version for FontReporter 1.0.0 Known problems in this version. We are currently aware of the following minor problems: > In rare cases the glyphs of Type 3 fonts may appear too small or too large, or not on the baseline. > Although PDF Producer entries with non-Latin characters will be displayed properly in the bookmarks, they will appear garbled in the overview page. > Sometimes not all glyph names are shown for simple fonts with the predefined encodings WinAnsi or MacRoman. > Glyph names for built-in encodings are not shown, nor those for custom encodings which are based on a font’s built-in encoding. > Unicode values will not be shown for CID fonts with standard CJK character collections and simple fonts with the predefined encodings WinAnsi or MacRoman. However, since these are fixed mappings no document-specific information is lost. A Revision History 17 Programs After Market Services (PAMS) Technical Documentation ������� ������ [NMP Part No.0275421 + 0275485] NSD–1 SERIES CELLULAR PHONES NSD–1 issue 2 : 09/00 Copyright � 1999. Nokia Mobile Phones Ltd. All Rights Reserved. NSD–1 Foreword PAMS Technical Documentation AMENDMENT RECORD SHEET Amendment Number Date Inserted By Comments 08/99 Issue 1 Issue 2 09/00 OJuntune General information: New variants NSD–1 FW/GW/AW, p.8 & 9 ARS added p.2 Issue 2 09/00 OJuntune System module: New variant NSD–1AW updated pages 1, 2, 5, 12 Issue 2 09/00 OJuntune System module schematic diagarams: 11 new A3 pages: 11 to 25 Issue2 09/00 OJuntune Product variants ARS added p.2 Issue 2 09/00 OJuntune UIF module: foreword warning p.3 added NSD–3AY assy parts added NSD–1FW, 1GW. 1AW data added, p. 7 to 10 ARS added v..6.3 parts list added p.15 Issue 2 09/00 OJuntune Parts list:: ARS p.2, 0201583, 0201577, 0201549 added 0201293, 0201294 updated Issue 2 09/00 OJuntune Troubleshooting instructions: ARS added, p.3 updated Page 2 � Nokia Mobile Phones Ltd. Issue 2 09/00 PAMS Technical Documentation NSD–1 Foreword CONTENTS: Foreword NSD–1 SERIES CELLULAR PHONES SERVICE MANUAL General Information System Module Part Lists (System Module) UI Module Product Variants Service Software and Tuning Instructions Service Tools Disassembly/Troubleshooting Instructions Handsfree Unit HFU–2 Non–serviceable Accessories Installation Instructions CARK–64 Installation Instructions CARK–91 Issue 2 09/00 � Nokia Mobile Phones Ltd. Page 3 NSD–1 Foreword PAMS Technical Documentation IMPORTANT This document is intended for use by qualified service personnel only. Company Policy Our policy is of continuous development; details of all technical modifications will be included with service bulletins. While every endeavour has been made to ensure the accuracy of this document, some errors may exist. If any errors are found by the reader, NOKIA MOBILE PHONES Ltd should be notified in writing. Please state: Title of the Document + Issue Number/Date of publication Latest Amendment Number (if applicable) Page(s) and/or Figure(s) in error Please send to: Nokia Mobile Phones Ltd PAMS Technical Documentation PO Box 86 24101 SALO Finland Page 4 � Nokia Mobile Phones Ltd. Issue 2 09/00 PAMS Technical Documentation NSD–1 Foreword Warnings and Cautions Please refer to the phone’s user guide for instructions relating to operation, care and maintenance including important safety information. Note also the following: Warnings: 1. CARE MUST BE TAKEN ON INSTALLATION IN VEHICLES FITTED WITH ELECTRONIC ENGINE MANAGEMENT SYSTEMS AND ANTI–SKID BRAKING SYSTEMS. UNDER CERTAIN FAULT CONDITIONS, EMITTED RF ENERGY CAN AFFECT THEIR OPERATION. IF NECESSARY, CONSULT THE VEHICLE DEALER/MANUFACTURER TO DETERMINE THE IMMUNITY OF VEHICLE ELECTRONIC SYSTEMS TO RF ENERGY. 2. THE HANDPORTABLE TELEPHONE MUST NOT BE OPERATED IN AREAS LIKELY TO CONTAIN POTENTIALLY EXPLOSIVE ATMOSPHERES EG PETROL STATIONS (SERVICE STATIONS), BLASTING AREAS ETC. 3. OPERATION OF ANY RADIO TRANSMITTING EQUIPMENT, INCLUDING CELLULAR TELEPHONES, MAY INTERFERE WITH THE FUNCTIONALITY OF INADEQUATELY PROTECTED MEDICAL DEVICES. CONSULT A PHYSICIAN OR THE MANUFACTURER OF THE MEDICAL DEVICE IF YOU HAVE ANY QUESTIONS. OTHER ELECTRONIC EQUIPMENT MAY ALSO BE SUBJECT TO INTERFERENCE. Cautions: 1. Servicing and alignment must be undertaken by qualified personnel only. 2. Ensure all work is carried out at an anti–static workstation and that an anti–static wrist strap is worn. 3. Ensure solder, wire, or foreign matter does not enter the telephone as damage may result. 4. Use only approved components as specified in the parts list. 5. Ensure all components, modules screws and insulators are correctly re–fitted after servicing and alignment. Ensure all cables and wires are repositioned correctly. 6. All PC’s used with NMP Service Software for this produce must be bios and operating system ”Year 2000 Compliant”. Issue 2 09/00 � Nokia Mobile Phones Ltd. Page 5 NSD–1 Foreword PAMS Technical Documentation This page intentionally left blank. Page 6 � Nokia Mobile Phones Ltd. Issue 2 09/00 Whitepaper:� PDF/A with PDFlib Products The PDF/A formats specified in the ISO 19005 standard strive to provide a consistent and robust subset of PDF which can safely be archived over a long period of time, or used for reliable data exchange in enterprise and government environments. This whitepaper discusses PDFlib features for creating PDF/A output suitable for long-term document archival. PDF/A-1a and PDF/A-1b. PDF/A-1, formally the international standard ISO 19005-1, is targeted at reliable long-time preservation of digital documents. The standard is based on PDF 1.4 and imposes some restrictions regarding the use of color, fonts, annotations, and other elements. There are two flavors of PDF/A-1, both of which can be created and processed with PDFlib products: > ISO 19005-1 Level B conformance (PDF/A-1b) ensures that the visual appearance of a document is preservable over the long term. Simply put, PDF/A-1b ensures that the document will look the same when it is viewed or printed some time in the future. > ISO 19005-1 Level A conformance (PDF/A-1a) is based on level B, but adds crucial properties from »Tagged PDF«: it requires structure information and reliable text semantics in order to preserve the document's logical structure and natural reading order. Simply put, PDF/A-1a not only ensures that the document will look the same when it is used in the future, but also that its contents (semantics) can be reliably interpreted and will be accessible to physically impaired users. When PDF/A without any conformance level is mentioned below, both conformance levels are meant. The PDF/A implementation in all PDFlib products is based on ISO 19005-1:2005 plus Technical Corrigendum 1 (2007). PDF/A requirements and restrictions. PDF/A requires certain PDF features and prohibits certain others. For example, in order to guarantee exact text reproduction, all fonts used in a document must be embedded; in order to guarantee exact color reproduction all colors must be specified in a device-independent way. Metadata must be embedded using the XMP format; encryption must not be used. In addition to these straight-forward requirements, however, PDF/A requires various other PDF features which are more subtle (e.g. certain entries in font data structures), and prohibits some critical structures (e.g. certain combinations of TrueType fonts and encodings). There are many aspects which must be implemented and checked by software developers before they arrive at fully standardconforming PDF/A products. PDF/A is much more than simply »PDF with embedded fonts«! PDF/A support in the PDFlib product family. PDFlib provides application developers with a toolkit which allows the following PDF/A-related operations: > Create PDF/A from scratch, e.g. based on text from a database > Convert raster images (e.g. scans) to PDF/A > Process existing PDF/A documents, e.g. merge or split > Create PDF/A-1a with structure information (Tagged PDF) > Attach XMP metadata to the generated documents, including the subtle topic of XMP extension schemas (see below). All of these operations can be implemented with simple PDFlib function calls. Sample code for a variety of programming languages and development environ- PDFlib GmbH 2008 - 08 www.pdflib.com 1 ments is provided with the PDFlib distribution. Additional programming techniques for PDF/A are available in the PDFlib Cookbook. Due to the significant overlap between PDF/A and the PDF/X standard (ISO 15930) for the graphics arts industry, the PDF/A support in PDFlib took advantage of the fact that we’ve been supporting various flavors of PDF/X for several years. To facilitate font embedding as required by PDF/A, the Japanese Resource Kit for the PDFlib Family offers common Japanese fonts with a license for embedding, as well as country-specific ICC profiles, CMaps, and documentation for Japanese users. Creating PDF/A-conforming output. Creating PDF/A-conforming output with PDFlib is achieved by the following means: > PDFlib automatically takes care of several formal settings for PDF/A, such as PDF version number and required XMP identification entries. > The PDFlib client program must explicitly use certain function calls and options (e.g. for font embedding). > The PDFlib client program must refrain from using certain other function calls and option settings (e.g. encryption). If the PDFlib client program obeys to these rules, valid PDF/A output is guaranteed. If PDFlib detects a violation of the PDF/A creation rules it will throw an exception which must be handled by the application. No PDF output will be created in case of an error; there is no danger of creating non-conforming output if an error occurs. Details of required and prohibited operations are discussed in the PDFlib documentation. Device-independent color specification. In order to maintain consistent color reproduction, PDF/A requires the use of device-independent color, usually achieved via ICC profiles or CIE Lab color specifications. The optional output intent describes the color characteristics of the document. While these concepts are widely used in the graphics arts industry, enterprise PDF developers are not necessarily familiar with color management. In this situation PDFlib makes it easy to create device-independent output regardless of the source of input data: > PDF/A output can be created with or without an ICC profile in the output intent. > In the common case of black text PDFlib will automatically choose an appropriate color space (Lab or DeviceGray) depending on whether or not an ICC profile for the output intent has been specified. > External ICC profiles and profiles embedded in images allow fine-grain color control. > ICC profiles for common application scenarios are provided with the PDFlib distribution so that valid PDF/A output can be achieved quickly. Raster images, e.g. TIFF and JPEG, play a vital role in document creation. Scanned paper documents and photographs from digital cameras are common examples of raster image data in document workflows. While in modern workflows raster image data may already be device-independent (usually by means of an embedded ICC color profile) and thus are PDF/A-compatible, legacy image data will in many cases be device-dependent, such as black-and-white or RGB scans without any associated ICC profile. PDFlib supports both situations: > ICC profiles embedded in raster image files will be honored. > External ICC profiles can be applied to an image. > As a fallback solution for legacy data of unknown origin PDFlib contains a builtin sRGB profile which matches many hardware and software environments. > By specifying an ICC profile for the output intent, device-dependent image data can be used without applying an ICC profile to the images. The PDFlib documentation discusses PDF/A color strategies for common application scenarios. 2 www.pdflib.com 2008 - 08 PDFlib GmbH XMP made easy. PDF/A mandates the use of XMP metadata for storing information about a document inside the PDF itself. XMP provides a powerful and flexible framework for storing standard and custom metadata (see also our separate whitepaper on XMP). If you already use XMP metadata in your workflow, you can create full XMP streams which PDFlib will integrate into the PDF/A output. However, developers who are not familiar with XMP are not required to delve into this vast topic. PDFlib will create the XMP output required for PDF/A, and will automatically map classic document info fields to the corresponding XMP constructs as mandated by the standard. As a result, developers who wish to do so can leverage the power of XMP, while PDFlib’s automatic XMP generation will be adequate in situations with simpler metadata requirements. XMP extension schemas. XMP is by its very nature extensible, i.e. company- or industry-specific metadata requirements can be met by constructing XMP extension schemas. PDF/A supports this concept, but for ease of future retrieval mandates that a machine-readable description of the schema must be embedded in the document according to certain rules. PDFlib products support XMP extension schemas for PDF/A (actually, PDFlib 7.0.3 was the first product with support for extension schemas). PDFlib validates user-supplied XMP metadata including extension schemas in order to guarantee that the generated output fully conforms to PDF/A. More details on XMP in PDF/A, plus an online validator for XMP extension schemas can be found on www.pdflib.com. Processing existing PDF/A documents. Additional rules apply when importing pages from existing PDF/A-conforming documents. For example, in Adobe Acrobat it is very easy to combine two PDF/A documents such that the resulting output document no longer conforms to PDF/A (without any warning). When dealing with existing PDF/A documents, PDFlib+PDI carefully examines the PDF/A properties of all input and output documents to make sure that the output will again conform to PDF/A. For additional control the output intent of an imported document can be copied to the output PDF, effectively cloning the PDF/A color properties of an existing document. Creating PDF/A-1a with Tagged PDF. PDF/A-1a can be regarded as PDF/A-1b plus Tagged PDF: it requires structure information for the document and imposes certain conditions on fonts to make sure that the text can be properly interpreted. As a result, PDF/A-1a documents are fully accessible for users with physical disabilities. In addition to the visual appearance they also preserve the meaning of its contents. PDFlib’s support for PDF/A-1a is based on the features for producing Tagged PDF: each content item can be placed at a particular location in the document’s structure tree; content items which are not relevant for the document structure (e.g. headers and footers, pagination) can be tagged as artifacts which means that they will be ignored when repurposing the document (e.g. when the document is read aloud by software, or converted to some other format). Alternative text can be attached to images; the text can be read to visually challenged users by Acrobat. Note that you will need detailed knowledge about the document’s logical structure in order to create Tagged PDF. PDFlib will take care of the PDF-related details, but it cannot infer the document structure from its contents. Tagged PDF support has been introduced in PDFlib 6. PDFlib 7 adds the capability to include annotations in the document’s structure tree which improves the accessibility of links and other interactive elements. Based on the existing Tagged PDF support, PDFlib 7 can produce output which conforms to PDF/A-1a. This makes PDFlib the first tool to support this advanced PDF/A level. PDFlib GmbH 2008 - 08 www.pdflib.com 3 Validating PDF/A. When implementing a standards-based workflow it is good practice to deploy tools for validating the results against the standard. With respect to the PDF/A standard there are software tools available which check whether or not a given PDF document complies with the ISO standard. PDF/A created with PDFlib fully conforms to the validation rules of the Preflight tool in Adobe Acrobat 9 which is one the strictest PDF/A validators available on the market. Note that PDF/A validation in Acrobat 8 did not fully implement the ISO standard. PDFlib GmbH is actively working with vendors of PDF/A validation tools to make sure that creators and validators have a common understanding and interpretation of the PDF/A standard. At this time, PDFlib GmbH does not offer any products for validating PDF/A documents (i.e., check whether a document conforms to the standard) or for converting arbitrary PDF documents to PDF/A. PDF/A-conforming document processing with PDFlib PLOP. The products PDFlib PLOP and PLOP DS offer several PDF processing features, all of which are PDF/Aaware. This means that processing PDF/A input files will either result in PDF/Aconforming output if the processing can be accomplished in a standard-conforming manner, or an error message otherwise. Some examples: > Trying to encrypt PDF/A documents will result in an error message since encryption is not allowed in PDF/A. You must explicitly sacrifice the PDF/A status in order to encrypt a PDF/A document with PLOP. > Using PLOP DS to apply a digital signature to a PDF/A document will create the signature field in a way which conforms to the PDF/A standard. > You can use PLOP to inject XMP metadata in existing PDF/A documents. Since PLOP 3.1 supports XMP extension schemas for PDF/A it can be used as a postprocessing step for existing documents, or to leverage XMP extension schemas even if the software for creating the documents in the first place does not support it. PDF/A Competence Center. PDFlib GmbH is one of the founding members of the PDF/A competence center which strives to increase industry awareness of PDF/A and achieve cross-vendor compatibility. We are actively involved in the Technical Working Group (TWG) which publishes TechNotes on PDF/A-related topics. The TWG also published the Isartor test suite for PDF/A-1, a set of test files which can be used to rigorously check the standard conformance and coverage of PDF/A validation software. See www.pdfa.org for more information. PDFlib GmbH Franziska-Bilek-Weg 9 80339 München, Germany phone +49 • 89 • 452 33 84-0 info@pdflib.com www.pdflib.com 4 www.pdflib.com 2008 - 08 PDFlib GmbH