RE: [Groff] illegal input characters in troff

[Egil Kvaleberg]

On Thu, 9 Mar 2000, you wrote:

> At present, in groff, eqn generates the error message
> 
>   illegal input character code `13'
> 
> but troff seems to ignore it (I think all components of groff should
> treat it the same way). NOW: Should it be ignored

Yes.

The present error message is a real nuisance, at least for people like me
who occasionally dump into *roff-like material that originated from Dos. 

> Should (as in PostScript), \n, \r\n, \n\r, \r all
> be equivalent (and all internally translated to \n)?

If that can be implemented absolutely painlessly, then yes, why not? If it
is done, it should be like that in all preprocessors too. I would not give
such a feature high priority, though. (But then, I'm never using Macs).
 
> Next: should ALL the currently ignored characters be translatable?
> I.e., by default they would be "seen" by troff, but have null effect;
> however, if translated by ".tr", or defined by ".char", or present at
> the appropriate numbered position in the device font files, they could
> be assigned to a graphic? I could be in favour of this option.

Fair enough, although I feel that such use shouldn't exactly be
encouraged. 

> However, I think that the characters not currently ignored
> (STX [0x02], ETX [0x03], ENQ [0x05], ACK [0x06] and BEL [0x07])
> should retain their current status (i.e. usable as delimiters
> -- "tbl" uses them, for instanace, and I think that "refer"
> may do so as well -- or translatable), to avoid breaking
> software which depends on this status.

See above.

> In any case, I'm definitely in favour of ALL input in the range
> 0x80-0x9F being available to troff, on the same basis as just
> described

See above, too.

Egil
-- 
Email: address@hidden  Voice: +47 22523641, 92022780 Fax: +47 22525899
Mail:  Egil Kvaleberg, Husebybakken 14A, 0379 Oslo, Norway
Home:  http://www.kvaleberg.com/