Aside from the fact that composite character information may be accessed in
t1lib, t1lib can automatically--and completely transparently with
respect to the user--compose characters if it finds information on how to do
so. To give an instance, let us examine the font ComputerModern Roman
(cmr10). Because this font is specially encoded for the use with early (7-bit)
TEX-systems, it does not incorporate a definition for Adieresis
. The
definition simply was not required because TEX itself constructed the
composite character by means of its \accent
-primitive. If a font like
cmr10 is reencoded e.g. to IsoLatin1 encoding, the character ``Ä'' will show
up as a blank because there is no definition for Adieresis
. Now, if the
corresponding AFM file is extended with the following lines, it becomes
possible to access an Adieresis
:
StartComposites 1 CC Adieresis 2; PCC A 0 0; PCC dieresis 100 200; EndCompositesThis line in an AFM file provides information about how to construct an
Adieresis
from the A
and dieresis
glyphs, and t1lib can utilize this information to construct the requested glyph without that
this will be be noticed by the user.
Composite character are treated just the same way as standard characters. They are cached, they can be scaled, transformed etc. Let us assume that the cache is still empty and a character, identified by its encoding index, now is to be rastered. The following happens in the rastering function:
Adieresis
by raising the umlaut ``¨ '' via a composite
character definition, if Adieresis
is defined internally.
.notdef
, so that for extreme cases the whole composite character might
be substituted by a .notdef
. Then, an appropriate message is put into
the log file with priority T1LOG_WARNING
and T1_errno
is set to
T1ERR_COMPOSITE_CHAR
.
In the same way t1lib composes characters without user intervention, the functions for character metrics are aware of composite character information and the returned result are also valid for those functions.