The first fontlevel transformation is called ``extension'' since it extents a font horizontally--makes its characters wider. A font is extended by a call to the function
int T1_ExtendFont( int FontID, double extend)
All information on character metrics is automatically adapted to an
extension-factor different from 1 (see ).
Applying an extension-factor to a font is implemented by replacing the current extension-factor--initially 1--with the supplied value. Thus, an extension can be deleted by specifying a factor 1. Moreover, extending a font two times, say, with factor 2, does not yield a font extended by 4. Rather the last specified extension, here 2, is applied.
The second type of fontlevel transformation supported by t1lib is slanting. It is done by a call to the function
int T1_SlantFont( int FontID, double slant)
Just as above, no size-dependent data may be existent and the font must be loaded. In that case 0 is returned, otherwise -1.
As above, the slanting operation is implemented by setting the slant-factor so that a slant may be reset by means of specifying a slant-factor of 0.
There is one thing that makes handling of slanted fonts more difficult than handling of extended fonts. When typesetting strings by concatenating bitmaps, exact information on character metrics is necessary. By slanting a character the character's width is not affected. But the bounding box is. And while extension--which means strictly horizontal scaling independent of the respective y-coordinate--simply leads to an extension of the bounding box, there is no way to compute the bounding box of a slanted character from the bounding box of the respective unslanted character. Here is an example.
\
. When slanting this character with a
value of 1, the resulting character will be similar to a vertical line. The
bounding box will thus be small in horizontal direction.
/
, the resulting slanted
character will tend to be more horizontal. Thus the resulting bounding box
will be much extended in horizontal direction.
Since version 0.3-beta the problem with the bounding box of slanted characters is handled as follows. The character in question is internally rastered at 1000 bp and the bounding box of the resulting ``edgelist'' is examined. But no bitmap is generated for the character, this limits the computational effort. However the difference in time performance between getting a bounding box from a ``simple-shaped'' slanted character like ``i'' and getting a bounding box of a ``complex-shaped'' character like ``Q'' is clearly noticeable.
The positioning algorithm for string bitmaps has been slightly improved in t1lib V. 0.3-beta so that now exclusively bitmap metrics are used where the bounding boxes are needed. The limitation of slanted fonts appears thus only if a user explicitly requests a bounding box of a character/string in an artificially slanted font.
The third and most common type of fontlevel transformation allows arbitrary linear transformations. This is done by a call to the function
int T1_TransformFont( int FontID, T1_TMATRIX *matrix)
matrix
(as described below).
This function acts by setting the font's transformation matrix to the
matrix pointed to by matrix
.
As a final consequence of what has been described so far in this section it
turns out that T1_TransformFont()
overrides whatever slant and extension
values might have been set before. Conversely, if T1_SlantFont()
or
T1_ExtendFont()
are applied to a font after a call to
T1_TransformFont()
, the respective values are simply overridden, there
will be no concatenation. In the following description of transformation
matrices and their usage, we will also describe how to concatenate an
arbitrary series of linear transformations.
There are also functions for querying the current values of the quantities described above for fontlevel transformations.
double T1_GetExtend( int FontID)
double T1_GetSlant( int FontID)
T1_TMATRIX T1_GetTransform( int FontID)
T1_TMATRIX
which will be described in detail in the next subsubsection.