Re: Heirloom Troff for NetBSD (was: Removing ARCNET stuffs)

["James K. Lowden" <jklowden%schemamania.org@localhost>]

On Mon, 08 Jun 2015 18:31:32 -0700
"Greg A. Woods" <woods%planix.ca@localhost> wrote:

> I think the reason these more modern tools are better at making the
> message fit more mediums is because they move away from describing the
> details of layout, formatting, justification, etc., and deal more in
> higher level document structure.  Getting the details "right" for a
> particular medium is often a "one-time" effort serving many authors.  

I agree with the thrust of your message, but not with this particular
point.  

Here's the thing: they're not better.  The can't be.  The "problem" of
"authoring" for many media in a single document is invented and
insoluble.  

Semantic markup can take you only so far.  Remember, it was invented by
IBM to help teams write documentation consistently, so the technical
writers wouldn't have to learn a style guide that described the font for
replaceable user-input text etc.  Semantic markup won't help you with
footnotes and sidebars.  It can't change a piece of paper into an
interactive browser.  It can't make the fine-tuning decisions about how
to arrange the text and the graphics so they're most readily viewed
together.  

> >  But from a technical standpoint, troff requests
> > and macros present the lowest markup/content ratio of any system I
> > know.  ISTM that should be the measure.
> 
> While that's certainly true that troff _requests_ are at the lowest
> level, that is far less true of macro packages such as mdoc(7) and MOM
> which are mostly about high-level document structure

I'm afraid I wasn't clear.  The ratio I was referring to is that of the
number of characters devoted to markup versus those of the text
itself.  I'm arguing that 

	.B here

is better than 

	<b>here</b>

because that ratio is 3/4 (counting the space after ".B") versus 7/4.
IOW, troff supports the tersest markup language.  And that's a good
thing because it minimizes the author's work.  

> > It would be nice to have a BSD license, UTF-8 support,
> > paragraph-at-a-time formatting, and PDFs with navigation.
> > Unfortuately at present we have to choose.
> 
> I'm not sure what you mean exactly.  I do not see any "choice".  When
> faced with all the issues combined Heirloom Troff is the only decent
> fit, and has been for the better part of a decade now (though of
> course some of the newer requirements on the list, such as perhaps
> navigation support for generated PDFs and better Groff compatibility
> have only been met by more recent improvements in Heirloom Troff).

I didn't know Heirloom Troff produces PDFs directly, a feature I think
is very valuable.  In that case, is there any reason not to substitute
it for groff, apart from some engineering work and possibly some
touch-up to a few documents?  

I suspect the answer brings us full circle, to the question of whether
or not to support/include troff per se in the first place.  

To the people who say the troff syntax is antiquated I ask, how so?
Because requests start with a dot in column zero?  So it looks funny?  

It's not an accident that Plan9 kept troff, or for that matter that
Kernighan did when he re-wrote it.  It's lightweight, in terms of both
user input and machine resources.  It supports both semantic markup like
mdoc and low-level choices (and device-specific choices) in one input
stream.  It's hard to improve on.  It would be a shame to dump it just
because it seems old-fashioned.  

--jkl