next up previous contents index
Next: Transformation at Rastering Time Up: Transformation of Fonts Previous: Transformation of Fonts   Contents   Index

Fontlevel Transformations

t1lib supports three transformations that operate globally on a font's data. After applying such a transformation to a font all characters generated from then on will be rendered according to that transformation. Moreover, these transformed characters are saved in cache for fast future access. This principle is thus meant for transformed fonts which are semantically used as ordinary text fonts. Creating a font Times-Oblique by slanting a Times-Roman would be a typical example.

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)

to 0pt \fbox{$\mathcal{F}()\Rightarrow$} A font that is to be extended may not have size dependent data. If size dependent data exists, it must explicitly be removed before applying an extension-factor. This is simply a security mechanism which prevents the user from mixing up extended and non-extended bitmaps. If the font is not loaded or size-dependent data is existent, -1 is returned. Otherwise, the function returns 0.

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)

to 0pt \fbox{$\mathcal{F}()\Rightarrow$} The slant-factor $s$ tells the rastering algorithm to advance the $x$-coordinate of a given point by the product of $s$ with the $y$-coordinate of that point. Such fonts are sometimes called oblique. Another interpretation is that we state: $s=\tan(\alpha)$, where $\alpha$ is the well-known italic-angle of the font.

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.

In conclusion we can say that the effect of slanting on the bounding box of a given character depends on the shape of the character itself.

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)

to 0pt \fbox{$\mathcal{F}()\Rightarrow$} The transformation is specified by 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)

to 0pt \fbox{$\mathcal{F}()\Rightarrow$} and

 double T1_GetSlant( int FontID)

to 0pt \fbox{$\mathcal{F}()\Rightarrow$} return the current extension and slant values. The function

 T1_TMATRIX T1_GetTransform( int FontID)

to 0pt \fbox{$\mathcal{F}()\Rightarrow$} Returns the current transformation matrix as a structure of type T1_TMATRIX which will be described in detail in the next subsubsection.


next up previous contents index
Next: Transformation at Rastering Time Up: Transformation of Fonts Previous: Transformation of Fonts   Contents   Index
2004-10-04