🚀 go-pugleaf

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