Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!ukc!warwick!anduk!lee From: lee@anduk.co.uk (Liam R. Quin) Newsgroups: comp.text Subject: Re: What features would you like in GNU troff? Message-ID: <21@nx32s.anduk.co.uk> Date: 8 Jun 89 21:51:01 GMT References: <742@dtscp1.UUCP> <10959@orstcs.CS.ORST.EDU> Reply-To: lee@nx32s.UUCP (0000-Liam R. Quin) Distribution: comp Organization: Unixsys (UK) Ltd, Warrington, England Lines: 131 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