jjc@jclark.UUCP (James Clark) (06/01/89)
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. 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). 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. Post if you feel it appropriate, but in any case please email me as some news seems to get lost on its way here. James Clark jjc@jclark.uucp
rick@pcrat.UUCP (Rick Richardson) (06/02/89)
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 > >So far it has almost all V7 troff features, as well as most ditroff >It can produce both TeX .dvi and PostScript output, Remember that it isn't ditroff compatible unless it supports at least the basic ditroff intermediate format. SQ made this mistake, and I hope GNU doesn't, too. The intermediate format is used by indexers and postprocessors, is documented, and should be supported. -- Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2 PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2 uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms. jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp
av@utacs.UTA.FI (Arto Viitanen) (06/02/89)
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. Following is a caption from GNU Emacs' info section called "The GNU Manifesto" We will use TeX as our text formatter, but an nroff is being worked on. So what is the point to work on troff, when GNU will use TeX (for example all the manuals are in TeXinfo format) ?
mende@athos.rutgers.edu (Bob Mende Pie) (06/02/89)
In article <712@utacs.UTA.FI> av@utacs.UTA.FI (Arto Viitanen) writes: > So what is the point to work on troff, when GNU will use TeX (for example > all the manuals are in TeXinfo format) ? One of the things that the GBU project is trying to do is make a Unix compatable OS and enviorment. One of the standard utilities of Unix is *roff programs. The standard manual pages are designed for nroff. It would be nice if gnu had this standard utility. Also, (La)TeX is great when you have a good display device, but loses on a dumb tty. /Bob... --
scott@dtscp1.UUCP (Scott Barman) (06/02/89)
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
budd@mist.CS.ORST.EDU (Tim Budd) (06/03/89)
A few months ago I taught a two day course on troff. While reviewing all the various dark corners of the system that I had forgotten about in preparation for that course, it occurred to me that a large percentage of troff commands basically just set various internal values. I pondered at the time whether if one made more internal registers user accessible, one could define *macros* for most of these commands. Something like .sp, for example, would just issue a .br (if not given as a 'sp command, so the first char of the command would have to be accessible to the macro), followed by an increment of the ``space to put out before next text'' value. I think this could be done, and I think this would result in the troff system itself being relatively small, but having a relatively large macro package to come with it. There were only a dozen or so commands that I could think of that couldn't be rewritten as calls on simplier functions, given some additional assumptions (like accessibility of registers, ability to get first character of command line, ability to do better argument string processing, and so on). I didn't pursue this since I have far to many black holes sucking my time as it is, but if somebody is actually rewriting troff they might want to give this some consideration. --tim budd, budd@cs.orst.edu
quiroz@cs.rochester.edu (Cesar Quiroz) (06/03/89)
Please remove as many of the arbitrary restrictions no doubt imposed
by the small memories of the machines troff grew on. No limits on
name lengths (check the syntax of the extensions that already exist
and pick up one that goes well with the rest of your work), no
limits on numbers of environments, of macros, of words in the
hyphenation list, etc... Actually, some sense of `scope' to produce
and promptly discard temporary names may help a little.
Good luck!
--
Cesar Augusto Quiroz Gonzalez
Department of Computer Science
University of Rochester
Rochester, NY 14627gm@romeo.cs.duke.edu (Greg McGary) (06/03/89)
In article <Jun.2.10.31.56.1989.20492@athos.rutgers.edu> mende@athos.rutgers.edu (Bob Mende Pie) writes: >In article <712@utacs.UTA.FI> av@utacs.UTA.FI (Arto Viitanen) writes: >> So what is the point to work on troff, when GNU will use TeX (for example >> all the manuals are in TeXinfo format) ? > ... Also, (La)TeX is great when you have a good display device, > but loses on a dumb tty. There is no inherent reason why (La)TeX should lose on a tty. TeX is nothing more than a `mason' that stacks boxes horizontally and vertically like bricks. The sizes of those bricks are defined in the TFM font-files, and the `mortar' (glue) between them is controlled by a hand-full of parameters. Normally the glue is stretchy, but by twiddling a few parameters to make the glue rigid and fixed-sized, and using a fixed-width TFM font-metric, TeX will stack boxes neatly into fixed-width character cells. Mind you, TeX does this fixed-width stuff wonderfully if the right-margin is ragged--I can't think of a way to get TeX to distribute extra spaces in discrete chunks between some of the words in a line... though it may be possible to pull each line apart after its been set and distribute the spaces explicitly via some macro-code. Any gurus care to enlighten us about this? After TeX has done its part, its now a matter of having a DVI driver that will spit out plain ascii text. I know of two such free-ware drivers: dvi2tty and dvidoc. These are not entirely suitable though, since their primary reason for existing is to provide fast and dirty previewing on ttys, not necissarily high-quality plain-text output. It would be nice if these drivers would be enhanced to provide some minimum level of font-simulation like nroff, producing `_<backspace>x' to make an underlined (italic) `x', and `x<backspace>x<backspace>x' to produced an overstriked (bold) `x'. You would simply copy the fixed-width TFM file to several different names so that the DVI file would contain font-changes telling the driver when to employ these strategies. I think that TeX is not often perceived as capable of producing good quality `dumb' output is because the ubiquity of low-cost laser printers minimzes demand for it, and because Plain TeX and LaTeX don't have macros built-in that conveniently switch to such a mode--you have to roll your own or use the macros that come with dvi2tty or dvidoc (and even these were buggy and incomplete last I looked). -- Greg McGary -- 10310 Main Street #354, Fairfax, Virginia 22030 voice: (703) 266-7249 -- {decvax,hplabs,seismo,mcnc}!duke!gm data: (703) 266-7258 -- gm@cs.duke.edu
rick@pcrat.UUCP (Rick Richardson) (06/03/89)
In article <742@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: > 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... Absolutely. Using macros can get text to swim around bitmaps to the left or right. But I haven't figured out a way to make text swim between arbitrary bitmaps placed anywhere in the output using just macros. Troff has to be taught this. > 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. Actually, you can already do this with ditroff, if your postprocessor is up to it. Troff doesn't give a hoot what is inside the \D'x n n ...' sequence. It just gets passed on to the postprocessor (except that all numbers have been converted to typesetter units). The soon to be released JetRoff version 2.6 has several enhanced drawing functions, including filled objects. Of course, a standard naming convention would be useful. Also, line widths should be variable with your postprocessor already. At a minimum, the current point size should be controlling the line width. > 6) Better definitions of character sets. On some phototypesetters, >the height and depth of a character is different and it is information No doubt. And don't forget (how could you with the CM fonts) that troff needs to be taught about non-linear scaling of fonts. -- Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2 PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2 uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms. jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp
dan@rna.UUCP (Dan Ts'o) (06/05/89)
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. >So far it has almost all V7 troff features, as well as most ditroff >features and obvious extensions such as long names. My understanding is fuzzy on this point, but I believe that TROFF has real problems dealing with widows and orphans. Either the one line that overflows onto the last page, or the one word that overflows onto the last line of a paragraph. It would be nice (but I know hard) to deal somehow with this. Can TROFF currently flow text around both sides of a display ? I implemented a NROFF-like program for "typesetting" BRAILLE (also does ASCII, source compatible with NROFF/TROFF). For long names, I used \{nameofanylength}. Of course macros can be of any length, and builtin commands also had more friendly aliases, like .space and .break and .page can be used for .sp, .br and .bp. There were some commands missing from TROFF that were need for BRAILLE production, like some way of putting a header string at the end of the first line of every page: This is a line of text from the user file 345 which did not contain the 345. That number was the page number. For this function, I implemented a .ri command (right indent) which takes two arguments, the amount to indent the next line at the right, and an optional string to stick in that spot. Good luck. Cheers, Dan Ts'o 212-570-7671 Dept. Neurobiology dan@rna.rockefeller.edu Rockefeller Univ. ...cmcl2!rna!dan 1230 York Ave. rna!dan@nyu.edu NY, NY 10021 tso@rockefeller.arpa tso@rockvax.bitnet
pcg@aber-cs.UUCP (Piercarlo Grandi) (06/05/89)
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.
Wow! great! I have been waiting for this to happen!
I would welcome suggestions both for completely new features and for
extensions or improvements to existing features.
If you can, the single most important feature would a way to preserve
and restore the stateof the troff, something like "undump/unexec" support.
This would be better than "compiled" macro packages ala SystemII/V troff.
It can produce both TeX .dvi and PostScript output, and uses TeX .tfm
font metric files.
Please, oh please get out ditroff's di format instead of PostScript. There
is no reason to output PostScript directly, but ditroff's di format is so
much better than dvi (two reasons: simpler structure, user specified resolution
and deltas). Also, ditroff devXXXX/YYYY.out as well as tfm...
I also hope that just like ditroff, you can specify the output printer
resolution in both X and Y, and that the formatter computes all motions
etc... as multiples of those resolutions. This makes output quality of low
resolution printers very much better than with tex/dvi, and easier.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukpcg@aber-cs.UUCP (Piercarlo Grandi) (06/05/89)
In article <14622@duke.cs.duke.edu> gm@romeo.UUCP (Greg McGary) writes:
There is no inherent reason why (La)TeX should lose on a tty. TeX
is nothing more than a `mason' that stacks boxes horizontally and
vertically like bricks. The sizes of those bricks are defined in
the TFM font-files, and the `mortar' (glue) between them is controlled
by a hand-full of parameters. Normally the glue is stretchy, but
by twiddling a few parameters to make the glue rigid and fixed-sized,
and using a fixed-width TFM font-metric, TeX will stack boxes neatly
into fixed-width character cells. Mind you, TeX does this fixed-width
stuff wonderfully if the right-margin is ragged--I can't think of a way
to get TeX to distribute extra spaces in discrete chunks between some
of the words in a line...
I have been thinking a while ago on these lines myself. The problem is: can
we tell TeX to strech glue by multiples of a certian delta?
If one has the ability to tell TeX to compute all motions etc... as even
multiples of some delta (in both directions preferably), like ditroff does,
then adapting to low resolution devices is easy.
The ideal would be to be able to have motions in TeX expressed, even in the
dvi file, in multiple of 1/Mth and 1/Nth, where M and N are the resolutions
of the device. Notice that this does not lose device independency; on a
device with different resolutions you just scale everything. It has the
advantage that you need not scale on the intended output device.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uktbray@watsol.waterloo.edu (Tim Bray) (06/08/89)
Apologies for cluttering net-bandwidth; couldn't get mail through. A tiny weeny nit, but: In various troffs, including ditroff, you can't .ss or even 'ss in the middle of an output line and have it take effect right there. (Bet a substantial proportion of (even moderately serious) troff hacks don't know what .ss does). This behaviour is not documented as far as I know, so it should be documented or fixed.
lee@anduk.co.uk (Liam R. Quin) (06/09/89)
In article <10959@orstcs.CS.ORST.EDU> budd@mist.CS.ORST.EDU (Tim Budd) writes: > [...] it occurred to me that > a large percentage of troff commands basically just set various internal > values. I pondered at the time whether if one made more internal registers > user accessible, one could define *macros* for most of these commands. Yes, you could do this. But you would have to dramatically improve troff's efficiency! Also, if you made some of the read-only number registers writeable, .ps 12 becomes .nr .s 12 .ll 21c-2i becomes .nr .l 21c-2i and so on. But what you gain in elegance you lose in portability. Judging by the number of flames resulting from the long names in the troff examples I posted recently, this is important to a lot of people. [but maybe burnt fingers are not a good guide :-) ]. > Something like .sp, for example, would just issue a .br (if not given > as a 'sp command, so the first char of the command would have to be > accessible to the macro), followed by an increment of the ``space to put > out before next text'' value. I think this could be done, and I think It might be the other way round -- .de br \\*[.control-char] sp 0 .. for example. The semantics of .br, .sp and .bp interact in a very complex way with page traps, though, and the above definition is *not* exactly correct. You would need to check \\n(.t first. This is because .sp is allowed to move a non-integral amount of baselines whereas .br (I think) isn't. > [...] > There were only a dozen or so commands that I could think of that couldn't > be rewritten as calls on simplier functions, given some additional > assumptions (like accessibility of registers, ability to get first > character of command line, ability to do better argument string > processing, and so on). Ideally, one should be able to get at the entire state of the C/A/T simulator (or device simulator, for ditroff). This would include tab stops, trtab[] (the list of characters to be transliterated on output via the .tr request), traps (you can't determine an exact list, and ordering of traps is not completely deterministic), and so on. > --tim budd, budd@cs.orst.edu Also, on a related topic: > From: rick@pcrat.UUCP (Rick Richardson) > Message-ID: <777@pcrat.UUCP> > > In article <742@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: > > 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. > Absolutely. Using macros can get text to swim around bitmaps to the > left or right. But I haven't figured out a way to make text swim > between arbitrary bitmaps placed anywhere in the output using just > macros. Troff has to be taught this. This is in fact possible, although a little tricky. One way to do it is to implement `software traps' or call-out lists, which are like traps but allow arguments. You can implement these as macros. Then you can implement linked lists, and you can use use the call-outs to scan the lists for boxes. There are several difficulties, mainly to do with troff bugs: * there is no easy way to do a .br without leaving the word spacing at its minimum allowed value, because troff doesn't have a "desired" word spacing * altering the line length and indent without causing a break can have very interesting effects in some versions of troff, because it may already have gone beyond the (new) margin! * you run out of names for things in non-long-name versions (but it'd be unfair to describe this as a bug!) * it generally all fails if you alter the vertical baseline spacing with the .vs request. You can ameliorate this by renaming vs, though, but at the expense of considerable complexity. Mail me if you want more details, although I don't have macros that do this for ditroff/troff/otroff. In any event, you still have fun including the bitmap, especially if your troff doesn't support \B'bitmap xsize ysize' or something similar. > Troff doesn't give a hoot what is inside the \D'x n n ...' > sequence. It just gets passed on to the postprocessor (except that > all numbers have been converted to typesetter units). The versions of ditroff I have seen do in fact care. They will generally pass through other strings, although they may convert them to D x word, where word is not easily predictable. But there is a compiled-in limit to the number of numbers you can supply. I seem to recall it was 50 pairs. Yes, pairs; they are interpreted as x and y respectively, with all that that implies, and if there is an odd number of numbers you may get a trailing zero too (I forget). > > 6) Better definitions of character sets. On some phototypesetters, > >the height and depth of a character is different and it is information > > No doubt. And don't forget (how could you with the CM fonts) that > troff needs to be taught about non-linear scaling of fonts. > Rick Richardson uunet!pcrat!dry2 Many people have done this (e.g. for the rare and elusive `imagen' printers). Eqn would work a lot better if it knew about heights of things. As it is, it has several heights compiled in for the C/A/T and the Aps 5. Dynamic fonts -- where `glyphs' are constructed from arbitrary strings as well as post-processor commands and actual device glyphs -- are not, I suspect, impossible to add to ditroff as it stands. Some simple changes, like making the -F fontdir option into a colon- delimited Font:file:path, makes testing easier and gives people a lot more flexibility at relatively little expense. (This change is good if you have added font-family of style-sheet files). For that matter, better error messages can help even more! I have mailed some suggestions to the author of the original article. They do *not* include a lisp interface to troff :-) :-) Lee -- Lee Russell Quin, Unixsys UK Ltd, The Genesis Centre, Birchwood, Warrington, ENGLAND, WA3 7BH; Tel. +44 925 828181, Fax +44 925 827834 lee%anduk.uucp@ai.toronto.edu; {utzoo,uunet}!utai!anduk!lee UK: uu.warwick.ac.uk!anduk.co.uk!lee
lee@anduk.co.uk (Liam R. Quin) (06/09/89)
In article <622@rna.UUCP> dan@rna.UUCP (Dan Ts'o) writes: >In article <JJC.89May31220314@jclark.UUCP> jjc@jclark (James Clark) writes: > I implemented a NROFF-like program for "typesetting" BRAILLE (also >does ASCII, source compatible with NROFF/TROFF). For long names, I used >\{nameofanylength}. Of course macros can be of any length, and builtin >commands also had more friendly aliases, like .space and .break and .page >can be used for .sp, .br and .bp. The only trouble with this is that you can't have long special symbols like \{pound-sterling} or \{dagger}, because \{ already means the "then" of an if-then-else, and is legal in generally the same places. Either \[name] or \<name> are better. I prefer \[...], because then I can use existing bracket-matching software (e.g. the % key in vi) to check things like \\*[array.\\n[index]]. Also, it is useful if all the escape sequences that recognise delimiters understand [...] (or whatever) as well. Currently, ditroff does not check that the two delimiters are the same in all cases, so \l[3i] happens to work, at any rate in the version I have here, but this is too easy to do by mistake. \h[\w[\\*[array.\\n[index]]u]u] is not much better then \h'\w'\\*'array.\\n'index]'u'u' and less robust than otroff's \h'\w\:\*(A\\n(Ix\:u'u' (\: was an undocumented delimiter) but at least yuo can check it automatically, anda combination *is* more readable: \h[\w'\\*[array.\\n[index]]u'u] looks best to me. > There were some commands missing from TROFF that were need for >BRAILLE production, like some way of putting a header string at the end >of the first line of every page: You migt be able to do this with a macro: * put the string in place at the top right * reduce the line length so the text doesn't overwrite it * make a trap for one line down * In the trap, * increase the line length * remove the trap But it isn't easy to get right first time... Lee -- Lee Russell Quin, Unixsys UK Ltd, The Genesis Centre, Birchwood, Warrington, ENGLAND, WA3 7BH; Tel. +44 925 828181, Fax +44 925 827834 lee%anduk.uucp@ai.toronto.edu; {utzoo,uunet}!utai!anduk!lee UK: uu.warwick.ac.uk!anduk.co.uk!lee
scott@dtscp1.UUCP (Scott Barman) (06/10/89)
In article <14365@watdragon.waterloo.edu> tbray@watsol.waterloo.edu (Tim Bray) writes: >Apologies for cluttering net-bandwidth; couldn't get mail through. > >A tiny weeny nit, but: In various troffs, including ditroff, you can't >.ss >or even >'ss >in the middle of an output line and have it take effect right there. (Bet >a substantial proportion of (even moderately serious) troff hacks don't >know what .ss does). Without looking at the manual (since I left it a home :-): .ss == set space character size where the value is entered is something like N/36 ems (or is it ens?). >This behaviour is not documented as far as I know, so it should be >documented or fixed. The reason is simple why this does not work. It is were this is interpreted. Like the .bd, the .ss is interpreted on output. I do not know the reasoning, but (as I try to remember since it has been 4 years since I hacked at troff) this number is not stored in the "magic cookie" of each character and needs to be in effect when troff tries to properly adjust the margins. It is also the same for emboldening since the widths of the characters change and it needs to know this information on output. The short of it is because it is interpreted on output and not input. Oh, and in a backward sort of way, it is... unfortunatly it assumes that the reader knows about troff internals. It is tied in with the same reasons that .bd and .cs (do *you* know what that one is) have to be in effect when you reread a diversion... because they are interpreted on output, not input. See the info on diversions (like I said, my manual is not handy). NOTE I have mentioned it once before and before I get alot of mail asking what the "magic cookie" is: it is what the internal representation of a character is in troff (I do not remember if it is the same in C/A/T troff since it has been even longer since I pulled the lid off of that beastie). In ditroff, it is a 32-bit quantity that contains size, character, font, motion, etc. informtion that is also context based (i.e. a charcter does not have spacing info, but does have width info (16-bits)). Any attempts at reimplementation should concentrate on making this "magic cookie" more flexible--or at least give us more than 16-bits to figure movement. -- scott barman {gatech, emory}!dtscp1!scott
dan@rna.UUCP (Dan Ts'o) (06/10/89)
In article <22@nx32s.anduk.co.uk> lee@nx32s.UUCP (0000-Liam R. Quin) writes: )In article <622@rna.UUCP> dan@rna.UUCP (Dan Ts'o) writes: ))In article <JJC.89May31220314@jclark.UUCP> jjc@jclark (James Clark) writes: )) I implemented a NROFF-like program for "typesetting" BRAILLE (also ))does ASCII, source compatible with NROFF/TROFF). For long names, I used ))\{nameofanylength}. Of course macros can be of any length, and builtin ))commands also had more friendly aliases, like .space and .break and .page ))can be used for .sp, .br and .bp. )The only trouble with this is that you can't have long special )symbols like \{pound-sterling} or \{dagger}, because \{ already means )the "then" of an if-then-else, and is legal in generally the same places. Sorry, I typed that in wrong. Its \*{long-string-name} for strings, and \n{long-number-register-name} for number registers. Macros, of course, can also have long names.
rick@pcrat.UUCP (Rick Richardson) (06/10/89)
In article <21@nx32s.anduk.co.uk> lee@nx32s.UUCP (0000-Liam R. Quin) writes: >> From: rick@pcrat.UUCP (Rick Richardson) {Me} >> Absolutely. Using macros can get text to swim around bitmaps to the >> left or right. But I haven't figured out a way to make text swim >> between arbitrary bitmaps placed anywhere in the output using just >> macros. Troff has to be taught this. > One way to do it is to implement `software traps' or call-out lists, > which are like traps but allow arguments. You can implement these as > macros. > Then you can implement linked lists, and you can use use the call-outs to > scan the lists for boxes. > In any event, you still have fun including the bitmap, especially if > your troff doesn't support \B'bitmap xsize ysize' or something similar. I don't think this works. I want to be able to tell troff that there are "holes" in the paper, and to skip the "holes" when justifying text: This is a test of a hole ******** in the page ******** being skipped magically. I don't think you can do this with just macros. You'd need a horizontal trap. Also, it isn't any great trick to do the actual include of bitmaps. Troff doesn't need to be taught this; it can all be done via macros. JetRoff does this via a ".BM" macro, whose basic arguments are: .BM bitmap_file_name file_type placement e.g.: .BM picture.pcx pcx RJ .BM signature.pcx pcx L Includes picture.pcx right justified (text swims left around the picture), and includes signature at the left margin (text skips past the bitmap). The macro takes care of determining the size of the bitmap and arranging for troff skip by or around the bitmap. This works fine for virgin AT&T troff. -- Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2 PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2 uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms. jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp
scott@dtscp1.UUCP (Scott Barman) (06/10/89)
In article <21@nx32s.anduk.co.uk> lee@nx32s.UUCP (0000-Liam R. Quin) writes: > [... much deleted about using registers to control troff ...] This seems interesting, but I am not convinces that upward compatibility would be preserved. If you are going to design something and call it a troff replacement, I would hope it is upward compatible. >There are several difficulties, mainly to do with troff bugs: >* there is no easy way to do a .br without leaving the word spacing at > its minimum allowed value, because troff doesn't have a "desired" word > spacing Then where does the .ss fit in. I think it will do what you want! >* you run out of names for things in non-long-name versions > (but it'd be unfair to describe this as a bug!) Let's see... names can be anything consisting of any of the 94 printable ASCII characters (no backslash or space), and they can be two characters, so if I remember my high school math correctly, there are 94^2 (or 8,836) possibilities (less builtin names). So for around 8700 possibilities, I think there are no problems! >* it generally all fails if you alter the vertical baseline spacing with > the .vs request. You can ameliorate this by renaming vs, though, but at > the expense of considerable complexity. If you change it in the middle of a line, it will do some interesting things since (I cannot remember and I do not have my docs at hand) it will not break the line. To change the .vs, make sure it is done at the beginning of the line... not difficult to do in most cases. >> > 6) Better definitions of character sets. On some phototypesetters, >> >the height and depth of a character is different and it is information >> >> No doubt. And don't forget (how could you with the CM fonts) that >> troff needs to be taught about non-linear scaling of fonts. > >> Rick Richardson uunet!pcrat!dry2 > >Many people have done this (e.g. for the rare and elusive `imagen' printers). I posted the original suggestion, and I did it for a III VideoComp 500 typesetter (a beast base on the 18-bit PDP 15!). >Eqn would work a lot better if it knew about heights of things. AMEN! >As it is, it has several heights compiled in for the C/A/T and the Aps 5. In ditroff, there are no heights compiled in--only assumptions based on ascenders and descenders. I have seen special cases in pic and eqn, but not in ditroff. >Dynamic fonts -- where `glyphs' are constructed from arbitrary strings as >well as post-processor commands and actual device glyphs -- are not, >I suspect, impossible to add to ditroff as it stands. This is assuming the output supports "glyphs". The VC500 used what it called "stroking data" (the vertical tracing of a character) and is very complicated to put together. I am hoping newer troffs move twoards more device independence. >For that matter, better error messages can help even more! Error messages? Do you mean a "?" is not good enough?!! :-) :-) -- scott barman {gatech, emory}!dtscp1!scott
scott@dtscp1.UUCP (Scott Barman) (06/10/89)
In article <22@nx32s.anduk.co.uk> lee@nx32s.UUCP (0000-Liam R. Quin) writes: >The only trouble with this is that you can't have long special >symbols like \{pound-sterling} or \{dagger}, because \{ already means >the "then" of an if-then-else, and is legal in generally the same places. > >Either \[name] or \<name> are better. I prefer \[...], because then I >can use existing bracket-matching software (e.g. the % key in vi) to check >things like \\*[array.\\n[index]]. The problem with this is with the older versions of troff it will interpret the string named "[" then append "array" to it and the number register of "[" then "index]]" appended. Once you do this, you have to sit and re-edit many megabytes of documentation already in existance. This is not fair to those of us who has been doing this for a few years! Didn't Berkeley do something like this for long names? I think they took great pains in keeping the compatibility! Their method was to use the space as the delimeter. For example, to use the number register named "saved", one would do: Part of a sentence then \n( saved and the rest... ^^ Note 2 spaces The extra space is needed for the delimeter. As I recall from their docs, they said that the extra space is required and is the cost for using this feature. I do not see anything wrong with this since the space is not a legal for use in nameing registers, etc. AND IT DOES NOT BREAK ALL THE OLD DOCUMENTS! PLEASE STOP TRYING TO BREAK OUR *MEGABYTES* OF DOCUMENTATION!!! I mean manuals, functional and design documents are painful enough. We do not want to have to re-edit them if it can be avoided! *AND* we (read: me, the part-time sys admin., full time programmer) do not want to maintain N versions of troff! I did it once and it was not fun or easy! -- scott barman {gatech, emory}!dtscp1!scott
lee@anduk.co.uk (Liam R. Quin) (06/12/89)
In article <763@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: >In article <22@nx32s.anduk.co.uk> lee@nx32s.UUCP (Liam R. Quin) writes: >>I prefer "\[...]", (e.g. for things like \\*[array.\\n[index]]). >The problem with this is with the older versions of troff it will interpret >the string named "[" then append "array" to it and the number register >of "[" then "index]]" appended. Obviously this happens if you use \n{ as well. The difference is that \[ is not already wired into troff, and is therefore useable for extensions; this isn't true for \{. But if you use the old versions of troff, you are not likely to use the new extensions. >Once you do this, you have to sit and >re-edit many megabytes of documentation already in existance. Only if it uses \[ in the input (which wouldn't have done anything!), or if you have used a string or number register called [, and you don't have a "disable long names" command-line option. Even then, it is a very, very easy sed-script to turn \*[ into \*[[] everywhere. Remember that your old documents do not use long names, because troff didn't have them at your site when you wrote them. No-one is suggesting that you be forced to discard or edit megabytes of documentation. >This is >not fair to those of us who has [sic] been doing this for a few years! Doing what? Sorry, not following you here. >Didn't Berkeley do something like this for long names? I think they took >great pains in keeping the compatibility! Yes... >Their method was to use the >space as the delimeter. Not that I am aware of. In article <252@ucbopal.CC.Berkeley.ARPA> (Edward Moy) wrote (on the 3rd Jul 1985), that they used square brackets, as in \*[string]: Strings, number registers and fonts of any length name may be called with \*[x..x], \n[x..x] and \f[x..x], respectively. Special characters may also be called with \[x..x]. The format of a number register may be accessed with \g[x..x], and the current input-line horizontal position may be recorded in register x..x with \k[x..x]. Size changes of any number of digits may be called with `s[x..x]. This only happened if you set the EXPANDED environmant variable, or if you used -x on the command line. If there was another version of ditroff which used spaces, I don't know of it (and would like to know more). But it sounds like it would have been a pain! >[...] AND IT DOES NOT BREAK ALL >THE OLD DOCUMENTS! Neither do \{ \[, \<, \C'...' or any of the other schemes. Perhaps you are being a trifle alarmist? At most these break a very few documents, and a few macro packages (not, for example, -mm in either case) need very slight editing. >PLEASE STOP TRYING TO BREAK OUR *MEGABYTES* OF DOCUMENTATION!!! No-one is doing this. You can stop shouting now [0.5 :-)]. If you still need convincing, though, send me some mail! >*AND* we (read: me, >the part-time sys admin., full time programmer) do not want to maintain >N versions of troff! I did it once and it was not fun or easy! No-one seems to be about to force you to use GNU troff. If you prefer to walk, walk. We'll take the `plane. [:-) :-) :-)] lee -- Lee Russell Quin, Unixsys UK Ltd, The Genesis Centre, Birchwood, Warrington, ENGLAND, WA3 7BH; Tel. +44 925 828181, Fax +44 925 827834 lee%anduk.uucp@ai.toronto.edu; {utzoo,uunet}!utai!anduk!lee UK: uu.warwick.ac.uk!anduk.co.uk!lee
lee@anduk.co.uk (Liam R. Quin) (06/12/89)
In article <762@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: >In article <21@nx32s.anduk.co.uk> lee@nx32s.UUCP (0000-Liam R. Quin) writes: >> [... much deleted about using registers to control troff ...] >This seems interesting, but I am not convinces that upward compatibility >would be preserved. If you are going to design something and call it >a troff replacement, I would hope it is upward compatible. I pointed out this difficulty in my article. It was really just a point of interest (as you remarked). >>There are several difficulties, mainly to do with troff bugs: >>* there is no easy way to do a .br without leaving the word spacing at >> its minimum allowed value, because troff doesn't have a "desired" word >> spacing >Then where does the .ss fit in. I think it will do what you want! Uh, I said `no easy way'. By which I exclude writing a macro which puts the single last line of a paragraph into a diversion, measures its length, sets the space size according to whether it would fit with the `optimum' value, outputs the line with the new space size, and then restores the space size. It is *possible*, but not *easy*. And none of the main macro packages do it. > >>* you run out of names for things in non-long-name versions >> (but it'd be unfair to describe this as a bug!) >Let's see... names can be anything consisting of any of the 94 printable >ASCII characters (no backslash or space), and they can be two characters, >so if I remember my high school math correctly, there are 94^2 (or 8,836) >possibilities (less builtin names). So for around 8700 possibilities, >I think there are no problems! Most versions of troff that do not have long names have an upper limit of around 500 names that can be defined at any one time in each of the two available name-spaces (numbers and strings/macros/requests). The later versions of -mm actually run out altogether with otroff. So yes, there is a problem. Also, your high-school arithmetic (whatever that may be) is flawed, because ( and . are not possible in the first character of a name, and nearly 100 names are pre-defined. On the other hand, some control characters are allowed.... >>* it generally all fails if you alter the vertical baseline spacing with >> the .vs request. You can ameliorate this by renaming vs, though, but at >> the expense of considerable complexity. >If you change it in the middle of a line, it will do some interesting things >since (I cannot remember and I do not have my docs at hand) it will not >break the line. To change the .vs, make sure it is done at the beginning >of the line... not difficult to do in most cases. ??? You can change .vs anywhere along the line; it will affect where the current line is printed. Go and get your doctors! The strategy that failed, however, was one that needed to know the vertical position at the start of each line; it could get confused if this wasn't as expected. As noted, this can be surmounted, but it generally isn't worth the effort! >>Eqn would work a lot better if it knew about heights of things. >AMEN! >>As it is, it has several heights compiled in for the C/A/T and the Aps 5. >In ditroff, there are no heights compiled in--only assumptions based on >ascenders and descenders. I have seen special cases in pic and eqn, but >not in ditroff. It was eqn that was being discussed, not ditroff. Eqn knows (for example) the height of a SIGMA in the special font. >>Dynamic fonts -- where `glyphs' are constructed from arbitrary strings as >>well as post-processor commands and actual device glyphs -- are not, >>I suspect, impossible to add to ditroff as it stands. >This is assuming the output supports "glyphs". The VC500 used what it >called "stroking data" (the vertical tracing of a character) and is very >complicated to put together. I am hoping newer troffs move twoards more >device independence. The idea is not to do with output technology, but with telling troff to treat an entire string as a single character. Consider the implications for .tr, for hyphenation (especially with accents), for overstriking... >>For that matter, better error messages can help even more! >Error messages? Do you mean a "?" is not good enough?!! :-) :-) The car I drive has several indicators on the dashboard. You can't by Kenmobiles in the UK :-) Lee -- Lee Russell Quin, Unixsys UK Ltd, The Genesis Centre, Birchwood, Warrington, ENGLAND, WA3 7BH; Tel. +44 925 828181, Fax +44 925 827834 lee%anduk.uucp@ai.toronto.edu; {utzoo,uunet}!utai!anduk!lee UK: uu.warwick.ac.uk!anduk.co.uk!lee
bb@wjh12.harvard.edu (Brent Byer) (06/14/89)
In article <779@pcrat.UUCP> rick@pcrat.UUCP (Rick Richardson) writes: ... >>> From: rick@pcrat.UUCP (Rick Richardson) >>> Using macros can get text to swim around bitmaps to the >>> left or right. But I haven't figured out a way to make text swim >>> between arbitrary bitmaps placed anywhere in the output using just >>> macros. Keep working at it. It isn't too hard, but it isn't for novices. >>> Troff has to be taught this. No, AT&T troff is perfectly capable of this, *as is*. Maybe, you have to be taught troff. :-) >I want to be able to tell troff that there >are "holes" in the paper, and to skip the "holes" when justifying >text: > This is a test of a > hole ******** in the > page ******** being > skipped magically. > >I don't think you can do this with just macros. You'd need a horizontal >trap. Not true. This can be implemented in less than 40 lines of troff. >Also, it isn't any great trick to do the actual include of bitmaps. > > .BM bitmap_file_name file_type placement > >The macro takes care of determining the size of the bitmap and arranging >for troff skip ... Yes, this is exactly how Textware's Tplus has done it since late 1986. And, given that this is on several of the machines at your work (AT&T HO) location, Rick, I'm pleased that you found the technique enlightening. ( Wouldn't it have been appropriate to give proper credit? ) Brent Byer brent@textware.UUCP or bb@wjh12.harvard.edu Textware Intl. or att!ihesa!textware!brent 12-year old nephew: "Uncle Bill, that steamboat race was the biggest gamble in the world." W.C. Fields: "That was nothing, son. I remember when Lady Godiva put everything she had on a horse."
rick@pcrat.UUCP (Rick Richardson) (06/14/89)
In article <355@wjh12.harvard.edu> bb@wjh12.UUCP (Brent Byer) writes: >In article <779@pcrat.UUCP> rick@pcrat.UUCP (Rick Richardson) writes: >>I want to be able to tell troff that there >>are "holes" in the paper, and to skip the "holes" when justifying >>text: >> This is a test of a >> hole ******** in the >> page ******** being >> skipped magically. >> >>I don't think you can do this with just macros. You'd need a horizontal >>trap. > >Not true. This can be implemented in less than 40 lines of troff. Well, that's a lot of troff. Does it handle the general case, working within *any* macro package? What if there are two holes next to each other? Will a sentence get broken up into three segments across the page? Without seeing your macro to do this, I still stand by my statement that troff itself needs to be modified. I'm sure that lots of people would be interested in this macro, why don't you post it? >>Also, it isn't any great trick to do the actual include of bitmaps. >> >> .BM bitmap_file_name file_type placement > >Yes, this is exactly how Textware's Tplus has done it since late 1986. >And, given that this is on several of the machines at your work (AT&T HO) >location, Rick, I'm pleased that you found the technique enlightening. >( Wouldn't it have been appropriate to give proper credit? ) Brent, I haven't consulted at AT&T for over a year. I never used, nor was I aware of, any bitmap capability in the version of tplus that was available at that site. As far as I know, there is no trademark on the name ".BM" for a macro. I haven't seen yours, and I doubt that mine is the same as yours. Here's mine in case you aren't convinced: '\" '\" .BM filename type resolution justification '\" filename is name of bitmap containing file '\" type is the name of the filter for this type bitmap '\" resolution is 300, 150, 100, or 75 '\" justification is L, R, C, LJ, or RJ '\" .k width of text on current line '\" .d current vertical place '\" .i current indent '\" .o current page offset '\" .l current line length '\" .v current vertical spacing '\" .z current diversion name '\" '\" $Id: tmac.jetroff,v 1.1 88/08/26 23:11:08 rick Exp $ '\" $Log: tmac.jetroff,v $ '\" Revision 1.1 88/08/26 23:11:08 rick '\" Initial revision '\" .nr ## 0 1 .de BM .sy jetroff_bm "\\$1" "\\$2" "\\$3" "\\$4" \\n(.k \\n(.d \\n(.i \\n(.o \ \\n(.l \\n(.v "\\n(.z" >/tmp/jet\\n+(##.\n($$ .so /tmp/jet\\n(##.\n($$ .sy rm /tmp/jet\\n(##.\n($$ .. Yes, all the hairy stuff is computed by a program called jetroff_bm. The source for which is in the comp.sources.misc archives. -- Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2 PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2 uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms. jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp
des@yatton.inmos.co.uk (David Shepherd) (06/14/89)
[[ apologies if this subject has been covered already, but we've got news feed problems and this article has only just arrived ]] In article <14622@inmos.co.uk (Greg McGary) writes: >There is no inherent reason why (La)TeX should lose on a tty. TeX >is nothing more than a `mason' that stacks boxes horizontally and >vertically like bricks. The sizes of those bricks are defined in >the TFM font-files, and the `mortar' (glue) between them is controlled >by a hand-full of parameters. Normally the glue is stretchy, but >by twiddling a few parameters to make the glue rigid and fixed-sized, >and using a fixed-width TFM font-metric, TeX will stack boxes neatly >into fixed-width character cells. Mind you, TeX does this fixed-width >stuff wonderfully if the right-margin is ragged--I can't think of a way >to get TeX to distribute extra spaces in discrete chunks between some >of the words in a line... though it may be possible to pull each line >apart after its been set and distribute the spaces explicitly via some >macro-code. Any gurus care to enlighten us about this? No need to do this. If everything that gets added to the page is in character cell sized chunks then all you do is to get the DVI driver to "round to nearest" character cell. Then you will get justified paragraphs with space distributed, sort of like, TeX intended. >It would be nice if these drivers would be enhanced to provide some >minimum level of font-simulation like nroff, producing `_<backspace>x' >to make an underlined (italic) `x', and `x<backspace>x<backspace>x' to >produced an overstriked (bold) `x'. You would simply copy the >fixed-width TFM file to several different names so that the DVI file >would contain font-changes telling the driver when to employ these >strategies. About 18 months ago when I was trying to get INMOS to take TeX on board as the standard text processor (we *still* use RUNOFF as I failed ;-) one of the objections was that TeX couldn't produce output to daisy wheel printers. After a bit of thought I realised the method I suggest above worked and in about 2 hours of a Saturday afternoon I'd hacked DVITYPE into a DVIDAISY driver, including underline and overstike "fonts". I don't think anyone ever used it, and I don't think I could still find it, but I'd proved my point ;-) david shepherd INMOS ltd
jes@mbio.med.upenn.edu (Joe Smith) (06/16/89)
> Keep working at it. It isn't too hard, but it isn't for novices. > >>> Troff has to be taught this. > No, AT&T troff is perfectly capable of this, *as is*. > Maybe, you have to be taught troff. :-) Having spent a *lot* of time trying to get troff and the standard macro packages to do very normal kinds of things, I find the attitude implied by this very disturbing on several counts, despite the smiley. I think these points are relevant to the GNU troff discussion. First, I need a writing environment that is as efficient as possible. That's why I can't stand the usual WYSIWYG model - I don't like having to wait every time I adjust the page layout. In my experience, troff (actually, otroff, which may be part of the problem), fails in this point because I end up spending too much time fighting the software: trying to write or modify complex, unreadable, undocumented macros. Maybe the one of the best contributions GNU troff could make would be a truly comprehensive reference manual, users manual, and real-world macro package. Then instead of taunting us poor slobs who have to write text, not macros, you can just say: "RTFM!" <Joe -- Joe Smith University of Pennsylvania jes@mbio.med.upenn.edu Dept. of Biochemistry and Biophysics (215) 898-8348 Philadelphia, PA 19104-6059
allbery@ncoast.ORG (Brandon S. Allbery) (06/17/89)
As quoted from <25@nx32s.anduk.co.uk> by lee@anduk.co.uk (Liam R. Quin): +--------------- | Also, your high-school arithmetic (whatever that may be) is flawed, | because ( and . are not possible in the first character of a name, and | nearly 100 names are pre-defined. On the other hand, some control | characters are allowed.... +--------------- Beg pardon, but the only restriction I've found is that ( can not be used as a single-character name; it is possible to define a macro called ".F", for instance, and call it as "..F". I've not found a need to define "." as a macro, but it could be useful e.g. to monitor memory usage as you define macros, since troff will not only stop defining at .., it will execute the macro called "." if it exists; make "." do a ".pm" for a quick memory-usage debug check. (Or ".rn pm .".) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
snoopy@sopwith.UUCP (Snoopy) (06/19/89)
In article <986@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: |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. | | It can produce both TeX .dvi and PostScript output, and uses TeX .tfm | font metric files. | |Please, oh please get out ditroff's di format instead of PostScript. Please, oh please retain the existing PostScript mode. Add di format if you like, but don't drop PostScript. | There is no reason to output PostScript directly, Why not? PostScript is a (mostly) device-independent page description language that is very popular. There is a GNU PostScript interpreter (Ghostscript) which handled the sample of groff output James sent me just fine, modulo font differences (I didn't have the fonts specified and had to substitute Hershey fonts). Groff generates PostScript code which appears to be significently more efficient than that generated by Adobe's psdit. (I haven't done benchmarks, but I think it's a safe guess.) _____ .-----. /_____\ Snoopy ./ RIP \. /_______\ qiclab!sopwith!snoopy | | |___| parsely!sopwith!snoopy | tekecs | |___| sun!nosun!illian!sopwith!snoopy |_________| "I *was* the next man!" -Indy
scott@dtscp1.UUCP (Scott Barman) (06/19/89)
In article <159@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >Diagnostic messages when you do something stupid > >Testing if an object (e.g., macro or string) is defined. >Tracing This brings up something that I wished for before: I think it is possible to do a dbx-like debugger for troff to debug macros (I have a few ideas on how to implement this). Is someone working on this--or have this done? I would be very interested in seeing this! -- scott barman {gatech, emory}!dtscp1!scott
allbery@ncoast.ORG (Brandon S. Allbery) (06/22/89)
As quoted from <159@unmvax.unm.edu> by brainerd@unmvax.unm.edu (Walt Brainerd): +--------------- | A feature we have not implemented, but think desirable is font families, | so that switching to _italic_ means italic of the current font family, | for example. +--------------- I have a macro package for ditroff which does this to some extent; at the moment, it's limited to handling bold and italic independently in Helvetica, but it shouldn't be difficult to adapt it to handle font families as well. The only problem with it is that, since ditroff can't determine fonts dynamically from within itself, it would have to be configured from an outside program. (I will probably use an .sy in the macro package to build the list on the fly from an ASCII font-description file.) It'll take some work to extricate it from the macro package it lives in (an internal current-project-list macro package) and add multiple font capability, but if there's sufficient interest I can post it. Oh, one other feature that I may make optional: if you switch to italic on a semi-permanent basis (e.g. issue .I without arguments), then the meanings of .I and .R with arguments are swapped within that block, e.g. ".I foo" will produce "foo" in the Roman style for the current font. I found it useful to "hide" the fact that comments are in italic while projects are in Roman. (Note that by "Roman" I mean the non-italic, standard stroke weight font style for the current font; that isn't (di)troff usage, but I think it's standard typesetters' usage.) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
iau@ukc.ac.uk (I.A.Utting) (06/22/89)
In article <13768@ncoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes: >As quoted from <159@unmvax.unm.edu> by brainerd@unmvax.unm.edu (Walt Brainerd): >+--------------- >| A feature we have not implemented, but think desirable is font families, >| so that switching to _italic_ means italic of the current font family, >| for example. >+--------------- > >I have a macro package for ditroff which does this to some extent; at the >moment, it's limited to handling bold and italic independently in Helvetica, >but it shouldn't be difficult to adapt it to handle font families as well. >The only problem with it is that, since ditroff can't determine fonts >dynamically from within itself, it would have to be configured from an >outside program. (I will probably use an .sy in the macro package to build >the list on the fly from an ASCII font-description file.) To another extent, this can most easily be done by having different typesetter (-Txxx) variants for each "family". For instance, for PostScript printers, I have -Talw as the default with Times Roman descriptions stored as R, I, B and BI; -TalwH analogously with Helvetica bold described in the R, I etc. files. And so on. Of course, this works transparently with any macro package, and any document which doesn't assume the availability of specific characters in specific fonts. Not really a problem. You'll need to have a back-end (or modify one) so that it selects fonts on the output device based on the internalname field, or via external information giving the new mapping. This is pretty trivially done. The only other problem I've had is marginal worries about how to select between /copyrightserif and /copyrightsans: generally characters in the special font which make assumptions about the form of the body font. Of course, I don't have a /copyrightbookman either. Ian.
brainerd@unmvax.unm.edu (Walt Brainerd) (06/23/89)
In article <3236@gos.ukc.ac.uk>, iau@ukc.ac.uk (I.A.Utting) writes: > >As quoted from <159@unmvax.unm.edu> by brainerd@unmvax.unm.edu (Walt Brainerd): > >| A feature we have not implemented, but think desirable is font families, > >| so that switching to _italic_ means italic of the current font family, > >| for example. > > > To another extent, this can most easily be done by having different > typesetter (-Txxx) variants for each "family". For instance, for > PostScript printers, I have -Talw as the default with Times Roman descriptions > stored as R, I, B and BI; -TalwH analogously with Helvetica bold described in > the R, I etc. files. And so on. > The point of my feature is that this works using two or more font families in the same document, so that switching to italic when setting a subhead in Helvetica means Helvetica italic and switching to italic when setting text in Times means Times italic. Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu
murray@sq.sq.com (Murray Maloney) (06/24/89)
>In article <166@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >>In article <3236@gos.ukc.ac.uk>, iau@ukc.ac.uk (I.A.Utting) writes: >>>As quoted from <159@unmvax.unm.edu> by Walt Brainerd: >>> A feature we have not implemented, but think desirable is font families, >>> so that switching to _italic_ means italic of the current font family, >>> for example. >> [Stuff about seting up alternate typesetter (-Txxx) variants deleted.] SoftQuad has implemented font family support. For consideration in the proposed GNU troff -- I submit the following excerpt from our documentation: <EXCERPT> ********************************************************************** Selecting a The default font family in sqtroff is T (Times).* When the Font Family current typeface is selected as one of the generic typeface names (R, I, B, BI)**, the typeface actually selected will be the corresponding member of the current*** font family. That is, when Helvetica is the current font family, then ``.ft B'' is equivalent to ``.ft HB'', and either can be used to select Helvetica Bold. (The same applies to ``\f''.) The font family may be specified with the ``.ffam'' request, and the current font family name is available in the ``.ffam'' register. </EXCERPT> ********************************************************************* <FOOTNOTES> ******************************************************************** * Actually the default is installation dependent. You can change the default for any device in its DESC file (the device description file). ** The list of generic typefaces may be extended in the DESC file to include other members. Small caps (SC) and old style figures (OF) are examples. This is further supported by something that we call ``logical to physical font mapping''. SoftQuad's font tables allow you to systematically map a requested typeface/size to any available typeface/size. *** The font family, like the typeface and point size, are in the environment. </FOOTNOTES> ******************************************************************* >In article <166@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >The point of my feature is that this works using two or more font families >in the same document, so that switching to italic when setting a subhead >in Helvetica means Helvetica italic and switching to italic when setting >text in Times means Times italic. This implies the importance of setting the font family in the environment. You can have Times family in the text environment, Helvetica in the header environment, Courier in a source listing environment, etc. Thus, you can keep your font requests totally generic (R, I, B, BI) while maintaining design standards. With enough environments at your disposal, the task of macro programming also becomes less of a chore -- you don't have to write the code to store and restore formatting parameters. This has been a big win for me when producing manuals at SoftQuad. <POSTSCRIPT> ******************************************************************* This is turning into an interesting discussion. It has been quite some time since troff come under such close scrutiny on the net. I encourage all participants to continue posting comments and gripes. I'm certain that it will contribute to the development of robust and full-featured versions of GNU troff and third-party offerings. </POSTSCRIPT> ****************************************************************** ******************************************************************************** Murray C. Maloney uucp: {utai|utzoo|uunet}!sq!murray Documentation Specialist Internet: murray@sq.com SoftQuad Inc. Phone: (416) 963-8337
wnp@killer.DALLAS.TX.US (Wolf Paul) (07/22/89)
jes@mbio.med.upenn.edu (Joe Smith): >>> = Rick Richardson, rick@pcrat.UUCP >> = Brent Byer, brent@textware.UUCP >> Keep working at it. It isn't too hard, but it isn't for novices. >>> Troff has to be taught this. >> No, AT&T troff is perfectly capable of this, *as is*. >> Maybe, you have to be taught troff. :-) > >Having spent a *lot* of time trying to get troff and the standard >macro packages to do very normal kinds of things, I find the attitude >implied by this very disturbing on several counts, despite the smiley. Maybe the attitude is somewhat easier to understand if one realizes that Brent is the author and vendor of TPLUS software, which costs ca. $500 for the 286/LaserJet version, binaries and very scanty docs only, while Rick is the author of JetRoff, which is shareware available for $100 including source and VERY extensive docs. These two guys are COMPETITORS, and while TPLUS has several capabilities Jetroff doesn't (yet) have, Jetroff is perfectly adequate for the needs of many users, and more affordable. Apparently Brent feels Rick is a johnny-come-lately who is stealing some of his business, thus the acrimony. Understandable, but not necessarily appropriate. -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: {texbell, killer, dalsqnt}!dcs!wnp DOMAIN: wnp@killer.dallas.tx.us or wnp%dcs@texbell.swbt.com
lee@anduk.co.uk (Liam R. Quin) (07/22/89)
In article <13759@ncoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes: >As quoted from <25@nx32s.anduk.co.uk> by lee@anduk.co.uk (Liam R. Quin): >| [...] ( and . are not possible in the first character of a [troff] name >| nearly 100 names are pre-defined. On the other hand, some control >| characters are allowed.... >Beg pardon, but the only restriction I've found is that ( can not be used as >a single-character name; it is possible to define a macro called ".F", for >instance, and call it as "..F". I was wrong, sorry. You are not the only person to point this out. The version of ditroff I checked originally had been hacked badly... Even so, defining a number register or string whose name starts with a dot is not a good idea, because all of the read-only number registers do this (as in \n(.s, for example). But the number of names you can have *is* limited, and not simply by the name-space but by a built-in limit on the size of a (linear-searched) symbol table. >[...] I've not found a need to define "." as a >macro, but it could be useful e.g. to monitor memory usage as you define >macros, since troff will not only stop defining at .., it will execute the >macro called "." if it exists; make "." do a ".pm" for a quick memory-usage >debug check. (Or ".rn pm .".) No, you have to do .de xx . to get this behaviour. If you want it, I think I still have tmac.debug, and also a sed(?) script, for tracing troff. It monitors every nr/ds/de, and every call to every user-defined macro (xx, say) prints .xx "a1" "" "" "" "" "" "" "" "" or whatever. I haven't needed it in a couple of years, as I now use a version of troff that can print a much better debugging trace into the intermediate file. It's sometimes useful to define . and .. as macros if you are running a version of troff that can print warnings, as pic tends to put out lines starting with ..., and troff might say something like troff: pic.in: 34: warning call to undefined macro ".." ignored The -mm package also uses some ``commenting conventions'' which involve things that are not comments getting ignored, so it can be useful there, too. >++Brandon Maybe I should be --Lee :-( :-( Lee -- Lee Russell Quin, Unixsys UK Ltd, The Genesis Centre, Birchwood, Warrington, ENGLAND, WA3 7BH; Tel. +44 925 828181, Fax +44 925 827834 lee%anduk.uucp@ai.toronto.edu; {utzoo,uunet}!utai!anduk!lee UK: uu.warwick.ac.uk!anduk.co.uk!lee
brainerd@unmvax.unm.edu (Walt Brainerd) (07/23/89)
I thought I would be able to refrain from commenting on this, but guess I can't! It bothers me that someone is going to spend a year or two creating something that may not be as good as what is available now. Yes, I know the answer is that we should give away our version, but even that can't be done because the basic code belongs to AT&T. It is a very complex program, as we all know, and the chances of being compatible with AT&T troff after writing the program from scratch is very small, in my opinion. Anyway, to find out what stuff to put in, simply look at the extant versions. Softquad's sroff and our profficient probably have the most additional "features". I don't know who made the original posting, but would be glad to send a description of our features on request. In the meantime, here is a brief summary. In my use to typeset technical books, I find the first five by far the most important. By the way, in the long name business, it is the availability of arbitrarily many names and the ability to alias, remove, and rename that is really important. For example, it's really nice to have an unlimited number of environments. Upward compatibility with "standard" troff source. Compatibility with "standard" ditroff output (so device drivers work) Dictionary-driven hyphenation (as an option) Long names for requests, macros, registers, environments, and fonts and the ability to rename, alias, and remove these objects. Diagnostic messages when you do something stupid Testing if an object (e.g., macro or string) is defined. Tracing Improved line drawing to take advantage of the capbilities of typesetters and laser printers If/else.if/else/end.if construct While construct Shifting and concatenation of macro arguments Saving and restoring tab stops A feature we have not implemented, but think desirable is font families, so that switching to _italic_ means italic of the current font family, for example.
jeffrey@algor2.uu.net (Jeffrey Kegler) (08/04/89)
In reflecting further on this, I feel that ability to produce dvi files would be very valuable in GNU troff. There are many drivers available for these files, and such a facility would render GNU troff usable under a much wider variety of circumstances. -- Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc. jeffrey@algor2.UU.NET or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
wnp@attctc.Dallas.TX.US (Wolf Paul) (08/04/89)
In article <1989Aug3.193322.24941@algor2.uu.net> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >In reflecting further on this, I feel that ability to produce dvi >files would be very valuable in GNU troff. There are many drivers >available for these files, and such a facility would render GNU troff >usable under a much wider variety of circumstances. As has been pointed out before, ideally GNUtroff should be fully compatible with DWB2.0 troff (no objection to more capabilities, as long as it is fully compatible with DWB pre and post processors, as well as with standard troff input and macros. Therefore, it seems that DVI compatiblility would best be provided by a post processor which takes ditroff(5) output and produces DVI output. This would have the added advantage of being usable not only with GNUtroff, but with AT&T DWB 2.0 troff as well. If GNUtroff were to produce DVI output rather than ditroff(5) output, I seriously question whether it should be called any variant of "*roff" -- it would be misleading. The same would be true if it were incompatible with either the preprocessors or the standard troff request language, and thus the macro packages. Wolf -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: {texbell, attctc, dalsqnt}!dcs!wnp DOMAIN: wnp@attctc.dallas.tx.us or wnp%dcs@texbell.swbt.com NOTICE: As of July 3, 1989, "killer" has become "attctc".
debra@alice.UUCP (Paul De Bra) (08/04/89)
In article <1989Aug3.193322.24941@algor2.uu.net> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >In reflecting further on this, I feel that ability to produce dvi >files would be very valuable in GNU troff. There are many drivers >available for these files, and such a facility would render GNU troff >usable under a much wider variety of circumstances. Also, most output drivers for Tex dvi format come for free whereas troff output drivers are mostly commercial. So the Tex dvi format would fit the GNU purpose much better. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
debra@alice.UUCP (Paul De Bra) (08/05/89)
In article <8881@attctc.Dallas.TX.US> wnp@attctc.Dallas.TX.US (Wolf Paul) writes: }... }As has been pointed out before, ideally GNUtroff should be fully }compatible with DWB2.0 troff (no objection to more capabilities, as }long as it is fully compatible with DWB pre and post processors, as }well as with standard troff input and macros. } }Therefore, it seems that DVI compatiblility would best be provided by }a post processor which takes ditroff(5) output and produces DVI output. } }This would have the added advantage of being usable not only with GNUtroff, }but with AT&T DWB 2.0 troff as well. } }If GNUtroff were to produce DVI output rather than ditroff(5) output, }I seriously question whether it should be called any variant of "*roff" -- }it would be misleading. The same would be true if it were incompatible }with either the preprocessors or the standard troff request language, and }thus the macro packages. I fully agree that GNUtroff should be fully compatible with ditroff as far as input is concerned and the output it produces on paper. This does *not* imply that it couldn't use a different intermediate output language than ditroff. Long ago there was "troff", which produced output for just one type of phototypesetter. (In fact this is still the troff that comes with BSD.) When the output language was changed with the introduction of ditroff (device independent) the program was still called troff. There always was a variant which produced low quality output for other devices, but accepted the same input language, and it is "nroff". I see no objection to creating a program called "groff" which accepts again the same input language and produces output in yet another language, but which can be turned into printed output that closely resembles that of ditroff. Clearly the "roff" part of the name refers to the input language, and the initial letter may tell something about the output, depending on whether it is "t", "n" or now also "g". Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
cck@deneb.ucdavis.edu (Earl H. Kinmonth) (08/06/89)
In article <9746@alice.UUCP> debra@alice.UUCP () writes: >In article <8881@attctc.Dallas.TX.US> wnp@attctc.Dallas.TX.US (Wolf Paul) writes: >Long ago there was "troff", which produced output for just one type of >phototypesetter. (In fact this is still the troff that comes with BSD.) Long ago is relative. Unfortunately, the troff the comes with SCO Xenix is "classic troff" that works only with CAT devices. The problem is finding a CAT machine outside of the Smithsonian! As an historian, I suppose I should be happy that for only $150 or so SCO sells me a genuine heirloom, something that will appreciate in value if collecting old software ever acquires the status of art deco lamps or bubble gum cards, but in the meantime, I am pissed off. Earl H. Kinmonth History Department University of California, Davis 916-752-1636 (voice, fax [2300-0800 PDT]) 916-752-0776 secretary (bitnet) ehkinmonth@ucdavis.edu (uucp) ucbvax!ucdavis!ucdked!cck (telnet or 916-752-7920) cc-dnet.ucdavis.edu [128.120.2.251] request ucdked, login as guest, no password
rick@pcrat.uucp (Rick Richardson) (08/06/89)
In article <9746@alice.UUCP> debra@alice.UUCP () writes: >In article <8881@attctc.Dallas.TX.US> wnp@attctc.Dallas.TX.US (Wolf Paul) writes: >}Therefore, it seems that DVI compatiblility would best be provided by >}a post processor which takes ditroff(5) output and produces DVI output. > >I fully agree that GNUtroff should be fully compatible with ditroff as >far as input is concerned and the output it produces on paper. >This does *not* imply that it couldn't use a different intermediate >output language than ditroff. There is an automatic indexing package around that uses the ditroff intermediate language to pick out the words and the page numbers they appear on. There are also a whole slew of non-standard thingies that appear in troff *input*, by virtue of transparent pass-thru, that are used to drive the troff postprocessors to do things that cannot be expressed in the input language, such as bitmaps and shading. These are a couple of good reasons to keep ditroff intermediate output around as an option in groff. On the other hand, TeX has much better font metric information available, and I'm sure that groff will take advantage of this. The postprocessors also need to know some of this information as well. As it happens, JetRoff already has some knowledge of TeX style font metric information, since it uses "pk" format font files. The groff author has choosen to limit his efforts to Postscript and DVI. A reasonable limitation for a package that you get for free unless someone is selling it bundled with support. Nevertheless, I'm sure that after the initial release of groff, some kind soul will add ditroff output format. I've made the offer to take a look at the problem, implement it as time is available, and donate it back to GNU. I haven't heard any reply, and I apparently wasn't choosen as an alpha site. -Rick -- Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2 PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2 uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms. jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp
scott@dtscp1.UUCP (Scott Barman) (08/07/89)
In article <5061@ucdavis.ucdavis.edu> cck@deneb.ucdavis.edu (Earl H. Kinmonth) writes: >In article <9746@alice.UUCP> debra@alice.UUCP () writes: >>Long ago there was "troff", which produced output for just one type of >>phototypesetter. (In fact this is still the troff that comes with BSD.) > >Long ago is relative. Unfortunately, the troff the comes with SCO >Xenix is "classic troff" that works only with CAT devices. The >problem is finding a CAT machine outside of the Smithsonian! As an I know where you can find three of them and I think they might even pay you to take them away!! :-) :-) >historian, I suppose I should be happy that for only $150 or so SCO >sells me a genuine heirloom, something that will appreciate in value >if collecting old software ever acquires the status of art deco lamps >or bubble gum cards, but in the meantime, I am pissed off. In all seriousness, that is the problem with SCO and, IMHO, a problem I have with all these vendors selling a version of Unix (this is a topic for another news group and I won't expand here... if SCO wants to flame me, do it email!). As of System V Release 2, if you bought the document production software from AT&T, you'd get DWB 2.0. Now, I think you will get SoftQuad's work. But still, it is not the C/A/T troff. When a company I was working for finally got a source license, they gave us the source to the old C/A/T troff and had to pay extra for DWB. Someone told me they (AT&T) does not distribute the C/A/T troff. I think you should this up to SCO and remind them C/A/T troff is not SVR3 compatible (they advertise they are SVR3 compatible). Side note: the C/A/T was a cute device (programming wise) but I was glad when we (at a previous job) retired those things for an APS Micro-5! -- scott barman {gatech, emory}!dtscp1!scott
dmb@sei.cmu.edu (Daniel Berry) (08/14/89)
In article <9737@alice.UUCP> debra@alice.UUCP () writes: >In article <1989Aug3.193322.24941@algor2.uu.net> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >>In reflecting further on this, I feel that ability to produce dvi >>files would be very valuable in GNU troff. There are many drivers >>available for these files, and such a facility would render GNU troff >>usable under a much wider variety of circumstances. > >Also, most output drivers for Tex dvi format come for free whereas >troff output drivers are mostly commercial. So the Tex dvi format would >fit the GNU purpose much better. > >Paul. >-- However, the original ditroff device independent format is FAR more flexible. Besides the information stating which character goes where, there are some additional semantic markers that are NOT present in dvi: 1. end of output line marker 2. end of input word marker These two are extremely valuable for a number of ditroff postprocessors. The first allows ditroff to be made tri-directional (L-R, R-L, and T-B) for the purpose of multi-lingual formatting (Latin, Semitic, and Chinese) with NO change to ditroff (In order to do same with TeX -- a la JTeX and TeX/XeT, you have to change TeX). The second allows an indexing program to find occurrences of original words in an already formatted document. (See Abe-Berry article in SP&E January 1989) There are many other uses that this information can be put to if you think about it.. Therefore, I strongly suggest keeping the original functionality. Yes, the ditroff drivers are mostly commercial, but they are not that expensive (in the $400 range) and there are some public domain ones available. This situation is NOT unlike that for DVI drivers.. Dan -- Prof. Daniel M. Berry, Computer Science Department, Technion, Haifa 32000 ISRAEL Tel:+972-4-294325, Bitnet:DBERRY@TECHSEL Csnet & Internet:dberry@sel.technion.ac.il DASnet:[DDB1DM]dberry, MCIMail:277-9346 <dberry>