[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[G. Branden Robinson]

Follow-up Comment #15, bug#64285 (group groff):

[comment #14 comment #14:]
> we now know that in the six months that 1.23 has been out, people have
complained about various changes debuting in it, but not this one (at least
not where I've seen it, though of course I don't follow every forum where such
complaints might be voiced).

I've been keeping an eye out as well, in many places (doing Web searches,
checking out distributors' change logs and bug trackers, monitoring techie Q
forums, and so forth).

Not a peep about \s.  This isn't a surprise to me, because most usage of the
escape sequence that I have seen isn't ambiguous.  Mostly what I see is man
pages (likely because they constitute a majority of *roff documents in the
world), doing stuff like:


foo\s-2bar\s0baz


...that.  These aren't ambiguous and we didn't change them.

We can revisit the matter in another six months, maybe, to see if we need to
update our observations, but assuming the level of consternation remains low
to zero, then I'd say the \s change was a good example of the sort of
regularizing, simplifying reform we _should_ be undertaking.

Just like \D't' not altering the drawing position!  ;-)

I trust I will not draw contradiction when I venture that explicit/manual use
of that escape sequence in documents is unlikely to be more prevalent than
\s.

If we want to start up another argument along these...lines, we can debate
whether the \D'p' request should automatically close the specified polygon, or
whether that drawing command is better thought of as a "polyline" operator. 
[https://lists.gnu.org/archive/html/groff/2023-08/msg00041.html This thread is
probably the place to resurrect the discussion initially.]


___

Reply to this item at:

  

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

Re: [bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[Steve Izma]

On Sun, Jan 14, 2024 at 05:23:28PM -0500, G. Branden Robinson wrote:
> Subject: [bug #64285] [troff] \D't' (set line thickness) drawing command
>  alters drawing position
> 
> Update of bug#64285 (group groff):
> ...
> > If you think fixing a crazy (but well known and documented)
> > "feature" is more important than maintaining 30 years of
> > groff compatibility,
> 
> I pretty much do, yeah.  Every crazy feature we keep dragging
> along with us makes the language harder to acquire, remember,
> and work with.  Where the size of the impacted user community
> is small, as it surely is here--I fear the most prolific users
> of drawing escape sequences outside of macro packages or
> preprocessors are cargo cultists--it seems an easy choice to
> make.

I agree that this should be fixed. But I can't imagine any
situation where the current behaviour can be considered a
feature. It's more likely that everyone using to the \Z'' fix is
doing so as a workaround and any such documents would be
unaffected by improving the \D't' behaviour.

I don't understand your reference to "cargo cultists". There are
scads of situations where one doesn't want to bother with macro
packages, e.g., one-page posters, flyers, announcements. I've
probably made hundreds of them with groff. Those are the kinds of
situations where one draws lots of lines and where this bug
becomes a nuisance.

The term "cargo cult" is almost always used in a pejorative way.
But I've been to Vanuatu and it's clear to me that the real
history of cargo cults is a history of anti-colonial movements
that engaged in communal, ritualized resistance, not so-called
superstition.

-- Steve

-- 
Steve Izma
-
Home: 35 Locust St., Kitchener, Ontario, Canada  N2H 1W6
E-mail: si...@golden.net  cellphone: 519-998-2684

==
The most erroneous stories are those we think we know best – and
therefore never scrutinize or question.
-- Stephen Jay Gould, *Full House: The Spread of Excellence
   from Plato to Darwin*, 1996

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[Dave]

Follow-up Comment #14, bug#64285 (group groff):

[comment #12 comment #12:]
> If you think fixing a crazy (but well known and documented) "feature"
> is more important than maintaining 30 years of groff compatibility,

I wrote a response to this point as well, then realized I was only repeating
my remarks of comment #4--except that where in that comment I had to say
"there's yet to be a released groff with the \s change, so we don't yet know
what gnashing of teeth it might engender," we now know that in the six months
that 1.23 has been out, people have complained about various changes debuting
in it, but not this one (at least not where I've seen it, though of course I
don't follow every forum where such complaints might be voiced).


___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[G. Branden Robinson]

Update of bug#64285 (group groff):

  Status:   Need Info => None   
 Assigned to:deri => gbranden   

___

Follow-up Comment #13:

[comment #12 comment #12:]
> If you think fixing a crazy (but well known and documented) "feature" is
more important than maintaining 30 years of groff compatibility,

I pretty much do, yeah.  Every crazy feature we keep dragging along with us
makes the language harder to acquire, remember, and work with.  Where the size
of the impacted user community is small, as it surely is here--I fear the most
prolific users of drawing escape sequences outside of macro packages or
preprocessors are cargo cultists--it seems an easy choice to make.

For an example of me biting the bullet and restoring backward compatibility in
spite of my strong view that it was the wrong _technical_ choice, see bug
#51468.

> then it would probably make sense for you to do the deed (to libdriver and
gropdf) in the same commit. Just comment out the two lines about 3916 (in
section dealing with "Line Thickness "):-

>   $poschg=1;
>   $xpos+=$lwidth;


> And test with the code in comment #9. Both paragraphs should be the same,
and with no unusual gap later in the first lines.

Thanks for the fish, there's no telling how long I'd have been out on the
ocean casting my rod and reel fruitlessly for that one.  :)

Clearing status and reassigning to self.

Not sure when I'll get to it.  I predict low difficulty but the urgency is
also low.


___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[Deri James]

Follow-up Comment #12, bug#64285 (group groff):


[comment #10 comment #10:]
> I see very little difference between PS and PDF output for your input
exhibit in comment #9, using bleeding-edge _groff_.

I agree.

> Regarding the topic at issue, I propose that the first and second paragraphs
should look the same, regardless of output device.  I am willing to undertake
the alternation of the "libdriver"-based output drivers to realize this
output, in coordination with changes in _gropdf_ to achieve the same.
> 
> What do you think?

If you think fixing a crazy (but well known and documented) "feature" is more
important than maintaining 30 years of groff compatibility, then it would
probably make sense for you to do the deed (to libdriver and gropdf) in the
same commit. Just comment out the two lines about 3916 (in section dealing
with "Line Thickness "):-

$poschg=1;
$xpos+=$lwidth;

And test with the code in comment #9. Both paragraphs should be the same, and
with no unusual gap later in the first lines.



___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[Dave]

Follow-up Comment #11, bug#64285 (group groff):

[comment #10 comment #10:]
> I _do_ observe some tiny differences (in kerning), for instance:
Kerning appears to be done by troff, not the postprocessor:

$ diff <(printf 'AVATAR\n' | groff -Z) <(printf '.kern 0\nAVATAR\n' | groff
-Z)
12,20c12
< tA
< H77870
< tV
< H83740
< tA
< H89850
< tT
< H95030
< tAR
---
> tAVATAR

So any kerning differences should be the result of differences in kerning data
in the font description files of the respective ps and pdf devices.

> However, these do not seem relevant to this ticket.

Agreed.


___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[G. Branden Robinson]

Update of bug#64285 (group groff):

 Assigned to:gbranden => deri   

___

Follow-up Comment #10:

I see very little difference between PS and PDF output for your input exhibit
in comment #9, using bleeding-edge _groff_.

I _do_ observe some tiny differences (in kerning), for instance:

1. between "i" and "a" in "diam" on the first line
2. between "l" and "i" in "aliquyam" on the second line
3. between "r" and "a" in "erat" on the second line
4. between "m" and "a" in "takimata" on the third line
5. between "e" and "s" in "est" on the third line
6. between "e" and "r" in "vero" on the third line
7. between "e" and "t" in "et" on the third line
8. between "b" and "u" in "rebum" on the fourth line

However, these do not seem relevant to this ticket.  I'm also not particularly
bothered by the differences, so I reckon I'll let Dave or some other
microtypographical maven take up the case.

Regarding the topic at issue, I propose that the first and second paragraphs
should look the same, regardless of output device.  I am willing to undertake
the alternation of the "libdriver"-based output drivers to realize this
output, in coordination with changes in _gropdf_ to achieve the same.

What do you think?


___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[Deri James]

Update of bug #64285 (project groff):

 Assigned to:deri => gbranden   

___

Follow-up Comment #9:

Did you test the code snippet I suggested against grops and gropdf? It would
be helpful to see the pdfs and grout files. This is it:-

===


.sp 2i
.ll 12c
Left\D't 5p'\fBIndent\fP\D'l 10p 0' Lorem ipsum dolor sit amet, consetetur 
sadipscing elitr, sed diam
nonumy eirmod tempor invidunt ut labore et do\%lo\%re magna ali\%quyam erat,
sed diam voluptua. Stet clita kasd gubergren, no sea takimata sanctus est.
At vero eos et accusam et justo duo do\%lo\%re et ea rebum.
.sp
Left\fBIndent\fP\D'l 10p 0' Lorem ipsum dolor sit amet, consetetur sadipscing

elitr, sed diam
nonumy eirmod tempor invidunt ut labore et do\%lo\%re magna ali\%quyam erat,
sed diam voluptua. Stet clita kasd gubergren, no sea takimata sanctus est.
At vero eos et accusam et justo duo do\%lo\%re et ea rebum.


==





___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[G. Branden Robinson]

Update of bug #64285 (project groff):

  Status: In Progress => Need Info  
 Assigned to:gbranden => deri   

___

Follow-up Comment #8:

Assigning to Deri to get his feedback.


___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[G. Branden Robinson]

Follow-up Comment #7, bug #64285 (project groff):

I haven't pushed this to my private branch, but I did push a set of unit tests
for all the drawing commands.

Here's what I have at present in my working copy for this ticket.

Find some preparatory commits first.  These are in fact the first commits I
have queued after `branden-2023-07-05`.

Deri, do you find this to be more complete?


commit be20c8f61fd0e5529b0a60821ac0f043ef918d0f
Author: G. Branden Robinson 
AuthorDate: Thu Jun 8 19:46:29 2023 -0500
Commit: G. Branden Robinson 
CommitDate: Wed Jul 5 15:57:37 2023 -0500

[troff]: Slightly refactor.

* src/roff/troff/node.cpp (troff_output_file::determine_line_limits):
  Slightly refactor.  Stop repeating code.  Add new Boolean,
  `do_generic_limit_check`, defaulting true.  In the switch that handles
  various drawing commands, set it false for those that perform
  specialized output limit checks.  Explicitly handle 'f' drawing
  command (though it has been deprecated since groff 1.19 in 2003).

Tested with

./build/test-groff -pet -ms -Z doc/pic.ms
./build/test-groff -M ./doc -ge -me -Z doc/grnexmpl.me

before and after.  No change.

diff --git a/ChangeLog b/ChangeLog
index 447d530c7..a53763d0b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -24,6 +24,16 @@
 
* src/roff/groff/groff.am (groff_TESTS): Run tests.
 
+2023-06-08  G. Branden Robinson 
+
+   * src/roff/troff/node.cpp
+   (troff_output_file::determine_line_limits): Slightly refactor.
+   Stop repeating code.  Add new Boolean, `do_generic_limit_check`,
+   defaulting true.  In the switch that handles various drawing
+   commands, set it false for those that perform specialized output
+   limit checks.  Explicitly handle 'f' drawing command (though it
+   has been deprecated since groff 1.19 in 2003).
+
 2023-06-08  G. Branden Robinson 
 
[man, mdoc]: Parameterize page offset.
diff --git a/src/roff/troff/node.cpp b/src/roff/troff/node.cpp
index 4d872189e..e2bbcfa9e 100644
--- a/src/roff/troff/node.cpp
+++ b/src/roff/troff/node.cpp
@@ -1373,6 +1373,7 @@ void troff_output_file::determine_line_limits(char code,
hvpair *point,
  int npoints)
 {
   int i, x, y;
+  bool do_generic_limit_check = true;
 
   if (!is_on())
 return;
@@ -1385,6 +1386,7 @@ void troff_output_file::determine_line_limits(char code,
hvpair *point,
output_vpos - point[0].h.to_units()/2);
 check_output_limits(output_hpos + point[0].h.to_units(),
output_vpos + point[0].h.to_units()/2);
+do_generic_limit_check = false;
 break;
   case 'E':
   case 'e':
@@ -1392,6 +1394,7 @@ void troff_output_file::determine_line_limits(char code,
hvpair *point,
output_vpos - point[0].v.to_units()/2);
 check_output_limits(output_hpos + point[0].h.to_units(),
output_vpos + point[0].v.to_units()/2);
+do_generic_limit_check = false;
 break;
   case 'P':
   case 'p':
@@ -1403,15 +1406,9 @@ void troff_output_file::determine_line_limits(char
code, hvpair *point,
   y += point[i].v.to_units();
   check_output_limits(x, y);
 }
+do_generic_limit_check = false;
 break;
   case 't':
-x = output_hpos;
-y = output_vpos;
-for (i = 0; i < npoints; i++) {
-  x += point[i].h.to_units();
-  y += point[i].v.to_units();
-  check_output_limits(x, y);
-}
 break;
   case 'a':
 double c[2];
@@ -1434,16 +1431,13 @@ void troff_output_file::determine_line_limits(char
code, hvpair *point,
 }
 // fall through
   case 'l':
-x = output_hpos;
-y = output_vpos;
-check_output_limits(x, y);
-for (i = 0; i < npoints; i++) {
-  x += point[i].h.to_units();
-  y += point[i].v.to_units();
-  check_output_limits(x, y);
-}
+  case 'f': // deprecated in groff 1.19
 break;
   default:
+break;
+  }
+
+  if (do_generic_limit_check) {
 x = output_hpos;
 y = output_vpos;
 for (i = 0; i < npoints; i++) {



commit 2096210e7a301b4b2b727c9bc24382ececf14ba3
Author: G. Branden Robinson 
AuthorDate: Thu Jun 8 20:11:09 2023 -0500
Commit: G. Branden Robinson 
CommitDate: Wed Jul 5 15:57:37 2023 -0500

[troff]: Refactor to clarify.

* src/roff/troff/node.cpp (troff_output_file::determine_line_limits):
  Make the 'l', 't', and '~' commands (more clearly) use the generic
  output limit check.  More clearly make the 'a' command not use it.

Tested with

./build/test-groff -pet -ms -Z doc/pic.ms
./build/test-groff -M ./doc -ge -me -Z doc/grnexmpl.me

before and after.  No change.

diff --git a/ChangeLog b/ChangeLog
index a53763d0b..c113ff858 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -24,6 +24,13 @@
 
* src/roff/groff/groff.am (groff_TESTS): Run tests.
 
+2023-06-08  G. Branden Robinson 
+
+   * 

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[Dave]

Follow-up Comment #6, bug #64285 (project groff):

[comment #5 comment #5:]
> I am concerned this patch is not complete.

Fair point.

In terms of tweaks to the patch, it also might be better to follow -mom's
example and wrap the \D't' in a \Z in the two preprocessors' output as well. 
That way things will still work even if the versions of pic and groff differ. 
(This is probably not a supported configuration, and may break other things,
but the preprocessors may as well be made version-agnostic on this score,
since it's trivial to do.)


___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[Deri James]

Follow-up Comment #5, bug #64285 (project groff):

The list message to which you refer contained a snippet of code intended to
show that the changes to pre-processors and troff would not be sufficient,
some changes to post processors would be required as well. (It's a one line
change in gropdf, but I could not find it in grops).

The proposed changes which were attached to a later message did not apply
cleanly to head, but I ran the code snippet and there was no change in
behaviour. This may be due to the patch failure, or the patch did not alter
troff's notion of the current horizontal position, i.e. the \D't' parameter
was still resulting in troff considering it as a horizontal motion.

I am not completely against this change in odd behaviour, but I am concerned
this patch is not complete.


___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[Dave]

Follow-up Comment #4, bug #64285 (project groff):

On the email list, Deri made a case
(http://lists.gnu.org/r/groff/2023-06/msg00073.html) for leaving this behavior
as-is.  This post has thus far garnered no reply.

To me, the behavior seems oddball enough that it likely was a bug which then
got documented, making it technically no longer a bug but still oddball
behavior.

While I sympathize with Deri's concern for users who rely on this behavior, I
bet it's a pretty small number, and there may be just as many who find that
the fix corrects problems in their documents.  The ones most likely to be
affected are those who coded workarounds to the undesired movement, which may,
after this fix, introduce new undesired movement.  (This would be the case
with code generated by both the grn and pic preprocessors; the attached patch
is obliged to remove their workarounds.)  But even that depends on how their
workaround was done: for -mom, Peter mentioned
(http://lists.gnu.org/r/groff/2023-06/msg00093.html) he would wrap \D't'
escapes in \Z, rendering moot whether or not \D't' moves the drawing
position.

In general, I share Branden's preference for making minor sacrifices to strict
back compatibility when the historical behavior is wildly counterintuitive
(see also bug #64275).  It is highly useful to allow groff to correctly render
roff source prepared 20, 30, 40 years ago.  However, for attracting and
retaining new users, it's also important to reduce the number of inexplicable
quirks: there comes a point when users trying to learn the system will grow
tired of dodging all the quicksand pits and move on to something else.  A
groff that caters only to the past and not to the future is a groff with a
baked-in shelf life.

The change proposed here seems rather less intrusive--and affecting less
entrenched behavior--than the early-2020 change to \s's semantics
([http://git.savannah.gnu.org/cgit/groff.git/commit/?id=0b9aaca0 commit
0b9aaca0]).  And that was a change to deliberate behavior (albeit behavior
tied to a historical device no one uses anymore) rather than an arguable bug
fix.  Of course, there's yet to be a released groff with the \s change, so we
don't yet know what gnashing of teeth it might engender.

cc:ing Deri so he can rebut any of the above points.


___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[G. Branden Robinson]

Follow-up Comment #3, bug #64285 (project groff):

I have a fix ready to go.  Attached.  It's in Git's usual reverse
chronological order, so it might help to read it from the bottom.

(file #54825)

___

Additional Item Attachment:

File name: 64285.diff Size:14 KB




___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[G. Branden Robinson]

Follow-up Comment #2, bug #64285 (project groff):

I'm thinking the pic part will look something like this.


diff --git a/src/preproc/pic/troff.cpp b/src/preproc/pic/troff.cpp
index 3dc87a721..00d244c84 100644
--- a/src/preproc/pic/troff.cpp
+++ b/src/preproc/pic/troff.cpp
@@ -475,7 +475,7 @@ void troff_output::line_thickness(double p)
   if (p < 0.0)
 p = RELATIVE_THICKNESS;
   if (driver_extension_flag && p != last_line_thickness) {
-printf("\\D't %.3fp'\\h'%.3fp'\n.sp -1\n", p, -p);
+printf("\\D't %.3fp'\n.sp -1\n", p);
 last_line_thickness = p;
   }
 }


Still testing, though.


___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[G. Branden Robinson]

Update of bug #64285 (project groff):

  Status:   Confirmed => In Progress
 Assigned to:None => gbranden   

___

Follow-up Comment #1:

This will require synchronized changes to grn and pic.  They both contrive
horizontal motions to offset the (stupid) drawing position update imposed by
\D't', so if that's not done, those preprocessors will produce incorrect
output.

I haven't found where pic does this yet (but I can tell from its output).

Here's where grn's code is.


src/preproc/grn/hgraph.cpp:400:  if (linethickness != thick[mode]) {
src/preproc/grn/hgraph.cpp:401:linethickness = thick[mode];
src/preproc/grn/hgraph.cpp:402:printf("\\h'-%.2fp'\\D't %.2fp'",
linethickness, linethickness);




___

Reply to this item at:

  

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

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[G. Branden Robinson]

URL:
  

 Summary: [troff] \D't' (set line thickness) drawing command
alters drawing position
   Group: GNU roff
   Submitter: gbranden
   Submitted: Thu 08 Jun 2023 10:43:26 PM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Incorrect behaviour
  Status: Confirmed
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Thu 08 Jun 2023 10:43:26 PM UTC By: G. Branden Robinson 
Steve Izma [reported
https://lists.gnu.org/archive/html/groff/2023-06/msg00055.html]:


Is it worth pointing out here that \D't n' is not zero-width?
e.g.:

.sp 1i
.po 1i
.ps 12s
.ll 24P
\D'l \n[.l]u 0'
.br
\D't .5p'\D'l \n[.l]u 0'
.br

In fill mode, the second drawing command produces this error:

troff: thick:7: warning [p 1, 1.2i]: can't break line

The troff output:

x T ps
x res 72000 1 1
x init
p1
V84000
H72000
md
DFd
s12000
Dl 288000 0
n12000 0
V96000
H72000
Dt 500 0
Dl 288000 0
n12000 0
x trailer
V792000
x stop

shows that \D't .5p' has a width of 500 units, which is output as
a 500-unit space. For as long as I can remember, I've needed to
use this instead:

\Z'\D't .5p''\D'l \n[.l]u 0'

I'm pretty sure this anomaly has been discussed on the groff list
before, but I don't know of any explanation in the documentation.


As noted in the follow-up, I regressed notice of this in the documentation
(which didn't really treat it as a bug), and within 2 days Steve stumbled
across this issue.

But like "STUPID_DRAWING_POSITIONING" in the source code, it is a bug and we
should fix it.







___

Reply to this item at:

  

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