Discussion:
[bug #57836] grotty's adjustment algorithm is not diversion-aware
(too old to reply)
Dave
2020-02-17 07:43:05 UTC
Permalink
URL:
<https://savannah.gnu.org/bugs/?57836>

Summary: grotty's adjustment algorithm is not diversion-aware
Project: GNU troff
Submitted by: barx
Submitted on: Mon 17 Feb 2020 01:43:04 AM CST
Category: Device - others
Severity: 3 - Normal
Item Group: Incorrect behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None

_______________________________________________________

Details:


$ groff -Tascii tty_example | head -14
For TTY output with full justification, grotty pads by adding
extra spaces alternating every line left-to-right and right-to-
left, as can be seen in this paragraph. This helps to preserve
overall uniform grayness throughout the text, as well as a
monospaced typeface allows.

But diversions requiring adjustment apparently are included in
this sequence even if they are not output right away (or ever,
for that matter). This means that a number of closely spaced
diversion definitions can break grotty's balancing algorithm,
putting all the space on the same end of every line, as this
paragraph demonstrates.


$ cat tty_example
.nh
For TTY output with full justification, grotty pads by
adding extra spaces alternating every line left-to-right and
right-to-left, as can be seen in this paragraph. This helps
to preserve overall uniform grayness throughout the text,
as well as a monospaced typeface allows.
.
.sp
.
But diversions requiring adjustment apparently are included in
this sequence even if they are not output right away (or ever,
.box dummy
This is some dummy text, enough to kick in the adjustment algorithm.
.box
for that matter). This means that a number of closely spaced
.box dummy
This is some dummy text, enough to kick in the adjustment algorithm.
.box
diversion definitions can break grotty's balancing algorithm,
.box dummy
This is some dummy text, enough to kick in the adjustment algorithm.
.box
putting all the space on the same end of every line, as this
.box dummy
This is some dummy text, enough to kick in the adjustment algorithm.
.box
paragraph demonstrates.
$ groff -Tascii --version
GNU groff version 1.22.4.74-b400-dirty
Copyright (C) 2018 Free Software Foundation, Inc.
GNU groff comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of groff and its subprograms
under the terms of the GNU General Public License.
For more information about these matters, see the file
named COPYING.

called subprograms:

GNU grotty (groff) version 1.22.4.74-b400-dirty
GNU troff (groff) version 1.22.4.74-b400-dirty





_______________________________________________________

Reply to this item at:

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

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
Dave
2020-07-15 15:59:51 UTC
Permalink
Follow-up Comment #1, bug #57836 (project groff):

This could be considered a different bug from the one reported in comment #0.
But they are closely related, and fixing both at the same time is probably
easier than fixing them both in isolation. But if that turns out to be wrong,
I can open a new bug report for this manifestation.

$ nroff tty | uniq
While the example in this bug's previous comment is somewhat
contrived and a bit of an edge case in real life, there turns out
to be a more innate bug in grotty's balancing algorithm. As
mentioned before (and easily observable), when grotty adds spaces
to a line in the process of justifying it, the algorithm it
utilizes adds spaces from opposite ends of each line. But when it
adds this space, it does not take into account lines with no
adjustment at all required. Therefore if space only need be added
to every other line of the text, all the space ends up being
added to the same end of the line, degrading the uniform grayness
of the output, as can be seen in this example. There is one
fairly simple way to address this: grotty shouldn't "count" lines
that don't need to be adjusted; instead, it should apply the
alternation pattern only to those lines that do need adjustment.

$ cat tty
.nh
.ss 12 0
While the example in this bug's previous comment is somewhat
contrived and a bit of an edge case in real life, there turns out
to be a more innate bug in grotty's balancing algorithm. As
mentioned before (and easily observable), when grotty adds spaces
to a line in the process of justifying it, the algorithm it
utilizes adds spaces from opposite ends of each line. But when it
adds this space, it does not take into account lines with no
adjustment at all required. Therefore if space only need be added
to every other line of the text, all the space ends up being
added to the same end of the line, degrading the uniform grayness
of the output, as can be seen in this example. There is one
fairly simple way to address this: grotty shouldn't "count" lines
that don't need to be adjusted; instead, it should apply the
alternation pattern only to those lines that do need adjustment.
$

Here is the same paragraph adjusted by hand using the suggested change to the
algorithm. The overall grayness does not change from one side of the column
to the other as it did before; it's much more pleasing to the eye, while being
no harder (or easier) to read. (If you're reading this in an email client
that uses a proportional typeface, neither example will display properly.
Look at them in the bug tracker.)

While the example in this bug's previous comment is somewhat
contrived and a bit of an edge case in real life, there turns out
to be a more innate bug in grotty's balancing algorithm. As
mentioned before (and easily observable), when grotty adds spaces
to a line in the process of justifying it, the algorithm it
utilizes adds spaces from opposite ends of each line. But when it
adds this space, it does not take into account lines with no
adjustment at all required. Therefore if space only need be added
to every other line of the text, all the space ends up being
added to the same end of the line, degrading the uniform grayness
of the output, as can be seen in this example. There is one
fairly simple way to address this: grotty shouldn't "count" lines
that don't need to be adjusted; instead, it should apply the
alternation pattern only to those lines that do need adjustment.


_______________________________________________________

Reply to this item at:

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

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

Loading...