9.2.8 CMI processing

Here are some further details on how Charspace processes the CMI files:

• Charspace uses a single namespace; i.e., each defined identifier, whether it be a character name, an internal identifier, a fontdimen name, or whatever, is stored in the same table. Furthermore, Charspace does not complain, or even warn, about redefinition of identifiers: as we build up CMI files to be shared among different fonts, we felt such redefinition would be common.

• Charspace does not insist that identifiers be used before they are defined. For example, the following sequence:

  define foo bar
  define bar 1.0
  char A foo , bar
  

  is valid, and defines both side bearings of `A' to be 1.0. (See the preceding sections for the definition of the various commands allowed in CMI files.)

• Charspace only tries to resolve the definitions of those identifiers which are actually used to produce the output files (i.e., those in a sidebearing definition, a kern value, or a fontdimen value). Thus, something like

  define foo bar
  

  will elicit no complaint, if `foo' is not needed to make the output files.

• Charspace reads the contents of all the CMI files before attempting to resolve any definitions. Thus, it is the last definition which counts. For example:

  define bar 100
  define foo 2 bar
  define bar 1
  char A foo , foo
  

  defines both side bearings of `A' to be 2, not 200.

• Charspace predefines one identifier, designsize, to be the design size of the input font (in pixels). It can be redefined like any other identifier.

If you can read programs in the C language, you may find it instructive to examine the implementation of CMI file processing in the source files `charspace/char.c' and `charspace/cmi.y'. The source provides the full details of CMI processing.