[Groff] XML as groff input

[Steve Izma]

On Thu, Mar 20, 2014 at 01:06:29PM +0000, Ralph Corderoy wrote:
> Subject: Re: [Groff] Mission statement, second draft
>
> I read _The TeXbook_ and returned to troff. The input language
> of troff is superior for mark-up that doesn't clutter the
> prose, e.g. often small and out of the way at the left of a
> line, and macro sets have tended to follow this. XML suffers
> terribly from noise, not intended for human entry, as I think
> you said elsewhere. asciidoc and friends are too simplified, OK
> for a github README but not typesetting.

Hi Ralph,

I think you're pointing at the basic issue here: how we write,
i.e., using computers as a composition tool. So I'm changing the
subject line, although I think this discussion really belongs on
a wiki where we can actually develop and share some good
practices.

Briefly, when I write I want to see text only with a minimum of
markup and with no reason for my fingers to leave the home row,
so that's why I suggest something simple like markdown. What do
you need when you're at the creative stage for most writing? a
blank line for paragraphs, one or two levels of subheads, maybe
blockquotes, inline markings for emphasis, titles, etc. All the
rest of the apparatus, scholarly or not, can be added on later,
when you don't really care about "noise".

So write creatively first, then think about presentation.

> Even though we're freed from two-letter everythings by modern
> troff, for common requests, a `.p' is all that's needed for the
> reader.

A blank line is obviously quieter than ".p" -- when you're at the
writing stage. When that's done, it's pretty easy to convert to
XML, and at that point I want clearly marked structure. But in my
experience -- I work mostly in scholarly publishing in the
humanities and in trade-oriented political texts -- the tag
set needed is not much more complicated than HTML5. DocBook is
overkill and most publishers smaller than the University of
Chicago Press don't have the funds to pay for such detailed
markup -- largely because the additional semantics don't result
in a more useful book to our audience. When that changes in the
future, then we'll add the extra detail -- or noise, or whatever
you want to call it. I've argued elsewhere that there's no gain
in efficiency to add the detail before it's really needed.

Using XML in the source document doesn't prevent you from using
the detailed troff commands -- you just divert your efforts to
the tmac file. It's the same thing as capturing a complex group
of troff requests into a macro that's appropriate for a certain
document. E.g., assuming all your first-level subheads should be
handled the same way, you wrap up font specs, spacing above and
below, justification & hyphenation specs, etc., into that macro,
rather than repeating the basic requests each time. In other
words, an XML tag is equivalent to a macro call.

But I think that XML has an advantage in things like this:

.H1 This is a long subhead that won't fit on one input \
source line, (so maybe it should be edited)

<h1>
This is a long subhead that
can go on as may lines as I want, if
I'm inelegant enough to keep it like this
</h1>

which, in my system, is equivalent to:

.h1((
This is a long subhead that
can go on as may lines as I want, if
I'm inelegant enough to keep it like this
.h1))

There are a number of other arguments for having opening and
closing macros for an element (even for a paragraph), but this
message is already too long.

        -- Steve

-- 
Steve Izma
-
Home: 35 Locust St., Kitchener N2H 1W6    p:519-745-1313
Work: Wilfrid Laurier University Press    p:519-884-0710 ext. 6125
E-mail: address@hidden or address@hidden

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
<http://en.wikipedia.org/wiki/Posting_style>