#ifdef T1LIB_X11_SUPPORTafter 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)
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)
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)
Another function usually be called near initialization is
int T1_SetDeviceResolutions(float x_res, float y_res)
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.