next up previous contents index
Next: Initialization of t1lib and Up: Using t1lib Previous: Compiling and Linking t1lib-Programs   Contents   Index


Querying and Setting Fundamental Configuration Parameters of t1lib

It might be necessary to know whether t1lib is compiled with or without X11 interface. At compile time a programmer can check for the X11 interface by stating
#ifdef T1LIB_X11_SUPPORT
after including t1libx.h. If T1LIB_X11_SUPPORT is not defined, the X11 interface is not configured and compiled.

At runtime, a program can check for the X11 interface by a call to

 int T1_QueryX11Support( void)

to 0pt It returns 1 if the X11 interface is present and 0 otherwise.

Notice that querying X11 support at runtime and compile time tends to be pretty useless starting with V. 0.6-beta. Any decision can be done by examining the existence of the t1x-library and the t1libx.h header file. The definition and the function described above are thus only provided for compatibility with pre-0.6 versions of t1lib.

Some remarks on the general data format of bitmaps and should be given here. t1lib internally always generates bitmaps in the way that appears to be natural for them: The first pixel corresponds to the least significant bit in a byte (or word/longword). Bytes are always arranged in memory the way, that the first byte is at the lowest address and the next byte at the following address. This convention is called LSBFirst which stands for Least Significant Bit/Byte First. It is the natural way of data alignment on machines with Little Endian data representation. In contrast MSBFirst stands for Most Significant Bit/Byte First which is the natural kind of data representation on Big Endian machines. A glyph's scanlines are always aligned in LSBFirst-type, no matter on what machine t1lib is running.

What has been said above, strictly does only apply to non antialiased glyphs, i.e., real bitmaps. Antialiased glyphs have their gray values coded in the representation that is natural for the machine t1lib is running on. For example, if t1lib runs on a Big Endian machine, the gray values are in Big Endian. The X11 displaying functions automatically handle this correct.

Scanlines of t1lib-glyphs may be padded to 8, 16 or 32 bit. Padding to higher values will consume more memory for the glyphs, but might speed up concatenating of bitmaps as described in [*]. This applies to machines with Little Endian representation as, for example, Intel's 86 series. On these machines 16 or 32 bits can be placed into the target bitmap in one step. On machines with Big Endian representation, for example, Motorola 6800 series, this is currently not possible. However, using a higher padding value could still yield a better performance since the application could work on larger units than a byte.

The default padding value in t1lib is 8 bit. The padding value can be specified at runtime by means of calling

 int T1_SetBitmapPad( int pad)

to 0pt pad must be one of `8', `16' or `32'. The call will only be successful if executed before initialization of t1lib. This a security mechanism which prevents from having glyphs with distinct padding values. The return value is 0 if successful and -1 if pad was invalid or t1lib had already been initialized.

There is a further restriction concerning the padding value. Setting it to 32 is only possible if the machine has an ANSI C integer type of 64 bits. This condition is automatically checked by the configure script of t1lib. If such an integer type is not present (or has to be emulated as e.g. long long in gcc) there would not result any performance gain. If a specified padding value is rejected, T1_errno is set appropriately.

An application can query the current padding value by calling

 int T1_GetBitmapPad( void)

to 0pt The returned value is the padding value. This function can be called before or after initialization of t1lib.

Another function usually be called near initialization is

 int T1_SetDeviceResolutions(float x_res, float y_res)

to 0pt This function allows setting the resolution of your device (screen). The values must be given in dpi. The default resolution, 72 dpi, implies that a pixel in device space equals 1 bp. This function may be called before or after initialization. The only restriction is that no size dependent data must be available. Changing the resolution when bitmaps are already cached would result in inconsistent bitmap-sizes for bitmaps generated before and after the call to T1_SetDeviceResolutions(). The function checks whether initialization has already been done. If not, all is OK since no size-dependent data for any font can exist. If initialization has been done, it checks for every font whether size dependent data exists. If there's any size dependent data for any font, T1_SetDeviceResolutions() will return -1 without having set the new resolution. Otherwise the specified resolution will be set and the function will return 0. If you really need to set another resolution in the middle of a session, all size-specific data should explicitly be removed from memory beforehand. This can be achieved using T1_DeleteAllSizes() (see [*]).

Notice that the device resolution need not be set at all if the default resolution of 72 dpi in horizontal and vertical direction is OK. This function is primarily intended to be prepared for applications with a device aspect ratio different from 1.


next up previous contents index
Next: Initialization of t1lib and Up: Using t1lib Previous: Compiling and Linking t1lib-Programs   Contents   Index
2005-01-12