Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cmcl2!nrl-cmf!ames!hc!pprg.unm.edu!unmvax!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: <762@dtscp1.UUCP> Date: 10 Jun 89 06:25:17 GMT References: <742@dtscp1.UUCP> <10959@orstcs.CS.ORST.EDU> <21@nx32s.anduk.co.uk> Reply-To: scott@dtscp1.UUCP (Scott Barman) Distribution: comp Organization: Digital Transmission Systems (a subsidiary of DCA), Duluth, GA Lines: 60 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