bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #54101] documentation for .ss either incorrect or incomplete


From: G. Branden Robinson
Subject: [bug #54101] documentation for .ss either incorrect or incomplete
Date: Fri, 8 May 2020 19:14:22 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Follow-up Comment #12, bug #54101 (project groff):

Okay, for the time being I've satisfied myself that you're right.

Here's a sample document that people can play with for their own experiments.


.pl 1v
.ll \V[LL]n
.ss \V[SS1] \V[SS2]
One two.
Three.
.brp
.warn 0
restore\ parity
.brp
.warn
One two. Three.
.brp


So, for instance, here's what I see.


$ for LL in $(seq 16 20); do LL=$LL SS1=12 SS2=12 ./build/test-groff -Tutf8
./EXPERIMENTS/ss-minimal.groff; done
One two.  Three.
restore parity
One  two. Three.

One  two.  Three.
restore parity
One  two.  Three.

One  two.   Three.
restore parity
One   two.  Three.

One   two.   Three.
restore parity
One   two.   Three.

One   two.    Three.
restore parity
One    two.   Three.



Note that in each pair of "One two. Three", groff has detected a sentence
ending in the first, but not the second.

Here's how I interpret it.

In the first pair (LL=15), the line length is precisely enough for the input
line with two spaces between the sentences; no adjust is required.  In the
second of the pair, that means a space is left over.  groff adjusts from the
left and places additional space at the first word break it sees.

In the second pair, LL=16, both items in the pair require adjustment.  The
first gets one space, and the second gets two, the latter of which happens in
the space between sentences, so the output is identical.

The pattern repeats as the line length increases.

This interpretation is also consistent with my understanding of the code. 
There is a function called distribute_spaces() in src/roff/troff/env.cpp,
which handles adjustment.  By the time processing reaches that point, groff is
working over a list of nodes.  There are several types of these, but the
important one here belongs to the class 'space_node'.

If we instrument this function, we see that the additional inter-sentence
space has already been coalesced into the interword space:


diff --git a/src/roff/troff/env.cpp b/src/roff/troff/env.cpp
index c11d2dfc..26324b6c 100644
--- a/src/roff/troff/env.cpp
+++ b/src/roff/troff/env.cpp
@@ -2086,6 +2086,8 @@ static void distribute_space(node *n, int nspaces,
hunits desired_space,
     if (Ems > spread_limit)
       output_warning(WARN_BREAK, "spreading %1m per space", Ems);
   }
+  error("GBR: distributing %1 units of space across %2 nodes",
+       desired_space.to_units(), nspaces);
   for (node *tem = n; tem; tem = tem->next)
     tem->spread_space(&nspaces, &desired_space);
   if (force_reverse || reverse)


Here's the noise this produces.


troff: backtrace: file './EXPERIMENTS/ss-minimal.groff':6
troff: ./EXPERIMENTS/ss-minimal.groff:6: error: GBR: distributing 0 units of
space across 2 nodes
troff: backtrace: file './EXPERIMENTS/ss-minimal.groff':9
troff: ./EXPERIMENTS/ss-minimal.groff:9: error: GBR: distributing 0 units of
space across 0 nodes
troff: backtrace: file './EXPERIMENTS/ss-minimal.groff':12
troff: ./EXPERIMENTS/ss-minimal.groff:12: error: GBR: distributing 24 units of
space across 2 nodes
One two.  Three.
restore parity
One  two. Three.

troff: backtrace: file './EXPERIMENTS/ss-minimal.groff':6
troff: ./EXPERIMENTS/ss-minimal.groff:6: error: GBR: distributing 24 units of
space across 2 nodes
troff: backtrace: file './EXPERIMENTS/ss-minimal.groff':9
troff: ./EXPERIMENTS/ss-minimal.groff:9: error: GBR: distributing 0 units of
space across 0 nodes
troff: backtrace: file './EXPERIMENTS/ss-minimal.groff':12
troff: ./EXPERIMENTS/ss-minimal.groff:12: error: GBR: distributing 48 units of
space across 2 nodes
One  two.  Three.
restore parity
One  two.  Three.
[...and so forth...]


The question I have is, should extra space be distributed in keeping with the
relative proportion of additional intersentence space to interword space?

That's more of a typography question than a code question.  One of us can take
it to the list, I reckon.

In the meantime, as you noted, clarifying the documentation to tell the truth
should resolve this ticket.  :)

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?54101>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]