Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!emory!dtscp1!scott
From: scott@dtscp1.UUCP (Scott Barman)
Newsgroups: comp.text
Subject: Re: What features would you like in GNU troff?
Message-ID: <742@dtscp1.UUCP>
Date: 2 Jun 89 16:48:44 GMT
References: <JJC.89May31220314@jclark.UUCP>
Reply-To: scott@dtscp1.UUCP (Scott Barman)
Distribution: comp
Organization: Digital Transmission Systems (a subsidiary of DCA), Duluth, GA
Lines: 91

In article <JJC.89May31220314@jclark.UUCP> jjc@jclark.UUCP (James Clark) writes:
>I have been implementing a troff which I'm going to give to GNU, and I
>would like to get some input on what features people would like to see
>in it.
Does this mean it will be 20 times bigger than the original? :-)

>I would welcome suggestions both for completely new features and for
>extensions or improvements to existing features. If there are any
>obscure, undocumented features of the original troff that aren't used
>by standard macro packages and that you think should be preserved, I
>would like to hear about them; since I've never seen the source, I may
>not know about such features.  I would also be interested to learn
>about extensions implemented in other troffs (particularly the current
>Bell Labs version).
If you get a copy of the Ossanna manual and the Tech Report about the
device independent version, you will find most of the information there.
However, the following would be nice:

	1) Better handling of graphics.  I want to be able to include
a bitmap anywhere in the output, give it is size in pixels (units) and
it leave space.  Now, the only way to do it is to use the transparent
character to put a devcntl line in the output, then force spacing--which
sometimes is difficult to do.  Another way is the unpredictable .cf...
	2) Enhanced drawing functions.  I would like to see filling of
objects and a selectable grey scale (or even color).  Also, line widths
would be nice.
	3) This is something I would like to see fixed:  When emboldening
a font (say .bd S 3), if you turn off emboldening before the end of a
line, then the output will not be emboldened.  It will not embolden a
partial line.  It will also not embolden a line that was to be emboldened
when reading it from a diversion unless emboldening is turned on.  I
cannot tell you how I fought this once and I have to say that this is
one "feature" I really would like to see changed.
	This happens because of when the emboldening is interpreted.
It should be interpreted with the character and not on output (as done
now).
	4) Allow for devices whose resolution are very big.  A while ago,
I was working for a company that was using a VideoComp 500 phototypesetter.
The resolution on that beast was 3600 dpi (I think... either way it was
big).  Since the "magic cookie" (the definition of the character) used
sixteen bit signed notation, once you tried to go beyond 32767 units,
you sent ditroff "off into the weeds."  I found a way of resolving this
(both my software and VideoComp software), but it was real annoying.
	5) How about a dynamically allocated hyphenation list.  When
one does technical journals, it is not unusual to have words that do
not follow the "standard" hyphenation rules built into troff.  So at
a previous job, we kept having to up the table size (yes, it was a
compiled in value) because the list grew to bit for internal limitis
(we had a file with .hw commands that got included at the front of every
paper).
	6) Better definitions of character sets.  On some phototypesetters,
the height and depth of a character is different and it is information
needed when doing kerning (sometimes better than just knowing if there
was an ascender of descender).  Then there should be a command to allow
this info to be used (like \K'[ad]x' to get kerning info where [ad] is
for ascender or descender).
	Another thing is what I've been calling font forwarding.  Some
typesetters do not put all their characters on one physical font.  They
have what they call font families.  On these typesetters, changing to 
a different font family is the same as a font change.  The change of
family should be noted in the definition so we do not have to create
many special files just so we can print a character that should be
in (say) the Roman font.
	7) If you get around to tbl, how about an option that will
allow it to do the \D line drawing function instead of the \l.  I
made this hack into tbl once before, but I don't have a copy of
it now and I just couldn't distribute it because it was full of
AT&T code (because I just hacked tbl and not rewrote it).

>So far it has almost all V7 troff features, as well as most ditroff
>features and obvious extensions such as long names. I am trying to
>make it sufficiently compatible that tbl, eqn and pic will work with
>it unchanged and standard macro packages will work with at most a few,
>simple changes.  It can produce both TeX .dvi and PostScript output,
>and uses TeX .tfm font metric files. It's written in C++. It's still
>quite a long way from being ready for release.
It should work with NO changes to macro packages!!  The beauty of
the old troff->ditroff->DWB troff path has been that everything that
I did under the old troff still works now!  If you are not careful,
requiring simple changes to macro packages can make it non-compatible
with eqn, tbl, and pic (you have to remember pic here).

Also, it should produce the ASCII form ditroff has output up until DWB.
I do not care for what some software companies have done since their
versions are now incompatible with my drivers which are written with
special hacks for special purposes... I do not want to have to go
back and change them.

-- 
scott barman
{gatech, emory}!dtscp1!scott