Re: On the term "justification"

[G. Branden Robinson]

Hi Doug,

At 2024-06-27T13:38:09-0400, Douglas McIlroy wrote:
> Roff adopted the term "adjust" from Runoff, in the guise of.ad and
> .na,

To reassure you, I'm aware; I consulted this history for the roff(7)
page that shipped in groff 1.23.0, and was able to prepare a partial
chronology of request introduction based on surviving documentation.
That exercise taught me a lot and threw much light on why the request
repertoire looks the way it does.

I would simply point out that, as far as I can tell, ".ad l", ".ad c",
and ".ad r" were later additions.[1]  But you are certainly well-placed
to correct me!  If I'm right, then I submit that the recognition of an
argument muddied the "adjustment" concept.  When all you had was `ad`
and `na`, adjustment meant only one thing--nice, simple, Boolean.

This is why I am careful to distinguish "alignment" from "adjustment".

> which have persisted sixty decades,

Possible error here--that would take us back to Johannes Gutenberg.  ;-)

> "Justify" joined the roff family lexicon well before Branden's
> citations, via pic's keywords ljust and rjust.

AT&T pic's manual is a little harder to lay hands on than other early
*roff components because it didn't show up until _after_ Seventh
Edition.  But conceding that pic has language keywords that carry the
"justification" banner doesn't make that term necessary to explain the
formatter itself and, indeed, CSTR #54 got along without it.

I note a few points of usage, insofar as I understand it:

* 'just' is a common morpheme of both 'justification' and 'adjustment',
  so a reader, especially a non-native English speaker, might infer
  either.

* As far as I can tell, pic doesn't enlist the formatter to _adjust_
  text at all.  So the only decision to make with text in (traditional)
  pic is how to _align_ it (left, right, or center).

* GNU pic has an "aligned" keyword, meaning that text is rotated along
  an axis joining the start and end control points of the associated
  geometric object.  It would certainly be disruptive to re-purpose the
  term here.  But because pic is for specialized needs, not general
  typesetting, I think the clash is excusable.[2]

* Even if we gave up the word "alignment" to describe anything GNU troff
  does, users with any background at all in typography would still
  come to the software with a prior understanding of the term, and want
  to know how this formatter grapples with it.

Major themes of my revisions to groff documentation have been reduction
of the size of the lexicon, and parallelization of terminological usage
wherever I feel free to do so (that is, not so much in components
actively maintained by others).  I trust that the virtue of simplicity
is as obvious in technical writing as it is in mathematics and
scientific theories.

Regards,
Branden

[1] See, for example,
    
<http://www.bitsavers.org/pdf/sds/9xx/940/ucbProjectGenie/mcjones/R-37_RUNOFF.pdf>.

    This documents a later version of RUNOFF than Salzer's, and appears
    to have added numerous features.

[2] Maybe introducing a replacement term, "rotated"--which is unused
    in the GNU pic manual except to define "aligned"--would be a good
    idea, leaving the latter of course as a synonym, as with "gifont"
    and "gfont" in the eqn forthcoming in groff 1.24.  Dare I suggest
    this as an improvement, since it is less likely to suggest to the
    ambitious graphic artist the possibility that pic will flow the text
    baseline along an arbitrary curve, as some fancy systems might?

signature.asc
Description: PGP signature