bugGNU troff - Bugs: bug #54101, documentation for .ss either...

 
 

bug #54101: documentation for .ss either incorrect or incomplete

Submitted by:  Dave <barx>
Submitted on:  Tue 12 Jun 2018 06:46:21 AM UTC  
 
Category:  Core Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Confirmed
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 18 Jun 2018 11:12:36 AM UTC, comment #5: 

The second .ss argument has an effect: the ps file you attached definitely shows a difference between its various values.  This file also further illustrates (probably better than my original example) the problem reported in this bug report: because SENTENCE_SPACE_SIZE spaces are not stretchable, the massive stretching of the WORD_SPACE_SIZE spaces dwarfs the fixed-width SENTENCE_SPACE_SIZE spaces to the point that they're nearly imperceptible.  But if you zoom in, you can tell that the words on different lines are not aligned.

This more strongly makes me think, as I began to ponder in comment #1, that the proper fix is to alter the software to match the documentation rather than vice versa.  It makes little typographic sense to have extra sentence spacing when this amount of space cannot be adjusted for filling.

But again, this decision should probably be made according to historical typesetting practice, and I'm not familiar with the details of how additional sentence space was historically implemented.

Dave <barx>
Sat 16 Jun 2018 11:50:27 PM UTC, comment #4: 

Distressingly, I can't get the second argument to .ss to have any effect at all.

See attachments.

(file #44379, file #44381)

G. Branden Robinson <gbranden>
Project Member
Sat 16 Jun 2018 06:34:28 PM UTC, comment #3: 

Hi, thanks for the followup.

I'm not sure what you're asking.  The discrepancy between what the info file says and what groff actually does exists no matter what any other piece of groff documentation has to say.  This discrepancy is what this bug report is documenting.

The groff_diff(7) passage you cite doesn't address stretching of spaces in fill mode at all, so I'm afraid I'm not following the connection you're trying to make.

Dave <barx>
Sat 16 Jun 2018 05:05:11 PM UTC, comment #2: 

Hi Dave,

Do you find the following discussion, from groff_diff(7), more helpful?

".ss m n                                                                

When two arguments are given to the ss request, the second argument gives the sentence space size.  If the second argument is not given, the sentence space size is the same as the word space size.  Like the word space size, the sentence space is in units of one twelfth of the spacewidth parameter for the current font.  Initially both the word space size and the sentence space size are 12.  Contrary to UNIX troff, GNU troff handles this request in nroff mode also; a given value is then rounded down to the nearest multiple of 12.  The sentence space size is used in two circumstances.  If the end of a sentence occurs at the end of a line in fill mode, then both an inter‐word space and a sentence space are added; if two spaces follow the end of a sentence in the middle of a line, then the second space is a sentence space.  Note that the behaviour of UNIX troff is exactly that exhibited by GNU troff if a second argument is never given to the ss request.  In GNU troff, as in UNIX troff, you should always follow a sentence with either a newline or two spaces."

G. Branden Robinson <gbranden>
Project Member
Wed 13 Jun 2018 02:52:43 PM UTC, comment #1: 

The other possibility is that the documentation is correct, and groff's noncompliance with it is a bug.

Modern typography does not add additional space between sentences.  To emulate that, documents cannot use the default .ss setting; they must explicitly invoke this request and pass 0 as its second parameter.  Groff should (and seems to) treat this 0 as fixed rather than stretchable.

In traditional typography, I don't know whether the extra sentence space was of fixed width, or adjusted proportionately with the word space.  But when using a nonzero SENTENCE_SPACE_SIZE, groff should probably follow historical practice in this regard.

Dave <barx>
Tue 12 Jun 2018 06:46:21 AM UTC, original submission:  

The documentation's .ss section states, "Initially both the WORD_SPACE_SIZE and SENTENCE_SPACE_SIZE are 12.  In fill mode, the values specify the minimum distance."

The latter sentence does not seem to be entirely accurate, in that a simple test shows that WORD_SPACE_SIZE specifies a minimum distance while SENTENCE_SPACE_SIZE specifies a fixed distance.  That is, if they were both minimum distances, they should both be stretched when filling text.  But this does not happen.  The input file:

Sentence one.
Sentence two.
Sentence three.\p

produces very large spaces between words, and that same size plus only a normal space width between sentences.

Although sentence spaces do not stretch in this simple example, are there cases where they do?

If not, the sentence claiming so in the documentation should be corrected.  (Possible wording: "In fill mode, WORD_SPACE_SIZE specifies the minimum distance.  The additional space added between sentences is always exactly SENTENCE_SPACE_SIZE.")

If there are, it might be useful for the documentation to specify under what circumstances this happens.

Dave <barx>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #44379:  54101.trf added by gbranden (271B - application/octet-stream)
file #44380:  54101.png added by gbranden (4KiB - image/png)
file #44381:  54101.ps added by gbranden (6KiB - application/postscript)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-06-16 gbranden Attached File- => Added 54101.trf, #44379
        Attached File- => Added 54101.png, #44380
        Attached File- => Added 54101.ps, #44381
        Item GroupDocumentation => Incorrect behaviour
        StatusNone => Confirmed

    Back to the top


    Powered by Savane 3.5