Re: hardcode.pgm anomaly--methodology

["Patricia M. Godfrey" priscamg@xxxxxxxx]

No go, Harry, I tried running your program. Now first of all, I
DO reset counters--quite often. It appears that you have to after
a chapter counter (C0; that's zero, not oh), which doesn't reset
automatically. And I have to after my One, Two, Three type part
numbers too. Secondly, I got "Command not recognized," and
nothing happened.
I've been thinking about this and on second thoughts, perhaps a
printer driver and typf is the only way to go. Because whatever
routine you use will have to juggle several things in memory
simultaneously: the value of the next-high$est counter, the value
of the one above that, and so on. Because every time you
increment a counter, you reset all the counters below it in the
hierarchy. BUT you don't want to change anything else.

So two possibilities present themselves:
1. You create a printer driver that changes NOTHING in the file
except the autocounters. ASCII.PRN does NOT do that; it strips
out all the high-ASCII/Speedos chars, not to mention formatting.
But I don't know enough about printer files to know if that's
possible.
2. You write an XPL routine that uses ≪NM1≫...≪NM0≫ formatter
to mark off all DC and Cx commands. Then it changes all other
formatting guillemets to ≪≫, then it loads ascii.prn and typfs
the file, then it calls fo.tmp and restores all the formatting
guilements by changing ≪≫ back to their control char values.
Anyone know of any reason that wouldn't work?
--
Patricia M. Godfrey
priscamg@xxxxxxxx