As Microsoft WORD becomes the not only the default word processor, but the
ONLY document preparation tool known on the planet, developers of Proform
template files find themselves dealing with a contrary tool.
<p>
Proform was written when word processing programs were expected to do a 
decent job of optimizing their output to drive a known printer.  They 
were expected to be aware of the internal fonts on the printer and make use
of them.  Since printers were connected by moderate speed parallel or low
speed serial ports, it was expected the output of a word processor print
driver was no more that the minimum necessary to get the ink on the paper.
<p>
Alas, those days are long gone.   Most printers are either have internal
network connections or USB.    HP, in its infinite wisdom, has decreed that
their printers will DENY THE EXISTENCE of the internal fonts built into
the printer when presented with PCL version 6 or higher.  (They still admit
to, and properly process, internal scalable fonts when presented with older
PCL versions, for obvious backward compatibility reasons.)  WORD never was
as consistent and clean in its creation of template files, and each new
version has gotten worse.  
<p>
The BIGGEST problem with WORD is that it no matter whether you have kerning
turned on or off, it wants to kern words.  Thus, when you lay out a form with:
<pre>
	[state]
</pre>
<p>
it just cannot leave it alone.  It will decide to move the "s" a couple 
pixels to the left or right.  This behavior is completely random, and can
shift based on what is next to this field, the barometric pressure, or
the current futures prices for hog bellies.   So what you get in the 
template file might be:
<pre>

	[state]
or
	[ Escape1224X state] 
or
	[st Escape1224X ate] 
or
	[s Escape1224X t Escape1224X a Escape1224X t Escape1224X e] 
</pre>
For a long time we persisted in the delusion that if you were careful in 
turning off kerning and making sure the character spacing was exactly 1
that this could be dealt with.  
<p>
We decided that it is such a nuisance that a brute force approach is 
called for.   Hence the "rmcurpos" utility.   After printing your template, 
run it thusly:
<pre>
	rmcurpos template-file-name > new-template-name
	Found [state-1X]. Squish? y
	OK: [state].
	Found [-1Xzip]. Squish? y
	OK: [zip].
	Found [d+1Xue-date]. Squish? y
	OK: [due-date].
</pre>
It will scan for things that look like field markers.  If the field marker
has an ESCAPE character in it, it will present it to you for review. 
Press y and it will remove all cursor motion strings from the string. 
Note that what you see on the screen is the character representation. 
the actual string would be interpreted as ESCAPE and several binary
digits with pixel positions, followed by an X.  However, for the brute
force purposes of this utility, we don't care what those binary numbers
mean. 
<p>
Rmcurpos uses the same scanning logic as Proform, which means that it 
might find a [ in your template which is unrelated to a field marker.
If that is not matched up with a ] within 400 characters it will assume
that was a false alarm and get on with life.   It is dimly possible your
file could contain a pattern that will make it latch onto something which
isn't a field marker.  That's why the dialog.    After running it the 
first time, you will know whether that's a factor for you.   If not, 
on any subsequent run you can use: 
<pre>
	rmcurpos template-file-name -y > new-template-name
</pre>
and it will skip the dialog.