Map Image Metafile* (MIM*) Language Specification Manual
Version 4.6
23 August 1995

"There is one thing stronger than all the armies in the 
world, and that is an Idea whose time has come."

Victor Hugo

Geography Division
U. S. Census Bureau
Washington, D. C.

Map Image Metafile and MIM  are Trademarks of the U.S. Bureau of the Census

Contents

Purpose and Applicability of Document				1
Change Overview							1
Why MIM?							1
What Is MIM?							5
What MIM Is Not							6
KISS Principle (Keep It Simple and Supple)			7	
Command Primitives						7
Objects and Command Extensibility				11
Rules for MIM Construction					13
Rules for Reading MIMs						16
Appendices							
COOL Map Component Definitions					A
MIM Commands							B
Cartographic Fonts Files					C
Simple MIM Interpreter Psuedocode				D
Simple MIM record token parser					E
U.S. Census Map GeoID and Parameter Examples			F
Pattern Application Rules					G

Purpose and Applicability of Document
The purpose of this document is to provide a complete and concise description of 
the Map Image Metafile* (MIM*) language for describing the components 
and relationships of a map image in a device independent manner.  The 
definitions, syntax, and structure of this language are recommended for all 
Census Bureau Geography division mapping projects requiring a standard, 
device independent means for creating, exchanging, and/or producing map 
images.

Change Overview
This version of the MIM language specification differs from the previous version 
in the following ways.
	a.	Some typographical errors, spelling errors, and minor wording 
		changes were made throughout the document.
	b.	The *dlt command has been changed to add two optional arguments.

Why MIM?
Past
Historically the U. S. Bureau of the Census has made the maps accompanying 
or associated with data products available to the public.  Heretofore this has 
taken the form of having the maps printed and bound with the data volumes or 
issued separately.  With the exception of a few map products, this has been the 
means of distribution.

The maps allow the users of census data to visually relate the statistics to the 
geographic areas for which they were gathered.  Other than for administrative 
type maps used during census operations, the maps that the public receive and 
use most are of two kinds, reference maps and statistical (thematic) maps.  The 
former show the types, extent and spatial relationship of the political and 
statistical areas represented in the census while the latter generally depict one 
geographic level and one data variable such as percent of population graduating 
from high school.  In general, the maps of use to people studying census data 
from a current or past census are the reference and statistical maps and not the 
operational maps.

The excellent quality of the printed map, both in image sharpness and paper 
stock, inexpensively provided the public with readily available and flexible 
research tools.  Because of the high contrast and sharpness of the printed 
images, the maps were easy to duplicate either photographically or, in the past 
few decades, xerographically.  The durability of the paper made them useful 
both as working bases and as archived documents for historical studies.

Present
The advent of the age of automated map production at the Census Bureau has 
changed things dramatically.  The number of map sheets produced has 
increased ten-fold or more.  Part of this has came about because of the change in 
the number of geographic units delimited for the country, e.g., block numbered 
maps are public products and now the whole country is block-numbered and 
grouped into Census Tracts or Block Numbering Areas.  Another reason is that 
more map types were produced as products than have been produced in previous 
censuses, e.g., metropolitan map series maps.  In some instances, special maps 
were made for an operational task that in past censuses would have been 
handled by making another map do double duty.  All this has added up to many 
maps , e.g., over 70,000 different sheets for just a single map type, and virtually 
every map was produced through automated means.

Plans were made to provide the public with maps of types similar to those 
provided in the past.  The shear volume, however, presented special problems to 
individuals, companies, other government agencies, academic institutions and 
libraries.  They were not prepared to receive, store, and manage such a large 
number of map sheets, much less pay for them from limited budgets.  Further 
complicating the situation was the fact that, except for less than 7,000 printed 
maps, all the maps were to be plotted at time of purchase.  This could potentially 
restrict the flow volume to users.  Finally, the somewhat lower quality of paper 
of the plotted maps verses printed maps affects wear and tear, markability on 
the image, and archivability.  The contrast and sharpness of the plotted maps 
are difficult to reproduce by any means, even large format copying or replotting.

An early recommendation was to copy the plot tape and make these available to 
the public so they could make as many copies as desired.  However, the plot files 
were produced in a format for a specific set of hardware.  Therefore, in order for 
anyone to make as many copies of the maps as they wished, they had to pay for 
the cost of this type of plotter (over $25,000 in 1988) and the costs of the plot files on 
tape.  Even providing the plot files on CD-ROM only reduced the volume of things 
to be handled, not the complexity of generating or viewing a map image.  To 
overcome the limitation of having to have a specific type of plotter, some work 
was done by commercial firms to produce interpreter software so the plot tapes 
could be read and output to other display devices and plotters.  Though 
promising, this still required a special step for each map plotted.  

How to make the maps as readily available as in past censuses is only one of the 
problems caused by automated mapping.  Another is that the programs that 
generate the map images (plot files) cannot account for all the variations and 
special conditions that occur in a map.  Text placement, with or without overlap, 
position of a north-arrow within image area for different shapes of geography, 
removing or editing features that were erroneously coded in the TIGER/File are 
the examples of tasks that cannot presently be economically and efficiently 
performed by batch (non-interactive) mapping programs.  This type of task must 
be performed interactively.  Therefore, some way had to be found to not only 
generate the map image, but to be able to edit and manipulate the image.

Further compounding the map generation process was, and still is the lack of 
stability in the production environment.  The main computer used for TIGER 
processing has changed three times,1 thereby affecting the extraction of 
cartographic data from the TIGER/Files.  The plot file generation software has 
had to be developed in four different environments.2  The programming, 
interactive editing, and plotting capabilities have continued to expand with 
concomitant needs for adjustments to the programs and procedures.

The situation begged for a simple and easy-to-implement solution.  A solution 
that would allow a map image to be generated wherever and in whatever 
computer environments available at the time, and then be edited, manipulated, 
and plotted wherever and in whatever hardware and software environment is 
available for those tasks.  The answer was a simple image transfer format that 
would not suffer under hardware limitations such as how bits are stored by 
different machines and so forth.  Some form of meta3 map image file was 
clearly needed.  The map image metafile (MIM) was designed as the simplest 
and quickest way to provide the needed transfer format.4

Future
Given that the map production environment in terms of hardware, software and 
operating procedures will continue to change, and that the MIM is a feasible 
solution to the problems caused by this change, there is yet another major 
problem:  How to store map images for future reproduction and use.

As the years go by, two groups of people will need to be able to reproduce the 
census maps, the Census Bureau itself and the public.  For the near future, the 
plot files can be used to replot maps as needed.  However, aside from the very 
real possibility that the plot files may become unreadable, at some point in time, 
the plotters that read these tapes will have to be replaced.  Storing the map 
images as hardware specific plot files and forcing ever burdensome backwards 
compatibility on new plotters is neither desirable nor realistically possible in the 
long term.

One possible solution was the simple capture of the map image as a bit-image5 
at the scale of map creation.  While this is well within the technology of today 
with all the image capture and manipulating systems available, this was 
unsatisfactory for several reasons.  First, most of the maps were generated at a 
resolution of 200 dots per inch (dpi) and would require a plotter of that resolution 
to reproduce them.  If a higher resolution plotter is used, either special software 
would have to translate the bit-image back to the original size or the plot would 
be changed proportionally.  For example, a 200 dots per inch (dpi) census map 
reproduced without conversion on a 1,000 dpi plotter would make a map 1/5th 
the original size.  Likewise, displaying the bit-image on the screen of a graphics 
terminal would severely limit the amount of the map visible since most screens 
today cannot display more than about 1,000 by 1,000 dots, if that much!  This 
means that, at best, only about 5 inches of a map can be seen at a time of a map 
that may be 24 by 30 inches or larger.  Further, a bit-image has no intelligence to 
allow for selected display of say boundaries without text, or county boundaries in 
red, all others in green.  Finally, an decompressed bit-image file of a 24 by 30, 200 
dpi map would take 28,800,000 million bits or 3,600,000 bytes.  Compressing the 
file means that if the information on how to decompress becomes separated from 
the file or lost, the map could only be retrieved with great difficulty.  Bit-images 
were discarded as not a feasible solution.

Other storage forms were investigated, including, but not limited to the 
American National Standard computer graphics metafile (CGM) for the storage 
and transfer of picture description information.  This is a powerful and clear 
standard in which many valuable ideas were found.  However the CGM 
standard, as well as the several other standards6 investigated, suffer from the 
same difficulty of use.  They all produce a file that is very close to hardware 
levels of image data representation and their format and form require 
knowledge of some external facts to read the file.  This was considered a serious 
shortcoming when viewed from a future position.  Further, most of the storage 
forms limited the non-graphic information content of the file, thereby restricting 
flexibility.7  This is not to say that they could not have been forced to perform the 
task envisioned for census map image storage, retrieval, manipulation, and 
reproduction.  Rather, desired was a simple, straight-forward file structure for 
the 1990 census maps; a structure that would serve census needs and the public 
(all other users) in the near future and for decades to come.

It is difficult, if not impossible to predict what will be the future uses of the 1990 
and subsequent census maps.  If the past if any indication, the users will need 
ready access to the maps and a relatively easy way for manipulating the images 
to show not only census data on them, but their data as well.  Past maps were 
fully comprehensible, free standing documents of great use; digital files of map 
images should be no less.

What Is MIM?
A Map Image Metafile is a flat file of ASCII characters that is a self-
documentating, full-image description of a map.  This means several things:  
The contents of a MIM file are readable without special software.  In fully 
expanded form, no external documentation is needed to describe the data fields.  
Differences in the bit-structure of the real, integer, and character data types 
between computers and programming languages are of no consequence.  And, 
most importantly, the information in the file can be used to faithfully reproduce 
a copy of the original census map.

The underlying MIM content and structure are based upon the map description 
concepts found in COOL8.  The map is considered to be an object that can be 
described in terms of other cartographic objects such as legends, north arrows, 
etc.  These in turn can be described in terms of other cartographic objects or 
cartographic primitives such as text, lines, and areas; each with it's own 
attributes.

The two characteristics of a MIM, it's object nature and flat ASCII format, 
provide significant improvements over a regular plot file.  The flat file format 
removes the need to interpret hardware codes while the object structure allows 
for showing relationships between graphic elements.  This is very powerful, 
because whole portions of a map image may be 1) readily identified within the 
file and 2) treated as a single unit when interactively manipulating the image.  
Neither of these are generally true of ordinary plot files.

Certainly such an object type capability could be incorporated into the map 
image generation software.  This, however, would require that the whole map 
image be generated, manipulated for edit and/or design needs and output to a 
plot file in one step.  The amount of computer resources (time, storage, 
communications, and so forth) needed to accomplish this in one step from the 
TIGER files currently beyond the Bureau's capabilities, and likely to be for some 
time.

MIM's serve as the exchange format between the various operational steps.  The 
production of a map is generally a multi-phased operation.  This is particularly 
true of a publication map.  As stated earlier, all the operations do not necessarily 
take place on one computer or even in one operating environment.  MIM's were 
designed to be a simple but complete exchange format between the operations.

Finally, MIM's provide a simple means for archiving census map images in a 
digital form.  Their form and content provides admirably for future reproduction 
of the original census map image.  Regardless of the storage medium, tape, 
disk, CD-ROM, etc., a MIM can either contain the full description of a map 
image or when many images are grouped on a single medium, allow sharing of 
common file information.  In either case, the full description of the map is 
stored, and stored in a "human" readable form. 

What MIM Is Not
It is probably true to say that MIM's are not for the inflexible and weak-hearted!

A MIM is not a compact binary transfer format.  Part of the value of a MIM 
comes not from the amount of data storage it uses, but from its almost universal 
flat, ASCII exchange format.  In some very specific cases during internal 
operations, a binary version of a MIM has been used for exchange between 
programs.

A MIM is not intended to be used directly by mapping operations programs.  
Rather it almost always requires reading and loading into an internal 
structure; one that is efficient to the needs of a given hardware and software 
installation.  The relative ease of reading a MIM is a strength that permits the 
use of many different types of hardware and software for display and 
processing.

MIM's are not designed to be randomly accessed.  MIM information is 
communicated by command and data sequence, much as one reads a letter or 
novel.  Rarely in a MIM is a map entity completely described by a single 
command.  Since MIM information is presented in the file in sequence, when 
an attribute such as line width is set, it stays in force for all succeeding lines 
plotted.  In this way file size is kept relatively low since redundant attributes do 
not have to be expressed for every instance of a map image command primitive.  
Even within a command, sequence is important.  Arguments in the commands 
must appear in the specified sequence.  If an optional argument is not included, 
the sequence of arguments is not changed; the optional one is merely not there9.
Therefore, knowing what conditions have been set earlier in the file is 
mandatory for proper display or manipulation of an entity.

MIM information is not stored in fixed field position or fixed record size.  In 
some cases a data field is generally only wide enough to contain the value in it.  
A number 7863 would take up four positions in a record and a number 57 would 
take up only two, thus precipitating a shift left of two characters for all 
succeeding data in that record.  Similarly, many arguments for the commands 
are optional, so the record size will vary according to the number of arguments 
actually used.

Finally, MIM commands are not designed to account for every possible special 
condition in every census map.  Even if all the possible exceptions or special 
conditions could be enumerated and described, to do so would weight the system 
down with specialized commands.  Different map symbols also are not pre-
established in the MIM definitions.  Rather, the philosophy is to treat special 
conditions by utilizing the existing commands, of which one of the most 
important is the comment (*cmt) command.

KISS Principle (Keep It Simple and Supple)
The development and evolution of the file structure and content has been heavily 
influenced by the Keep It Simple Soldier (KISS) principle.  While retaining the 
guiding principle of simplicity in form and content, the other need was for it to 
be supple.  Indeed, one of the problems with defining strict structures and 
standards is that they tend to evolve into highly complex encoding schemes as 
technological and/or social changes occur and attempts are made to 
accommodate them.  There is always the tendency, in the name of management 
ease, to enforce formalized structure in situations when it is at best 
inappropriate, and at worse, totally repressive to creativity and advancement.  
By keeping a MIM simple but flexible, hopefully some of these pitfalls may be 
avoided.

Simplicity is maintained by defining the absolute minimum number of 
commands and providing for extensibility.  This minimal number can be 
determined by only allowing commands if they 1) cannot be constructed 
efficiently and effectively out of existing metacommands, 2) apply to most map 
images, and 3) are neither hardware, software, nor operationally specific.  
Granted, some degree of common sense must apply when deciding on a new 
command, but in general, the fewer the better.

Suppleness is maintained providing for a way to accommodate special situations 
and changing conditions.  This is achieved in MIMs by providing for 
extensibility to the image description commands.  Suppleness implies a 
flexibility and moldability but not a change in the basic nature of the underlying 
structure.  In mathematical terms, a piece of ceramic clay shaped like a torus 
can be molded into a coffee cup or an orange juicer dish with a handle, all 
without losing the underlying nature of the torus.

MIMs must be kept simple and supple.

Command Primitives
MIMs are constructed from a series of primitive commands.  Each primitive is 
discussed in terms of its category, use and file order.  A detailed description of 
the commands is given in Appendix B, Map Image Metafile Commands.

Meta-commands are divided into three categories, 1) required commands, 2) 
basic class and attribute commands, and 3) grouping and extending commands.

Required commands  These commands must appear in all metafiles.  There are 
three commands in this category: *int,  *cls, and  *msz.

The *int and the *cls command bracket a map image.  Any command found 
outside these two are assumed to not be part of the image.  The *int command 
must appear first before any other command necessary to that image.  Likewise, 
the *cls must appear as the last command of all commands describing that 
image.  This is not to say that commands such as comment commands cannot 
appear outside the *int-*cls bounding commands.  In some cases, comments 
are added before the *int to specify that an operation or process has occurred on 
that file.  These "external" commands are stripped off when no longer needed 
and are not part of the "real" image.

The *msz command defines the fundamental design parameters of the meta 
image.  All map images have been designed to give a certain "look" to the map 
product.  This means that they are designed for a certain size and to be produced 
on a certain output device at a given resolution.  The *msz command sets the 
visual size and resolution parameters.  Any parts of the image that fall outside 
the xy-values given in the *msz command are subject to be clipped at best and 
dropped at worse.

Basic class, attribute, and helper commands  These commands make up the 
bulk of the metafile commands.  They define the look-and-feel of the map image.

There are three class commands, *str, *pgX, and *vtx.  The *str command 
defines a line in terms of its shape points.  The *pgX command defines a polygon 
in terms of its shape points.  The *vtx command defines a line of text to be 
plotted.  While text can be considered to consists of lines and areas, for MIM 
purposes it is considered as a class itself.  Therefore, these three commands are 
the fundamental cartographic entities of all maps images.

Because they are fundamental, the class commands can have an optional 
argument that identifies the state of the entity, i.e., active, deleted, changed, 
added (not created by original meta image generation software.)  This is useful 
when doing interactive work or displaying the file.  The class commands also 
can have geocodes or similar alphanumeric codes that identify the geographic 
entity being represented.  This has the advantage of allowing image display 
and/or interaction to be able to work with the entities as say, county boundaries, 
tract boundaries, place name, and so forth without having to work with say all 
strings or all text.

The way an entity appears in the final map depends upon the attributes of the 
entity.  A line can have a width, a type such as solid, dashed, and so forth, and 
other attributes.  Text has fonts; polygons may have pattern fill.  These are 
attributes to the entity.  There is a category of commands that are used to set 
attribute conditions for succeeding entity processing.  Each of attribute setting 
commands must be proceeded by a defining command.  For example, the *dpa 
command defines the characteristics of a pattern that is then referred to by the 
line or fill patterns as needed.  Table I is a shows the relationships between the 
primitive cartographic entities, their attribute setting commands and the 
attribute defining commands.

					Table I

		Strings	Polygons	Text	Defined
		*str	*pgX	*vtx	by
Fill color	fcs	fcp	fcv	rgb
Fill pattern	n/a	fpp	fpv	dpa
Line color	lcs	lcp	lcv	rgb
Line pattern	lps	lpp	lpv	dpa
Line type	lts	ltp	ltv	dlt
Line weight	lws	lwp	lwv	n/a
Text font	n/a	n/a	sft	n/a

Helper commands are there to make metafiles easier to build and understand.  
The two helper commands are *cmt and *inc.  The *cmt command allows 
comments to be included anywhere in the file.  They can be used to elaborate on 
the map image, "non-standard" things in the file such as a new scheme for 
geocoding, map projection, map scale, and so forth.

The other helper command is *inc.  Meta commands, comments, definitions, 
etc. that are common to many maps do not have to reside in every metafile.  A 
separate file of these meta commands can be produced and included in the map 
image file at the point that the content of the separate file is applicable.  For 
example, a set of pattern descriptions that are common to the urbanized area 
page size maps can be put in a file.  This file is then linked to an urbanized area 
map image file by the *inc command.

Combining and extending commands  These commands provide a means for 
making more complex cartographic objects out of basic commands and for 
extending the number and type of commands.  Basically they act like the *inc 
and *cls command pair in that they define the beginning and end of a group of 
commands that produce either a given map element or a process.

The *bef and *enf commands denote the beginning and end of a collection of 
meta-commands that should be treated as an object.  These can be used to define 
things like a legend, which is a group of text, lines, polygons, and even other 
*bef - *enf objects.  Because the object components can be treated as a single 
object, it can be manipulated as needed.  For example, during an interactive 
program, one may zoom in on a portion of a map and have a need to see the 
legend at the same time.  Since the legend is positioned relative to the whole map 
image, it may not be visible in the zoom area.  However, since the legend also 
can be an identifiable entity, a properly written program can translate the 
legend coordinates  and display it in the visible area of the display.

To ease creation of "sets" of entities encapsulated within a *bef and relative to 
each other, the *rel is used to indicate that all coordinates within the *bef are 
relative to the map inches position given in the *rel command.  Therefore, a 
symbol can be produced from a series of *str, *pgX and *vtx commands, each 
with coordinates relative to say the center of the symbol.  By using a *rel 
command within the *bef, only the *rel coordinates need to be changed to move 
the symbol to a different position.  The *rel command is only active within the 
*bef in which it appears, but does apply to subordinate *bef-commands.10

The commands that provide extensibility to the map image meta basic set are 
the *dep and *enp commands.  The *dep and *enp commands denote the 
beginning and end of a process to be performed on a set of meta commands.  For 
example, the process may be to display a triangle in a specific location and at a 
given angle.  The advantage is that a triangle symbol need only be defined once.  
Then encapsulating it between a *dep - *enp with arguments for x,y-position 
and angle creates a new command, say a *tri command (the * is not necessary), 
which will produce a triangle each time it is used.  Now, the symbol can be 
produced as many times as needed on the map image, but without having to 
fully describe all the bounding coordinates, the fill pattern, and so forth at each 
instance of the triangle. Thus, the original meta commands have been extended 
within this map image.

Basically the difference between a *bef-object and a *dep-extension is that a *bef 
does not expect arguments to modify or control instantiation while the *dep does.  
Put another way, *bef's are singular expressions of the contents of the *bef while 
*dep is instantiated as many times as needed, i.e., a legend would be a *bef 
while a cemetery would be a *dep.  One occurs once; the other occurs as many 
times as needed.

In addition to all other MIM commands, the following are operators that can be 
used within a *dep defined procedure:

Operation			Action denoted
	+		add
	-		subtract
	*		multiply
	/		divide
	sqt		take the square root
	cos		take the cosine(radians)
	sin		take the sine (radians)
	tan		take the tangent (radians)
	atn		take the arctangent (radians)
	=		set equal to
	==		test for equality
	!=		test for nonequality
	<		test for less than
	>		test for greater than
	<=		test for less than or equal
	>=		test for greater than or equal
	integer		a 32-bit integer or array of integers
	float		a 32-bit decimal number or array
	char		a character or character string
	[num]		designates an array of num size
	if...else...endif	if with optional else
	BRK		causes a jump out of the loop
	CON		jumps to the end of the loop
	while...wend	while a condition is true
	GETSTATE		returns the contents of a MIM state 
				variable
	PAR		parses a text string variable
	STO		stores a parsed value in a specified 
				variable
	DAT		performs the specified operation on an 
			associated data set
	**mimcmd	designates a MIM command that 
				addresses values indirectly
	$varname	specifies a variable
	$$varname	specifies a global variable
	static		designates a variable as static
	global		designates a variable as a global
	[more to be announced]
 
SPECIFIC COMMAND STRUCTURE

	DAT  $buf  datasetID  cmd  $ret	
			Places the contents a data set entry in the 
			text string $buf.  Aborts if the data set is not 
			previously defined in MIM.
cmd		TOP	moves to first entry in data set, returns a zero.
		NEXT	moves to next entry in data set, 
			returns the entry number or -1 if past end.
		PREV	moves to the previous entry in data set, returns 
			the entry number or -1 if past top.
		END	moves to the last entry in data set, returns the 
			entry number.
		#num	moves to the numth entry in data set, returns 
			the entry number or a -1 if past top or end.

	PAR  $buf  $ret		
		parses current entry pointed to in the current 
		data set and returns the number of tokens in $ret.
	STO   :toknum$var		
		stores the specified token into the specified variable.  
		Type conversion from text string to variable type is 
		automatic.

Objects and Command Extensibility
COOL considers a map as a collection of cartographic objects.  Each object 
consists of one or more cartographic primitives and/or other objects.  MIMs are 
constructed and should be processed from this same viewpoint.  The advantage 
of objects is that they provide an easy means for manipulating multiple 
primitives as if they were one object.  The use of objects also allows for the reuse 
of the same object between maps.

The following shows the difference between using an object definition and not 
using one.  The metafile containing a bar scale may look like the following:

*int	"Test Map"
*msz	10  15  inches   200
*lnw	0.005
*sft	RPTrip.Hft
*lnt	0
*vtx	2.90  1.20  0.10  0.0  "Bar_Scale"
10 Miles
...		(denotes other commands)
...
*str	4
2.0  1.10  2.0  1.00  3.0 1.00 3.0 1.10
...
...
*vtx	2.0  1.60  0.15  0.0  "Bar_Scale"
Scale
...
...
*vtx	1.95  1.20  0.10  0.0  "Bar_Scale"
0
*cls

Now an example of the metafile when the barscale is treated as an object:

*int	"Test Map"
*msz	10  15  inches   200
*lnw	0.005
*lnt	0
*sft	RPTrip.Hft
...		(denotes other commands)
...
*bef	"Bar_Scale"
*str	4
2.0  1.10  2.0  1.00  3.0 1.00 3.0 1.10
*vtx	2.0  1.60  0.15  0.0  "Bar_Text"
Scale
*vtx	1.95  1.20  0.10  0.0  "Bar_Values"
0
*vtx	2.90  1.20  0.10  0.0  "Bar_Values"
10 Miles
*enf
...
...
*cls

Using the *bef keeps the parts of an object together in the file.  Thus they can be 
more easily identified and manipulated.

Since no single set of primitive commands can efficiently describe higher levels 
of abstraction and complex actions, the command structure should provide for 
extensibility.  This means that a new command, symbol, etc. can be defined 
within the map image file.  That new element will then be able to be included on 
the final displayed or plotted map by merely including a reference to that 
element.  This concept will be more fully developed as MIMs evolve.

While the descriptions are similar, there is a difference between an object and 
an extension to the MIM commands.  The object is a description of a specific 
map element.  It has no ability to reproduce itself elsewhere on the map, or 
change its characteristics.  These must be done to it externally.  A extension is 
an abstract map element that will act on itself or other map components to 
reproduce the image.  Only the instantiation of the extension can be 
manipulated, not the extension itself.

Rules for MIM Construction

A MIM is constructed much as one would write a verbal description of a map 
image.  The rules for MIM construction are predicated upon the use of 
information in the sequence presented.
 
1.	A map image starts with an *int command.  The inclusion of optional 
information  in the *int command is strongly recommended.  This 
information is useful when searching for a given MIM on a storage 
medium that may have many of them.  For example, if the map ID is given, 
a simple search routine that checks the *int command in each MIM would 
be used to build an index of maps on a disk, CD-ROM or similar storage 
medium.

2.	A map image must close with a *cls command.  This is the only way that a 
file of multiple images can separate one image from another.

3.	All map image files must contain one and only one *msz command.  When 
placing the *msz command, it must be placed in the file ahead of any 
commands that include coordinates or patterns.  All coordinates or other 
metric values that occur within that MIM are assumed to be in terms of the 
units argument in the *msz command, e.g., if the units are centimeters, 
then all coordinates are assumed to represent measurements in 
centimeters.

4.	Defaults cannot be assumed.  Although some map series processing 
software have built in defaults, the MIM should always start by setting 
these values.  A MIM must have these values set before any *str, *vtx, or 
*pgX command is encountered.  The applications program can set any 
values desired.  Some values that have served as reasonable initial values 
in the past are,

line weights	0.005
line types	solid
line patterns	solid
fill patterns	solid
font		RPTrip.Sas

	Note that there are only three exceptions to the rule that there are no 
defaults.  Patterns 0 and 1 are already defined as all bits off and all bits on 
respectively, and the definitions are generally found throughout the 
industry.  Also, line type 0 means a solid line.

5.	*inc's must occur before their information is used.  Includes can be placed 
anywhere in the MIM.  The rule is that the included information must 
occur before any feature or attribute command references it.

6.	Attribute values continue to apply.  Once an attribute value has been set, it 
is applied to all subsequent commands as appropriate.  It is the 
responsibility of the applications software to insure that the proper attribute 
value is in force at all times.  The introduction of redundant attribute 
values, while not changing the image, take up file space and their 
occurrence is discouraged.

7.	Use of optional entity geoID argument.  Although the creator of a given 
map design is free to establish any geoID coding scheme desired, many 
map images have been generated using the ones listed in appendix F.  
Whatever coding scheme is used, the codes and their meaning should be 
placed after the *msz command at the top of the file and within comment 
commands.

NOTE:	geoID length should not be excessive.  At the U.S. Bureau of the 
Census the geoIDs are limited to a character string of not more 
than 31 characters.

	A given map design may require a different set of geoID arguments.   The 
principles underlying MIMs encourages appropriate use of any description 
in the argument.  Two things need to be kept in mind.  First, good form 
would be to specify the definitions at the top of the file through use of *cmt 
commands.  Second, a geoID must be one and only one argument.  The 
following are examples.

S76			Good
Major_Road		Good
"Green Briar Springs"	Good, but poor form.  Multiple words 
enclosed by quotes could cause difficulty.  
Better to connect words by underscore.

S76    C29 		Bad  Space makes two arguments
Major Road		Bad  Space makes two arguments
Green Briar Springs	Bad  No quotes, therefore three arguments

	Comments help provide information to users of the MIM about what codes 
are to be encountered and how they should be interpreted.  It is the 
responsibility of the program developer of the map specific software to 
produce programs that read this map file and handle the geocodes 
appropriate to that map.  There is no general procedure for handling 
geocode information, it is all map specific.  For example, two useful 
comments,

	*cmt	"geoID   MAJORWATER  denotes a water body that must be kept" 
	*cmt	"geoID   CFCC_nnn denotes a CFCC11 code"

	Following these comments, the map specific programs can interpret any 
entities with these geoIDs as appropriate to the operation and needs of the 
program.  Thus, if the program needed to display roads of a certain CFCC 
by a specific color, then the geoID with a CFCC as part of it would be further 
split by the program to determine what color to use.  For example, say roads 
of class A1 are to be displayed in an interactive program in red and all other 
roads in green, then the first string below would be displayed green and the 
second in red.

	*str	34	CFCC_1A20
	.  .  .  .  .  .  
	*str	18	CFCC_1A10
	.  .  .  .  .  .

	NOTE: The manner in which a feature is displayed depends upon the 
display program, it's purpose, and and the display hardware.  In no way is 
the display on given hardware constrained by the color, line type, and so 
forth that are stated in the MIM.  The MIM commands for color, line type, 
and so forth are followed, if and only if one wishes to faithfully reproduce 
the original map image.

8.	Use of optional entity state argument.  There are five states in which an 
entity may exist in a MIM.  

State				Denoted by
Active				Absence of state argument
Deleted				Xdel argument
Changed				Xchg argument
Added				Xadd argument
Reference			Xref argument

These arguments are provided so that entities modified by an interactive 
program may be flagged.  The value of these arguments depends upon the 
project.  For example, suppose one were investigating how a human 
operator designs a map.  After a computer program has produced it's 
version of the map image, a human operator may use an interactive 
program that allows modifications to be made to the image.  The program 
flags each modified entity with one of the state flags.  After a series of map 
images have been processed, the resulting MIMs can be examined to see 
what actions were taken by the operator.  Comparing the human actions 
with the original image file may yield an understanding of what rules were 
followed and lead to these rules being incorporated into future mapping 
programs.

The Xref argument is used to denote a feature or entity that is included in 
the MIM as an aid to processing.  It denotes a feature or entity that is not to 
be displayed as part of the image, but is to be used to aid in creating the 
image.  This is valuable in such operations as splitting text for stacking 
when the original text string needs to be retained.  Another example is 
when providing a coordinate string for automated positioning of text along 
it or a polygon within which text is to be constrained, but only using the 
coordinates for positional reference.  Since these features or entities are not 
part of the image, they can and usually will be removed from the files for 
public release.

9.	Portions of this documentation are in a MIM.doc file.  This file is either 
included with every MIM or in the case of multiple MIMs on a single 
storage medium, it may appear just once.  The file is not necessary to use 
the MIM for reproducing a map, but it helps.  Therefore, this file is 
important only when preparing MIMs for public release or archival 
storage.  If not included directly in a MIM, the documentation file should be 
referenced just after the *int and as shown below.  Note that this will add 
considerable text to your image file and should be used with discretion.

			*inc  MIM.doc

Rules for Reading MIMs

The rules for reading a MIM are set forth here only for general guidance to 
those who must develop interpreters for specific operations and/or display 
devices.  The design of a MIM interpreter becomes one of mapping the display 
device characteristics to the operations specified in the MIM.

The MIM command descriptions and rules for file generation fix the contents, 
syntax, and sequence of the file.  This in no way forces or fixes the interpretation 
of the commands.  If the commands can be followed faithfully, the original map 
image will be reproduced.  This either may be un-achievable or undesirable.  In 
the former case, the interpreter may be for a device that lacks the functionality to 
correctly render the MIM commands in terms of line weight, fill patterns, and 
so forth.  In the latter case, the interpreter may be part of an interactive editing 
system where deviations from the true representation enhance the ease of the 
edit operation, e.g., displaying certain map features in color when the original 
map is black and white.

Errors can be expected in spite of efforts to eliminate them.  Some syntax errors 
may make it impossible to meaningfully parse the commands of a metafile.  If a 
reasonable interpretation is possible, the error falls into the category of "do the 
best you can."  If it is impossible to guess reasonably, then the interpreter must 
either skip the command or abort the run until the file is repaired.

There are several approaches to creating MIM interpreters.  One is to only act 
on the information provided by the MIM and it's associated "include" files.  This 
has the advantage of guaranteeing a reproduction that matches the file.  The 
other approach is to assume some default values.  The following are values that 
are frequently found in census maps:
 
Default attributes values
Line type:		solid
Line width:		0.005
Line pattern:		solid (all bits on)
Line color:		black
Fill pattern:		solid (all bits on)
Text font :		Roman Plain Simplex Hershey font

Since MIM records do not have fixed fields, the interpreter must have some 
means of parsing the MIM records.  The difficulty of this operation is directly 
related to the programming language chosen by the user.  Experience has 
shown that writing a parsing routine in FORTRAN is somewhat more difficult 
than writing one in C or one of the modern versions of BASIC.

Appendix E gives the code for a simple parser written in the C computer 
language.

Once the MIM record is parsed, the rules for interpretation of the arguments 
are more defined.  The rules may be stated as follows:

1.	Read the MIM until a *int command is encountered.  Then and only 
then initiate the map image.

2.	Continue to read until a *msz command is encountered.  Extract the 
map size and resolution.  Set up processing factors such as display 
scale, initializing plot size, and so forth based upon these values.  If a 
*msz is not found before a *cls is encountered, abort the run; this is a 
bad MIM.

3.	Return to the top of the MIM and process forward from the *int.  This 
is done in case the *msz is not the first executable encountered - 
though it should be.

4.	Process each command in turn until a *cls is encountered.  This 
signals the end of the file.

Appendix F provides a MIM interpreter written in psuedocode.  This is the 
simplest form of an interpreter and is not suitable for interactive work.  To load 
the MIM into a program that will allow interaction or changes to the MIM, the 
basic procedure for reading the MIM is the same.  However, as the information 
is read, each MIM entity (*str, *pgX, *vtx, etc.) must be stored with all 
associated attributes.  Failure to do store all the entities and attributes means 
that at best the program must reread the entire MIM every time some action is 
performed such as a zoom or pan of the displayed image.  At worst the file 
cannot be changed and reconstituted after interaction.

Appendix A
COOL Map Component Definitions

Every map image consists of certain components such as legends, image area, 
graphics scale, and so forth.  For purposes of describing these to a computer 
program, certain COOL12conventions were adopted to use in a MIM.  The 
following defines a minimum set of COOL definitions used in MIM development

Frame line  -  this line defines size and shape of the area in which 
components of the maps itself are displayed.  Folio information such as 
page numbers, map title, and so forth may appear outside this frame -- or 
may not, depending upon the map design.  This defines the envelope, not 
the exact shape of the frame.  The shape, if displayed, may be denoted by a 
geoID such as Frameline on the string and/or polygon of the area.  Frame 
lines are not mandatory.

Outer Image Line  -  this defines the maximum envelop of a map image.  
Generally no parts of a map image are expected to go beyond this.  This 
defines the envelope, not the exact shape of the outer image area.  The 
shape, if displayed, may be denoted by a geoID such as OuterImageLine 
on the string and/or polygon of the area.

Neatline (Map Image Area)  -  this defines the limits of the area within a 
map in which an image will be displayed.  There may be multiple map 
image areas per map page.  This defines the envelope, not the exact shape 
of the map image area.  The shape, if displayed, may be denoted by a 
geoID such as Neatline on the string and/or polygon of the area. 

Entity Latitude/Longitude Envelope  -  this is the maximum and minimum 
latitude /longitude of the entity being displayed.  Usually it is required 
when an entity is free to float within an image area.  These values relate 
to the entity maximum/ minimum map inches envelope described below.  
This relationship allows the computation and positioning of 
latitude/longitude or other reference grid ticks.  This is particularly 
valuable when moving the entity's position within the image area.  
Obviously, not all maps require this relationship.

Entity Map Inches Envelope  -  this is the maximum and minimum map 
inches of the entity being displayed.  Usually it is required when and 
entity is free to float within an image area.  These values relate to the 
entity maximum/ minimum latitude/longitude envelope.  This 
relationship allows the computation and positioning of latitude/longitude 
or other reference grid ticks.  This is particularly valuable when moving 
the entity's position within the image area.  Obviously, not all maps 
require this relationship.

The following graphic describes the relationship of these components to each 
other.

                                                                    

Example in terms of MIM commands

                                                                       

Appendix B
Metafile commands

Required commands
1.	*int	[alphanumeric map ID]	
Indicates beginning of map commands.  This may or may not be followed by text 
elaborating on such things as the name of the map, project, etc.  The comment 
command can be used for the same information.

Example:   *int   "UAP346001"
	for page number 1 an urbanized area map for UA number 3460.

Example:   *int   "Percent High School Graduated of Total Population (1990)"

2.	*cls	
Indicates end of map metafile.

Example:   *cls

3.	*msz	x y units resolution
Gives the maximum physical size and the units of measure for all elements of the 
map sheet.   Since all map images are designed for reproduction on a specific 
device, the resolution of the device is given in terms of pixels (dots) per unit.  This 
provides the necessary parameters for reproducing screen patterns and for 
providing the "true" texture to the map symbols, line, and so forth.

Example:   *msz    22.5   17.0   inches  508

Optional commands

4.	*bef	[feature_ID] [feature_status]
	.	.	.
	.	.	.
	.	.	.
	*enf	[feature_ID]
Indicates the beginning and end of a feature.  This is useful when multiple 
entities make up a single map image feature and one wishes to keep the entities 
together in the MIM.  The optional feature ID is strongly suggested to separate 
*bef's and may be added for clarity  at the *enf command when feature 
definitions are nested or complex.

Example:	*bef       North_Arrow_Symbol
	*cmt	This is a north arrow symbol.
	*str	 6 	.	.	.	
	.	.	.	.	
	.	.	.	
	*enf       North_Arrow_Symbol

5.	*cmt [any string of characters]
Indicates a comment.  This may be any string of characters.  If the parts of the 
string are to be treated as one unit, the whole string must be enclosed within 
double quotes.  This command is  very useful when passing environmentally 
dependent information and file descriptor information.

Examples:	*cmt  "Page size county boundary map for Georgia"
		*cmt   rotate image 90.0 degrees
		*cmt "PROJECTION: Albers Equal Area"
		*cmt "                 Lamda = center if geographic entity."

6.	*dlt	number_changes  line_type_ID [-cap arg]
				[-join arg]
Line types (styles) are defined as a sequence of  pen ups and downs to be used 
when drawing the lines for these features.  This command relates a pen up/down 
sequence to a line type ID.  All values are given in terms of the decimal units of 
the map.  Dash lengths are denoted by the minus values while the positive values 
denote the space between dashes.  The optional arguments -cap and -join are 
provided to enhance the image quality.13  The -cap argument specifies the 
characteristics of the end of the line, while the -join argument specifies the 
characteristics of the point at which two lines join.  Acceptable arguments for 
each are,
	-cap		butt		round		square
	-join		beveled	round		mitered
The default is determined by the output device's default.

Example:	*dlt    2     myDashDot	 -cap  butt     -join  round
		-0.50	0.10	-0.01	0.20

7.	*dpa	matrix_side_size  pattern_ID	[pattern_Angle]
Patterns are defined in terms of bits-on/bits-off in a matrix of 4 by 4, 8 by 8, 16 by 
16, or 32 by 32.  Matrix side size gives the size of the matrix.  The pattern is known 
to all successive references to this pattern by the pattern ID.  The angle argument 
is a decimal degree angle at which the pattern is to be plotted.  This argument is 
optional and its absence causes a default to angle of 0.0.  A *dpa command must 
occur somewhere before any references to the pattern ID.

Example:	*dpa	4	pat_31	30.0
1	0	0	1
0	1	1	0
0	1	1	0
1	0	0	1

See also *dpa in Currently unimplemented Commands section that 
follows.

8.	*fcp	color_ID
	*fcs	color_ID
	*fcv	color_ID
Sets the pattern color for successive *pgX, *str and *vtx commands respectively.  
The color ID must have been defined earlier in the file.

Example:   *fcs	myPurple

9.	*fpp	pattern_ID  -rule
	*fpv	pattern_ID  -rule
Sets fill pattern for successive *pgX, and *vtx commands respectively.  Each 
applies only to its respective feature type.  This command defines the fill pattern 
to be used when drawing the lines for these features.  Sets the fill pattern to the 
specified pattern ID.  The pattern_ID is an alphanumeric identifies that is 
defined by a preceding *dpa-command.  The application of the fill patter is 
governed by the optional application rule argument.  If the argument is not given, 
the default rule is to use the transparent application rule.  -tran denotes a 
transparent rule; -opaq denotes an opaque rule; and -eras denotes an erase rule.  
(Rules detailed in appendix.)

Example:   *fpp	31	-OPAQ

10.	*inc	filename
Identifies a file  whose  contents are to be included at this point in the metafile 
being processed.

Examples:	*inc	"mysymbols.fil"
		*inc	"mypatterns.fil"

11.	*lcs	color_ID
	*lcp	color_ID
	*lcv	color_ID
Sets the line color for successive *str, *pgX, and *vtx commands respectively.  
The color ID must have been defined earlier in the file by a *rgb command.

Example:   *lcs	myPurple

12.	*lps	line_pattern_ID  -rule
	*lpp	line_pattern_ID  -rule
	*lpv	line_pattern_ID  -rule
Sets line pattern for successive *str, *pgX, and *vtx commands respectively.  
Each applies to its respective feature type.  This command defines the line pattern 
to be used when drawing the lines for these features.  Each line pattern is an 
alphanumeric identifies that must have been previously defined by a *dlp 
command.  The application rule argument is optional.  See *fpp for discussion of 
rule argument.

Example:	*lps	31

13.	*lts	line_type_ID (is an alphanumeric identifier)
	*ltp	line_type_ID (is an alphanumeric identifier)
	*ltv	line_type_ID (is an alphanumeric identifier)
Sets line type for successive *str, *pgX, and *vtx commands respectively.  Each 
applies to its respective feature type.  It is defined by a *dlt command.

Example:            *lts      myDashDot

14.	*lws	line_width
	*lwp	line_width
	*lwv	line_width
Sets line weight (width) for successive *str, *pgX, and *vtx commands 
respectively.  Each applies to its respective feature type.  This command defines 
the line weight to be used when drawing the lines for these features.  Line width is 
given in decimal units of the map as provided in the *msz command.

Example:	*lws	0.005

15	*pgX	number_of_polygons points_in_first_polygon 
fill_boundary_flag [feature_ID] [feature_status]
Defines a polygon.  Acceptable values for the fill_boundary_flag are,

F	Fill only, do not draw boundary.
O	Only draw the boundary of the area, do not fill it.
B	Fill the area and draw the boundary.

Example:	*pgX	2	5	F 	Augusta	Xchg
	2.0	2.0	6.0	2.0	6.0	5.0	2.0	5.0	2.0	2.0
	2	4
	3.0	2.7	4.6	2.7	3.5	3.1	3.0	2.7

16.	*rel	map_units_X  map_units_Y
Only has meaning when used within a *bef; it indicates that all 
succeeding coordinates within this *bef are given relative to 
this point and not to the map in total.  The effect, i.e., scope 
of a *rel ends with the *enf of the *bef to which it refers.

		Example:	*rel	8.75	2.55

17.	*rgb	v1 v2 v3  color_ID
The *rgb is a defining command that sets the relationship between a color in RGB 
scheme and a color ID used within the MIM.  All values are integer numbers 
ranging from zero to 255, i.e. 256 values per color.  This gives a total of 16,777,216 
colors.

Example:	*rgb	255	0	127	myPurple

The color ID  argument allows use of this name in subsequent color referencing 
commands.

Example:	After defining, to set the line color, issue the command
		*cvp	myPurple

18.	*sft	font_type_name	[fillFlag] [-slope arg]
                [-widthFactor arg] [-kerning OFF/ON]
                [-spacingFactor arg]
Sets the font type to the font type name specified.  The optional characteristics are 
things such as a flag that denotes to fill or not the interior of the character, letter 
spacing other than default, and so forth.

Example:   *sft	RPTriplex.Sas
	*sft	RBHev.Oas      B      -slope -20.0 

19.	*str	number_of_points [string_ID] [string_status]
Denotes a string of coordinates.

Example:	*str	4	Triangle	Xadd
		3.0	2.7	4.6	2.7	3.5	3.1	3.0	2.7

20.	*vtx	x y h a [text_ID] [text_status]
Indicates vector text.  The start position of the text is given by x and y, while the 
text  height and angle are h and a respectively.  An 

Example:	*vtx	3.2	1.7	0.5	30.0	M130095001
		"Red River Road"

Currently unimplemented commands

21.	*aka	original_text_string  alias_text_string
Identifies an alias.  After an aka command,  every time the alias text string is 
encountered during processing, the original text string is substituted for it.  If a 
text string consists of more than one word, the text must be enclosed within double 
quotes.
Example 1:	*aka	"draw_my_triangle"	"*tri"
Example 2:	*aka	"*rgb	255	0	127"	myPurple
Example 3:	*aka     "*draw_Square"      "*dsq"
The *aka in example 1 indicates that anytime the text *tri appears in the metafile 
after this *aka, it is taken to mean draw_my_triangle.  Likewise, anytime after 
the aka in example 2 that the text myPurple is encountered in the metafile, it is 
taken to mean the *rgb 255 0 127 text string., i.e., myPurple becomes another way 
of issuing that specific *rgb command.The double quotes should be considered as 
necessary.

22.	*dep	procedure_ID  [[arg] [arg] ... [arg]]
	.	.	.
	.	.	.
	.	.	.
	*enp	[procedure_ID]
Indicates the beginning and end of a procedure definition.   Useful for reducing 
the size of the metafile by being able to incorporate repetitive type command 
sequences into a single new command.  The optional procedure ID may be added 
to the *enp for clarity  when definitions are nested or complex.

Example:	*dep       *draw_Square  $1  $2  $3 
*cmt   "$1 is size of the sides of the square"
*cmt   "$2 is the x-value of the center of the square"
*cmt   "$3 is the y-value of the center of the square"
$2  $1  2.0  / - $4 =
$3  $1  2.0  / - $5 =
$2  $1  2.0  / + $6 =
$3  $1  2.0  / + $7 =
**str  5
$4 $5  $6 $5  $6 $7  $4 $7  $4 $5
*enp
			.	.	.	.
			.	.	.	.
			.	.	.	.
		*draw_Square   0.25   24.001   13.345  15.0
			.	.	.	.
			.	.	.	.

See section on *dep - *enp command for details about internal operators and use.

23.	*dat	data_set_ID
		.	.	.
		.	.	.
		.	.	.
	*end
Indicates the beginning and end of a data set that contains zero or more data 
elements.  A data set can be referenced only from within a *dep-*enp command.  
The data_set_ID must always be present because there may be multiple data sets 
within the MIM.  A data set cannot contain other MIM commands except *cmt.  
The *cmt is strongly recommended as a means of elaborating on the data set 
structure and meaning.  The need for elaboration is more pressing when the data 
set consists of variable length elements and the start of each element needs to be 
readily identified to the user.   A data set is part of the full description of a map .   
A data set must be part of a MIM or included within a MIM by means of a *inc 
command before it is referenced by any other command.

Example 1:
*dat 	"CountyCornClasses"
*cmt "1994 United States Census of Agriculture "
*cmt "Classed data for choropleth map of Corn Production by County"
*cmt	"First value is the FIPS state/county code; 2nd value is the county class"
01001	4
01003	3
01005	4
02001	4
.	.
.	.
.	.
57001	2
57003	3
*end

Example 2:
*dat 	"RPTrip.Sas"
*cmt "Roman Plain Triplex Stroke ASCII font file"
*cmt "This file contains the vector descriptions of each character in the RPTRip.Sas"
*cmt "font.  This font is derived from the Hershey font sets placed in the public "
*cmt "domain by  the U.S. Government."
*cmt	"The > character in the first position denotes beginning of a data element."
>001	0	0	"Not used"
>002	5	3	"A"
2.34	4.56	2.65	2.11	2.88	1.01
>003	0	0	"Not used"
.	.	.	.	.
.	.	.	.	.
.	.	.	.	.
*end

Example 3:
*dat 	"MIM Documentation"
The meaning of each MIM command is based upon the premise that elements 
of a graphic image are being described; specifically, elements of a map 
image.

When the ....

*end

Inactive commands
	*pgX	number_of_polygons points_in_first_polygon 
[feature_ID] [feature_status]
NOTE: This is the old form of the *pgX command.  Does not contain the FOB 
argument.
	*dpa	matrix_side_size  pattern_ID
NOTE: This is the old form of the command.  It does not contain the angle 
argument.
	*lnt	number_of_changes	(1992) [see line type command]
	*lnp	line_pattern_ID	(1992) [see line pattern command]
	*lnw	line_width		(1992) [see line width command]
	*pat	pattern_ID		(1992) [see pattern command]
	*cir		(1990) draw circle
	*pdn		(1990) pen down
	*pup		(1990) pen up
	*pud		(1990) pen up/down, defined line type
	*rot		(1990) rotate image
	*txt		(1990) plot hardware dependent text
	*fnt		(1990) set type font

Appendices C
Cartographic Font Files

The cartographic font files are provide to aid in production of a MIM.  Other fonts 
can be defined and used, but the ones listed here are the only ones used to date to 
produce census maps.  Currently, they are implemented on three platforms: VAX 
VMS in FORTRAN, Tektronix Unix in C and Silicon Graphics Unix in C.

Currently active font files.

RPTrip.Sas		Roman Plain Triplex Stroke hershey font
RPSimp.Sas		Roman Plain Simplex Stroke hershey font
RPSlim.Sas		Roman Plain Slim (Simplex) Stroke hershey font
IPTrip.Sas		Italic Plain Triplex Stroke hershey font
IPSimp.Sas		Italic Plain Simplex Stroke hershey font
IPSlim.Sas		Italic Plain Slim (Simplex) Stroke hershey font
RPHev.Oas		Roman Plain Helvetica Outline mapping font
RBHev.Oas		Roman Bold Helvetica Outline mapping font
IBHev.Oas		Italic Bold Helvetica Outline mapping font
IPHev.Oas		Italic Plain Helvetica Outline mapping font

Appendix D
Simple MIM Interpreter Psuedocode

place includes here
 
main(arg, argv)
int   argc;
chaw  *argv[];
{
Set up variables and initialize them as required.
Check fo input metafile and open it.
Open support filessuch as fonts.
Stgp thru meta file }ooking for msz command and extractvalues when found.  If not 
found, abort run.
Initial graphis sysem.
Rwind metafile
1.	More records in metafile?  If NO, end run.
2.	Get record.  These are expected to be command records.
3.	Parse record.
4.	Is it a -
a.	*str, then extract points and plot using current attributes. Go to 5.
		Example:
if ( (strcmp(tokenStrPtrs[0], "*str") == 0 )
   {
   k = atol(tokenStrPtrs[1]);  /* Number of pts */
   n = 0;
   while(k > 0)
     {
     fptr = fgets(recBuf,130, metaFilePtr);
     numToks = parseTokens(recBuf);  /* Pts this rec */
     for (j = 0; j < numToks; j++)
        {
        fx = atof(tokenStrPtrs[j]) * scaleFac + offset;
        j++;
        fy = atof(tokenStrPtrs[j]) * scaleFac + offset;
        if(n == 0)
          {
          MOVE(fx,fy);
          n++;
          }
        else
          DRAW(fx,fy);
        }
     k = k - (numToks/2);
     } 
   continue;
   }
b.	*pgX, then extract points and plot using current attributes.  Go to 5.
c.	*vtx, then extract values and text record and plot using current 
attributes.  Go to 5.
d.	*sft, if same as current, take no action.  If not, then set the current 
font to this type.  Go to 5.
e.	*lnw, if same as current, take no action.  If not, then set the current 
line weight to this value.  Go to 5.
Example:  if ( (strcmp(tokenStrPtrs[0],"*lnw") == 0 )
   {
   currentLineWeight = atof(tokenStrPtrs[1]);
   continue;
   }
f.	So forth with all attribute commands.
g.	Not recognized command, go to 5.
5.	Go to 1.
End program.

Appendix E
parseTokens Function
/* Utility function that successively parses the string passed to it in the
  function argument until all the tokens in the string have been extracted
  and stored in a global array of tokens.  The function returns the number
  of tokens found.  Pointers to the tokens are returned in another global
  array.  See parseTokens.h for definition of global arrays.              */
/* F. R. Broome            *********************           20 August 1990 */

#include <stdio.h>
#include <string.h>

char           tokenStrings[64][128];     /* Globals for passing tokens.   */
char           *tokenStrPtrs[64];         /*Include as externals in program*/

#define        QUOTE       34  /* This is the double quote. */
#define        COMMA       44
#define        SPACE       32
#define        CR          13  /* Carriage return */
#define        LF          10  /* Line feed       */
                               /* NULL already defined elsewhere. */

long int parseTokens( inString )
          char     inString[];   /* Incoming text string. */

{
extern char     tokenStrings[64][255];
extern char     *tokenStrPtrs[64];

long int        i, kount = 0, charCnt = 0, numTokens = 0, flag;
char            *inStrPtr = inString;   /* Establish a pointer to inString */
char            *tokenStart = NULL;     /* Initialize to 0 */

/* Check to see if the incoming text string has any characters to process. */
charCnt = strlen(inString);
if( charCnt < 1 ) return(numTokens);                   /*No string passed. */  

/* --- Capture and store all tokens in this string.  --- */
*(inStrPtr + charCnt ) = NULL;      /* Force NULL to terminate the string. */

while(charCnt)
  {
  /* Check for end of string. */
  if((*inStrPtr == NULL)  || (*inStrPtr == CR)  || (*inStrPtr == LF))
    break;                                /* End of input string detected. */
  /* Ignore spaces and commas in front of tokens. */
  if((*inStrPtr == SPACE)  || (*inStrPtr == COMMA))
    {
    inStrPtr++;
    continue;  /* Skip to bottom of while loop for and thence to next char */
    }

  /* Have detected a possible token character. */
  tokenStart = inStrPtr;        /* Set pointer to head of potential token. */
  kount = 0;                    /* Set token character count to zero.      */
  
  if(*inStPtr == QUOTE)       /* Check for the special situation of QOTE */
    {
    tokenStart++;             /* Set to next uossible char as token sart */
    inStrPr++;            q  /* Set ths pointer to next character.      */
    while((*inStrPtr != QUOTE)                  /* Check for ending QUOTE. */
         && (*inStrPtr != NULL)    /* Check for other string ending chars  */
         && (*inStrPtr != CR)  && (*inStrPtr != LF))
      {
      kount++;                       /* Increment token character counter. */
      inStrPtr++;                    /* Move token character pointer.      */
      }   
    /* Falling through to here indicates that all characters of the        */
    /*    quoted token have been found.  NOTE: End of string is considered */
    /*    to be equal a double quote.                                      */
    }
  else                      /* token is not quoted. */
    {
    flag = 1;
    while(flag)
      {
      switch (*inStrPtr)      /* Use the character ASCII value for check. */
        {
        case  NULL:
        case  CR:
        case  LF:
        case  SPACE:
        case  QUOTE:
        case  COMMA:
             flag = 0;      /* End of token found. */
             break;
        default:
             kount++;               /* Increment token character counter. */
     ..      inStPtr++;            /* Increment textstring pointer.     */
        }  /* End switch. */
      }..  /* End flag while-loop */
    } }    /* End else condition  */

  if(kount)    /* If there i one or more characters in token. */    
 .  {        . /* then move the token to the global array.     */
    for( i = 0; i < kount; i++)
      {
      tokenStrings[numTokens][i] = *(tokenStart + i);
      }
    tokenStrings[numTokens][i] = NULL;  /* Terminate with NULL */
    /* Store the pointer to this token. */
    tokenStrPtrs[numTokens] = &tokenStrings[numTokens][0];
    numTokens++;
    }
  if(*inStrPtr == QUOTE)
     {
     inStrPtr++; /* Increment past any ending quote. */
     } 
  if(*inStrPtr == CR  ||  *inStrPtr == LF  ||  *inStrPtr == NULL)
    {
    charCnt = 0;  /* Set value to kick out of while-loop */
    }
  }   /* End while-loop */
        /* Now have all tokens from this string.  Return the count. */
return(numTokens);
}

Appendix F
U.S. Census Map GeoID and Parameter Examples

The use of nnn sequences in the descriptions below denote a series of numbers.  
FIPS14 codes are used when possible.

GeoID			Denoted by
State			Snn
County			Cnnnnn
Minor civil division	Mnnnnnnnnnn
Census county division	mnnnnnnnnnn
Place			Pnnnnnnn
Census designed place	pnnnnnnn
AI/ANA   (American Indian/Alaskan Native American)
	Reservation		Innnnnn
	Tribal trust		Tnnnnnn
	Individual trust	Nnnnnnn
	Tribal designated statistical area	dnnnnnn
	Tribal jurisdiction area	knnnnnn
	Alaska native village statistical area	Hnnnnnn
	Alaska native regional corporation	Wnn
Subbario		Lnnnnnnn
Urbanized area		Unnnn

Double line water shore		SHORELINE

Some useful parameter comments [map design and processing dependent]:
Old font spacing flag		Param_OLD_TEXT_SPACING
Map scale			Param_Scale	(denominator of RF)
Map type			Param_MapType
Map file number for multiple files	Param_FileNum
State code for grid reference		Param_GeogridStateCode	(FIPS)
Map entity envelope		Param_EntityMinLon
				Param_EntityMaxLon
				Param_EntityMinLat
				Param_EntityMaxLat
				Param_EntityMinX
				Param_EntityMaxX
				Param_EntityMinY
				Param_EntityMaxY
Neatline			Param_NeatlineMinX
				Param_NeatlineMaxX
				Param_NeatlineMinY
				Param_NeatlineMaxY
Outer image envelop		Param_OuterImageMinX
				Param_OuterImageMaxX
				Param_OuterImageMinY
				Param_OuterImageMaxY
Frame line			Param_FrameMinX
				Param_FrameMaxX
				Param_FrameMinY
				Param_FrameMaxY

Some useful geoIDs to denote special relationships between map image 
entities when placed within *bef-*enf structures. The {...} denotes 
optional part of geoID.

Areal feature with associated text		AREF_{...}
Linear feature with associated text		LINF_{...}
Areal text with associated arrows		ARROW_TEXT{...}
Parts of split text associated with original	SPLIT_TEXT{...}
Fishhooks between areas				FISHHOOK

NOTE: geoID's are limited in Census Bureau software to a character string 
of not more than 31 characters.

Appendix G
Pattern Application Rules

Several pattern command have an optional application rule.  These rules tell the 
output device how the map designer intended the pattern to be applied to that class 
of entities.  There are three rules, the transparent rule, the opaque rule, and the 
erase rule.  While there is no operational reason why the rule names have to be 
denoted by a minus sign followed by a four letter lower case name, it is 
recommended that they be so designated.

-tran		Transparent  overlay.  The ON-bits in the pattern definition are set to 
ON in the output image and the OFF-bits in the pattern have no effect.

Pattern bits				0011
Existing entity bits			0101
Resulting entity pattern		0111

-opaq		Opaque overlay.  The ON- and OFF-bits in the pattern definition 
determine the pattern in the output image, i.e., both ON- and OFF- bits have an 
effect.

Pattern bits				0011
Existing entity bits			0101
Resulting entity pattern		0011

-eras		Erase overlay.  The ON-bits in the pattern definition are set to OFF in 
the output image and the OFF-bits in the pattern have no effect.

Pattern bits				0011
Existing entity bits			0101
Resulting entity pattern		0100

These pattern application rules are provided to allow for description in the MIMs 
of several normal cartographic (map generation) operations.
1The first computer was a Univac (UniSys) mainframe with a 36-bit word structure and 
the Exec-8 operating system.  The computer system was a Digital Equipment VAX with a 
32-bit word structure and the VMS operating system.  Currently development and 
production are on Unix-based workstations.

2The first was FORTRAN on the UniSys; the second was FORTRAN on the VAX; the most 
recent is some FORTRAN, but mostly C in a UNIX environment on many types of 
computers, including PC-based systems.
3The term meta was selected in the sense of beyond the mere image, transcending a given 
computer or display environment, and more comprehensive than a purely machine 
readable hardware image exchange format.

4Development of the MIM concepts started in 1989.  The first MIM files were produced in 
1990.  Version 1.0 of the MIM commands used at that time were considered cumbersome 
and produced files that were four to five times larger than current MIM files for the same 
map.  Additionally, the commands depended too much upon hardware text and fonts.

5Almost all census maps are created as black and white raster plots.  By equating a raster 
to a bit, if the bit is on, a dot is plotted there, or if off, nothing is plotted.  Techniques for 
saving such bit images have been available for decades.
6The Federal Information Processing Spatial Data Transfer Standard is a data exchange 
standard that satisfies geographic data transfer needs very well.  Indeed, the definitions of 
cartographic entities used in MIM were extracted from the SDTS.  The comprehensive and 
detailed nature of the SDTS was deemed to be more extensive than that required for map 
image exchange within the production environment, thus the MIM was developed.

7The PDEF, Protean Data Exchange Format, recently developed and placed in use by the 
U.S. Army Corps of Engineers, Engineer Topographic Laboratories, is similar to MIM in 
raison d'etre.  PDEF, however, is presented as a standard file format for data interchange 
in opposition to or as an elaboration of SDTF while MIM is not.
8Cartographic Object Oriented Language (COOL)  An unpublished research work that 
describes basic primitive graphic entities and their attributes and then describes the map 
in terms of arrangements of these primitives grouped into map elements (cartographic 
objects)such as neatline, legend, image, inset, and so forth.  COOL avoids the problem of 
having to have dictionaries of all possible map sysbols and their associated meaning with 
variations.  It does so by incorporating the description, both graphically and textually, into 
the map image structure.
9Consideration is being given to allowing argument field descriptors so the sequence or 
number of arguments can be altered as needed.  In the absence of a positive entry to the 
contrary, the command arguments are to be interpreted in the sequence established in each 
command definition.
10While the effect of a *rel only affects the coordinates within the *bef, image entity state 
values, if set within a *bef, will stay in force upon exit from the *bef.
11CFCC stands for the Census Feature Class Code scheme developed and used by 
the U.S. Bureau of the Census in their TIGER system.
12 Several cartographic text were referenced when developing these 
definitions.  Among them, though not all of them, are Elements of Cartography 
by Robinson et al and Cartographic design and production by J. S. Keates.
13 The cap and join of a line can be modified in numerous graphics languages.  
The following show the terms used in three of the common languages:

Specifying the characteristics of the end of a line -
	X-Windows		CapButt	CapRound	CapProjecting
	PostScript		butt cap	round cap	projecting square cap
	HP-GL/2			Butt		Round		Square
Specifying the characteristics of the point of join of two lines -
	X-Windows		JoinRound	JoinMiter	JoinBevel
	PostScript		round join	join		bevel join
	HP-GL/2			Round		Mitered		Beveled

14FIPS are Federal Information Processing Standards of the United States 
government.  They provide standardized codes for various levels of geography 
and are issued by the National Institute for Standards and Technology in the 
Department of Commerce.