bugGNU roff - Bugs: bug #58450, additional inter-sentence spaces...

 
 

bug #58450: additional inter-sentence spaces should be stretched in fully justified text

Submitter:  Dave <barx>
Submitted:  Wed 27 May 2020 04:37:49 AM UTC
   
 
Category:  Core Severity:  1 - Wish
Item Group:  Feature change Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 04 Aug 2023 09:48:21 PM UTC, comment #3: 

Given the comment #2 input, Heirloom troff (and thus, probably, AT&T troff) behaves in the same manner in this regard as modern groff:

echo 'x x    x\p' | troff -x0 | dpost

This behavior is not made clear in CSTR#54:

An input text line ending with ., ?, or !, optionally followed
by any number of ", ', ), ], *, or , is taken to be the end of
a sentence, and an additional space character is automatically
provided during filling. To prevent this, add \& to the end of the
input line. Multiple inter-word space characters found in the input
are retained, except for trailing spaces; initial spaces also cause
a break.


Dave <barx>
Group Member
Fri 21 Jul 2023 07:31:33 PM UTC, comment #2: 

It turns out the behavior isn't limited to additional inter-sentence space.  Consider: what would you expect the following to produce?


echo 'x x    x\p' | groff


The quoted string contains 5 spaces: 1 between the first two x's, and 4 between the last two.

When the \p forces the line to be adjusted with this minimal input, a reasonable expectation would be that all five spaces would be stretched equally, producing four times the distance between the last two x's as between the first two.  Reasonable, and wrong.  As before, the difference in spacing is not visually detectable; only measuring reveals that the distance between the second and third x is a tiny bit wider than that between the first and second.

This is kind of interesting and kind of irrelevant.  Kind of interesting, because it suggests that the root cause of the behavior reported by this bug may not be related to the additional inter-sentence space (.ss's second parameter), but to any case of adjacent spaces.  Kind of irrelevant, because--unlike in the case of additional inter-sentence space--it's not clear what the behavior should be.  Typographically speaking, if a user wants horizontal space of other than a conventional width (e.g., word space, sentence space, thin space, digit space, etc.--all of which groff provides documented mechanisms for), the proper way to achieve that would be through the \h escape, not through trying to string together stretchable word spaces.

Dave <barx>
Group Member
Tue 02 Jun 2020 12:47:54 AM UTC, comment #1: 

original submission:

> This is a groff extension; classical troff's .ss request (as documented in CSTR #54) took only one parameter.


As a further historical note, while classical troff lacked a mechanism for specifying the amount of additional inter-sentence space, it did add such space, and seemingly with the same (subpar) algorithm that this bug report bemoans: stretching inter-word spaces without restriction but keeping the size of additional inter-sentence spaces fixed.

That is, running classical troff on the input file attached to comment #4 of bug #54101 produces four lines of output identical to one another -- because the second parameter to .ss is ignored -- but the same problematic spacing as in groff's output, where spaces between sentences are only infinitesimally wider than those between words.  (The difference is really not even detectable to the naked eye; you have to measure it.)

Dave <barx>
Group Member
Wed 27 May 2020 04:37:49 AM UTC, original submission:  

Background


The groff .ss request takes two parameters, the second one specifying the additional inter-sentence space.  This is a groff extension; classical troff's .ss request (as documented in CSTR #54) took only one parameter.

In fully justified text, groff stretches inter-word spaces, while keeping this additional inter-sentence space at a fixed width.

The problem


On output lines where spaces are stretched for justification, stretching one type of space but not the other alters the ratio of inter-word space to inter-sentence space that the user has requested with the two parameters to .ss.

In extreme cases, where inter-word spaces are significantly stretched, the additional inter-sentence space can become dwarfed by the amount of stretching done to the inter-word spaces on the line, rendering the additional inter-sentence space imperceptible.  Comment #4 of bug #54101 contains an example of this, showing that with large adjustments, spaces between words and those between sentences become nigh indistinguishable (to the point that the person who created the example thought no additional inter-sentence space was being added at all), surely not the desired outcome when the user has asked for inter-sentence spaces to be two to four times the width of inter-word spaces.

The solution


Further discussion in bug #54101 came to no resolution how best to address this.  According to this ranting but well-documented blog post, professional typography stopped using extra sentence spacing between the 1920s and the 1950s, breaking with two centuries of nearly universal typographic practice.  Ideally, when a groff user asks for additional inter-sentence space with the second parameter of .ss, groff would adjust these spaces in line with that historical practice.

I do not know the details of that practice.  This blog post states, "when a line needed to be expanded or compressed ... the aesthetics of how to handle the various width spaces... had complex rules that can be found in many of the manuals cited above," a vagueness that makes sense given that the question of adjusting is beyond this post's scope.  But it does quote a passage from the 1906 Chicago Manual of Style with some Byzantine (and, to my modern eyes, not entirely comprehensible) rules for adjusting a line, wherein space is added or removed depending on the shapes of the adjacent characters, among other considerations.  This is probably not only inadvisable in modern groff (it concerns a typesetting paradigm where other marks of punctuation also got something other than a standard word space after them), but not even possible, as I don't think groff has any awareness of letter shapes (else why would user intervention be required to avoid a collision between an italic f and a roman end parenthesis?).

Since bug #54101 was primarily concerned with a different (though related) issue, I'm opening this bug report to track this one.  Much of the text here comes from that bug report.

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-04 barx Severity3 - Normal 1 - Wish

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code