🚀 go-pugleaf

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