Data Structure

Initialization of the Adobe PDF Library requires a specific collection of information, maintained in the data structure PDFLDataRec. One such structure should be created and cleared to zeroes before starting the Adobe PDF Library. The next few sections deal with settings of parts of this structure to prepare for initializing the Adobe PDF Library.

Setting Resource Directories

The PDFLDataRec record contains two fields (dirList and listLen) which are used to establish a list of paths to be searched for font resources, its AdobeFnt.lst file.

See “The AdobeFnt.lst File” below. This resource directory listing is built by allocating an array of pointers to strings, and filling each pointer with a pointer to a path.

The field dirList should be set to point to this array. The field listLen should be set to the number of entries in the above array.

The AdobeFnt.lst File

Your Adobe PDF Library application and Adobe Acrobat or Adobe Reader compiles an AdobeFnt.lst file for its own use when either constructing a PDF document or rendering/displaying it later. It consists primarily of font information within files found on your machine. Since the AdobeFnt.lst file is a plaintext file, compiled on an as-needed basis by the application, you can review its contents in a text editor at any time to verify that it is finding the resources needed. The actual name of the file varies by product, platform or release level as AdobeFnt.lst, AdobeFnt07.lst, AdobeFnt08.lst, AdobeFnt09.lst and so on; we will refer to it generically as AdobeFnt.lst here.

Decimal-point Numbering in AdobeFnt.lst Filenames

As font resource information stored by the “Plus” release of Adobe PDF Library, provided by Datalogics, may not match that of font resource files compiled by other Adobe products, the Library adds an extra decimal-point extension to the file name.  This way, only an application built using a version of the Adobe PDF Library provided by Datalogics will search for and recognize that file.  Other Adobe Systems applications will not try to read the file by mistake.  The file name will be AdobeFnt11.3.lst instead of AdobeFnt11.lst.

Optimizing the AdobeFnt.lst compilation process

You should find that the AdobeFnt.lst file is only compiled if a copy of that file is not already present, or if another file in the directory has a more recent time stamp than the AdobeFnt.lst file itself. The creation time does of course go up if many files are present, or if many resource areas must be searched. The file is not recompiled every time the application is run, only when certain conditions are met as described above.

Try to limit the number of files that must be searched. You can do this by running the application from another location, so that the current working directory is one with very few files in it, or alternatively make use of flags such as kPDFLInitIgnore DefaultDirectories, to instruct the application to ignore its working directory when searching for resources.  See “Font Resource Search Control Flags” below. Make sure that the application gets a list of directories where its resources will be found.

Determining your Application’s Font Search Areas

It is possible to have many copies of AdobeFnt.lst stored on your system, as a copy of this file may be created whenever an application is run in a new working directory for the first time. Therefore, if you have any doubt as to which AdobeFnt.lst files are being read by your APDFL application, feel free to delete the existing copies, or temporarily rename them in order to hide them, run the application again, and then look to see where a new copy has appeared. Reviewing where those files are being created will show you which areas are being searched, and what resources are being found by that instance of the application.

Font Resource Search Procedures

Referenced fonts are searched for in a series of locations, with the hunt continuing until a font matching the specifications has been found. In the absence of any control flags , fonts will be searched for in the following order:

  1. Fonts known to the system (from %WinDir%\Fonts, etc.)
  2. Fonts in common areas (“program files\Common\Adobe”)
  3. Fonts below the current working directory
  4. Fonts specified in user-defined paths (dirList)

See “Font Resource Search Control Flags” below.  In all cases, the first font found with the given name and attributes is the font that will be used for that name.

Font Resource Search Control Flags

The Adobe PDF Library font- search procedures allowing you to tailor your application’s initialization for the most efficient searching of resources. This allows you to avoid areas of the directory structure that are congested and/or which have no font resources to be found. You can also change the order in which locations are searched, and enable selected areas to be ignored or omitted from the search.

Think of the font resource searching process as the four-step sequence itemized above, which you can control via the following flags:


The default setting, searching areas in the following order (as above) until a matching font resource is found:

  1. Fonts known to the system (from %WinDir%\Fonts, etc.)
  2. Fonts in common areas (“program files\Common\Adobe”)
  3. Fonts below the current working directory
  4. Fonts specified in user-defined paths (dirList)


If this flag is specified, the search order for system and common areas is transposed, with common areas searched first:

  1. Fonts in common areas (“program files\Common\Adobe”)
  2. Fonts known to the system (from %WinDir%\Fonts, etc.)
  3. Fonts below the current working directory
  4. Fonts specified in user-defined paths (dirList)


When kPDFLInitIgnoreCurrentDirectory is present, search step 3 (Fonts below the current working directory) will be omitted, regardless of the order of steps 1 and 2:

  1. (System or Common Location Search, as above)
  2. (Common or System Location Search, as above)
  3. (Omitted)
  4. Fonts specified in user-defined paths (dirList)


When the flag kPDFLInitIgnoreDefaultDirectories is set, the “prefer” flags above will be ignored, and searches of locations 1, 2 and 3 will be omitted. Thus when kPDFLInitIgnoreDefaultDirectories is given, font searches will be conducted only in user- defined paths:

  1. (Omitted)
  2. (Omitted)
  3. (Omitted)
  4. Fonts specified in user-defined paths (dirList)

NOTE:  There is currently no way to “prefer” fonts loaded in steps 3 or 4 of the search order to fonts loaded in steps 1 or 2.

Font and CMap files in the /Resources directory

The Font and CMap resources found on the local system and provided in the \Resources folder are needed for many types of operations. Several workflows rely on these resources, including processes  that:

  • create text runs
  • render or print pages
  • extract text from PDF documents using the WordFinder
  • edit or change content via the PDE Layer

Setting Memory Allocation Routines

You may wish to use this portion of the PDFLDataRec record when your application contains a memory allocation/deallocation schema that you want the Adobe PDF Library to share. In particular, if your application does not use the system malloc/calloc/free routines, which the Adobe PDF Library will use by default, you may want to use this section.

Control of memory allocation is accomplished by creating a new record (TKAllocatorProcs). You must allocate space for this record and fill in all of the fields if you want to establish your own memory manager. This record points to several routines:

  • allocProc, allocates memory
  • reallocProc, increases the size of an allocated block of memory
  • freeProc, frees memory
  • memAvailProc, returns the amount of memory that may be requested without an error

The definitions of the interfaces for these procedures are contained in PDFInit.h. Basically, they are the interfaces for malloc (or calloc), realloc and free for standard UNIX. However, each contains as its first parameter a pointer to user data. This pointer is the fifth field of the TKAllocatorProcs record.

Setting Resource Allocation Routines

The Adobe PDF Library provides routines for locating resources. But if you want to control access to resources in your application, this section is where such control is established.

The TKResourceProcs record is similar to the TKAllocatorProcs record. It contains a pair of pointers to procedures for allocating and deallocating resources. The procedure interfaces are defined in PDFInit.h.