Next: Error Handling
Up: Composite Characters
Previous: Transparent Handling of Composite
Contents
Index
Caveats
Although handling of composite character is widely automated, problems may
arise. Most importantly it is the responsibility of the user to take care that
font file and AFM file provide consistent data. Alas, this is not always true
for existing font and AFM files. If, for example, an AFM file is extended by
composite character definitions and these composite character definitions
reference symbols that are not defined in the CharsStrings dictionary, errors
will result. If composite character information is added to an AFM file, the
following rules have to be respected:
- The name of the composite character has to be encoded because it could
not be accessed otherwise. Furthermore, no internal definition in the
CharStrings dictionary may exist because this would override the composite
character definition from the AFM file.
- The user should verify that all components of a composite character
definition have entries in the CharStrings dictionary. This can be checked
for example by using
T1_GetAllCharNames()
or by disassembling the font
file.
- Even being more restrictive, the user should take care that all pieces
of a composite character are encoded. For t1lib this is really
irrelevant because, internally, characters may be accessed by the name of
their CharString. This means t1lib simultaneously has access to all
characters defined in a font. However, an application that exports PostScript
files can only access character definitions via their position in the
encoding vector. Composing a character from pieces of different encodings
will require two font definitions in a exported PostScript file for
typesetting one character, which cannot be termed a clean strategy.
Next: Error Handling
Up: Composite Characters
Previous: Transparent Handling of Composite
Contents
Index
2005-01-12