next up previous contents index
Next: Adding Fonts to the Up: Initialization of t1lib and Previous: Standard Initialization   Contents   Index


Fine Control over Font Databases and File Search Paths

First, it is important to mention that it is generally possible to force T1_InitLib() to skip steps 4 and / or 5 as described above.

The configuration file is discarded by OR'ing the parameter log of T1_InitLib() with IGNORE_CONFIGFILE. The default paths or the paths explicitly specified by the application before are then left untouched during initialization.

Discarding the font database specification from the configuration file is achieved by bitwise OR'ing log with IGNORE_FONTDATABASE. The result after initialization will be an empty database. This is valid in V. 0.5 and newer since fonts may be added to the database at runtime.

Using the two flags described above, an installed setup can be ignored and an application may have complete control over its search paths. There are a number of functions for this purpose and each of these functions allows to specify exactly one path element at a given time. Using special characters like white space or path separators in a path element is thus not an issue.

The font database may explicitly be specified by the application using

 int T1_SetFontDataBase( char *filename)

to 0pt \fbox{$\mathcal{F}()\Rightarrow$} filename is the pointer to a string containing the name of the font database file that is to be examined. This function replaces any set of font databases setup previously and is thus usually to be called before T1_InitLib(). A call to this function after initialization will return the result -1 and T1_errno will be set to T1ERR_OP_NOT_PERMITTED. For the special case that the font database is still epmty after initialization this function may also be called after initialization. But in any case, the database must be empty! For the latter cases, fonts specified in the new database file are then immediately inserted into the database. In case of success, the number of available fonts is returned.

There is also the function

 int T1_AddFontDataBase( int mode, char *filename)

to 0pt \fbox{$\mathcal{F}()\Rightarrow$} It can be called at any time and filename is the string of the new font database's file name. If called before initialization, the parameter mode can be either T1_APPEND_PATH or T1_PREPEND_PATH and the name of the new font database simply is either appended or prepended to the existing list of font databases. Then, the function returns $0$.

If the function is called after initialization, the parameter mode is ignored and the new database is appended in any case, because this is the only meaningful action. Furthermore, the new database is immediately loaded and the function returns a number indicating the number of available fonts (which can also be 0). In the case of an error, T1_AddFontDataBase() returns $-1$.

A similar manipulation as just described for font database file, is possible for the searchpaths. (Re-)Defining a search path is done by calling

 int T1_SetFileSearchPath( int type, char *pathname)

to 0pt \fbox{$\mathcal{F}()\Rightarrow$} before calling T1_InitLib(), or respectively, before the database contains any fonts. An attempt to set the file searchpaths when the database is no longer empty is denied. The reason is that it is not wise to override the searchpaths which had been valid previously during the verification of the existence of font files. Such paths should thus not be removed. The parameter pathname points to the string that contains the pathname that should be used as searchpath. The parameter type is any OR'ed combination of T1_PFAB_PATH, T1_AFM_PATH and T1_ENC_PATH. These tell the function to set the search paths for Type 1 font files, AFM files and encoding files, respectively. In case of an error -1 is returned and otherwise 0.

Extending the file searchpaths before and after initialization is possible using

 int T1_AddToFileSearchPath( int pathtype, int mode, char *pathname)

to 0pt \fbox{$\mathcal{F}()\Rightarrow$} This might be useful to locate font files that were of no interest at the time of initialization. pathname is the pointer to the string that should be added to the searchpaths. Only one particular path element may be specified in one call. What searchpaths are affected is determined by the parameter pathtype. Again, similar to described above, any OR'ed combination of T1_PFAB_PATH, T1_AFM_PATH and T1_ENC_PATH is valid. There are two ways to extend an existing searchpath which are specified by the mode parameter. It must be either T1_APPEND_PATH or T1_PREPEND_PATH, which causes the new path element to be appended or prepended to the existent path respectively. Since an existent path specification is not overwritten by T1_AddToFileSearchPath(), this function may be called at any time before or after initialization.

It might also be of interest to query the current file search paths and font databases. t1lib provides

 char *T1_GetFileSearchPath( int type)

to 0pt \fbox{$\mathcal{F}()\Rightarrow$} for querying search paths. Again, the parameter type determines what search path is returned. Exactly one of T1_PFAB_PATH, T1_AFM_PATH, T1_ENC_PATH and T1_FDB_PATH should be specified. If more than one path is specified, the first match wins and only one path is returned. The types will be checked in the order T1_PFAB_PATH, T1_AFM_PATH, T1_ENC_PATH and T1_FDB_PATH. Here, T1_FDB_PATH indicates an interest in the list of font databases. The paths are separated using the current path separator.


next up previous contents index
Next: Adding Fonts to the Up: Initialization of t1lib and Previous: Standard Initialization   Contents   Index
2004-10-04