[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #57836] grotty's adjustment algorithm is not diversion-aware
From: |
Dave |
Subject: |
[bug #57836] grotty's adjustment algorithm is not diversion-aware |
Date: |
Wed, 15 Jul 2020 11:59:51 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0 |
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/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [bug #57836] grotty's adjustment algorithm is not diversion-aware,
Dave <=