comment #14:

> The formatter has no conception of columns.  There is only a line length.

Yeah, I was speaking in shorthand, but apparently shortened too much.  By "column" I meant it would calculate the center between the page offset + indentation and the page offset + line length, in contrast to calculating the center between the two page borders.  When there is one column and the margins on both sides are the same, these come out to the same value.  Notably, -me's default page layout (until the recent
commit ac6e764a) had unequal margins, so the distinction mattered there.  And of course any user can set up a single column of text with unequal margins, whereupon groff not documenting how it defines the center becomes relevant.

comment #11:

>   Similar "subject" is also discussed in bug #60731

Yes, that bug has been cited here a few times, going back to comment #1.

>   It is the job of '.ce' to ignore the right margin,
> that is, not to break the input line in two pieces for the output line.

Whether .ce should break input lines as a general rule is the topic of #60731; the bug you're currently reading is only about the inconsistency in breaking behavior given specific inputs.  This inconsistency needs to be dealt with regardless of what #60731 decides groff's general breaking behavior should be.

So if you want to make the case that groff should follow AT&T troff .ce behavior, #60731 is the place to do that.

comment #12:

> The request has to know where the "right margin" is (what the
> line length is) to know where the centerline of the page is.

Whether that's true depends on whether text is being centered within the current column or on the page -- a distinction that actually seems to not be documented in the info manual.  (This should probably be a separate bug report.)

> This ticket should be retitled.  Dave, any suggestions?

I put a suggestion in the Summary that seems to be to reflect what this ticket is about, but not being certain what shortcoming you were noticing in the original Summary, I don't know whether this addresses it.

  Similar "subject" is also discussed in bug #60731

  It is the job of '.ce' to ignore the right margin,
that is, not to break the input line in two pieces for the output line.

  The example in groff.texi ("info groff") is misleading in two aspects

1) The output does not conform to the provided description.

2) The input lines do not conform to the purpose of the '.ce' request
(wrong layout of the input lines).

  A better example could be

.nr length (u;40*\w'0')
.nr sp (u;9*\w'0'))
.ll \n[length]u
.ad b\" default value
.fi\" default value
1234567890123456789012345678901234567890
\h'\n[sp]u'1\h'\n[sp]u'2\h'\n[sp]u'3\h'\n[sp]u'4
.de FR
This is a small text fragment
that shows the differences
between the '.ce' and
the '.ad c' requests.
..
.ce 9999\" from s.tmac
.FR
.ce 0

.ad c
.FR
.pl \n(nlu

N.B.  Mentioning the purpose of requests could aid with the right use
of them, if not obvious from the description of what they are doing.

comment #8:

> comment #7:
> > This also makes sense as centering and filling are incompatible
> > goals.
>
> They aren't conceptually; this

> $ printf '.ce 2\nHello,\nworld!\n' | nroff | cat -s
>                              Hello,
>                              world!

> could have just as easily been designed to output

>                          Hello, world!

> but no roff ever written fills input lines while .ce is active, so the fact that it could have been done another way is a moot point.

Right.  Filling and centering together are otherwise known as ".ad c".

I think Bjarni is right that fill mode and the `ce` request are mutually exclusive, unless we can imagine some `ce`-with-filling variant that is useful and more easily implemented in the formatter than with some specialized macro.

> Is the purpose of this change to require the user to explicitly disable fill mode before calling .ce?  I disagree with that change,

I do too, unless we can contrive some way .fi+.ce can populate output lines that is useful, tractable to implement, and not duplicative of `.ad c`.

Right now my thinking is that fill mode plus `ce` is either not meaningful for not worthwhile.  (This is not true of the superficially similar `rj`.)  The formatter should therefore quietly suspend fill mode while counting `ce` lines, and restore it (if it was active) when it runs out of lines to center.

  The documentation in CSTR#54 and in Heirloom
(https://heirloom-doctools/doc/troff/doc.ps) are silent about fill
mode, but one can deduce from the text, that neither filling nor
breaking of input lines is done.

  This also makes sense as centering and filling are incompatible
goals.

  Thus the groff code does not do the sensible thing.

  The variable "was_centered" is not used in the current subroutine
"possible_break_line".


####

src/roff/troff/env.cpp: possibly_break_line: return at once, if lines
 are to be centered and fill mode is active

  Lines to be centered should neither be filled nor broken.
This shows a defect in the input file's layout.

####

  Line numbers might be different.

--- src/roff/troff/env.cpp        2023-04-15 22:05:43.000000000 +0000
+++ ../new-groff/src/roff/troff/env.cpp        2023-04-15 21:49:42.000000000 +0000
@@ -2119,6 +2127,12 @@ void environment::possibly_break_line(in
   int was_centered = center_lines > 0;
   if (!fill || current_tab || current_field || dummy)
     return;
+  if (was_centered && fill) {
+//  Centered lines should not be broken and not in fill mode
+//    warning(WARN_BREAK,
+//        "centering (.ce) and filling (.fi) are incompatible goals");
+    return;
+  }
   while (line != 0
          && (forced
              // When a macro follows a paragraph in fill mode, the

####

Provided input file "ce.roff" with default .fi and .ad b.

.ll 4i
.ad b\" default by me is .ad l
.fi
.ce 100
This is a small text fragment that shows the differences
between the `.ce' (with and without `.nf`) and the `.ad c' requests.
.ce 0
.sp
.nf
.ce 100
This is a small text fragment that shows the differences
between the `.ce' (with and without `.nf`) and the `.ad c' requests.
.ce 0
.sp
.fi
.ad c
This is a small text fragment that shows the differences
between the `.ce' (with and without `.nf`) and the `.ad c' requests.
.pl \n(nlu

####:

Output from "test-nroff -b -ww ce.roff":

This is a small text fragment that shows the differences
between the `.ce' (with and without `.nf`) and the `.ad c' requests.

This is a small text fragment that shows the differences
between the `.ce' (with and without `.nf`) and the `.ad c' requests.

This is a small text fragment that shows
the differences between the `.ce' (with
 and without `.nf`) and the `.ad c' re-
                quests.

When filling is enabled and `ce` is used, not only does automatic breaking still take place in spite of no filling proper taking place, but adjustment does too!

You just need an example that reveals it.

$ cat ATTIC/ce2.roff
.de FR
Text can be centered with `.ce' (optionally with `.nf'
to suppress automatic breaks) or with `.ad c'.
..
.ll 4i
.ce 1000
.FR
.ce 0

.nf
.ce 1000
.FR
.ce 0
.fi

.na
.ce 1000
.FR
.ce 0

.ad c
.FR
.pl \n(nlu
$ nroff -Tascii ATTIC/ce2.roff
Text can be centered with `.ce' (option-
            ally with `.nf'
to suppress automatic  breaks)  or  with
                `.ad c'.

Text can be centered with `.ce' (optionally with `.nf'
to suppress automatic breaks) or with `.ad c'.

Text can be centered with `.ce' (option-
            ally with `.nf'
to suppress automatic breaks) or with
                `.ad c'.

Text can be centered with `.ce' (option-
 ally with `.nf' to suppress automatic
        breaks) or with `.ad c'.

Count the spaces in the first exhibit.

to suppress automatic  breaks)  or  with

This does not seem useful; if you add inter-word spaces until the line reaches the length limit, it is not distinguishable from centering.

Also, why is the first output line generated from the input line beginning with "to suppress" not centered in the third `FR` call's output?

Presumably some combinations were not checked long ago which is why the bug in comment #0 and this/these escaped notice.  It's possible they're all even the same bug.

If not, I'll spin this/these out into as many new tickets as are necessary.

It doesn't take a spirit medium to see regression tests in the future.

Given the input file of comment #2, Heirloom nroff breaks none of the centered lines.  Its output:

12345678901234567890
Some  line with long
singleword
Some line with long singleword
Some line with long singleword
Some line with longe singleword
Some line with longer singleword

Someone with easy access to one of the old Unix simulators can determine whether the above reflects AT&T nroff behavior (it probably does, as Heirloom is a derivative of that codebase), but the upshot is that groff seemingly does not behave the way it does in order to conform to some historical implementation.

You can see the bug in nroff output too; just edit the example input file to change the line length from 2i to 38n.  The terminal output from this (using groff 1.23.0.rc1) is:

some  text  some  text  some text some
text some text  some  text  some  text
some  text  some  text  some text some
text some text

          some centered text

some text some  text  some  text  some
text  some  text  some  text some text
some text some  text  some  text  some
text some text

quite a bit more centered text in this case

some  text  some  text  some text some
text some text  some  text  some  text
some  text  some  text  some text some
text some text

so, quite a bit more centered text  in
              this case

some  text  some  text  some text some
text some text  some  text  some  text
some  text  some  text  some text some
text some text

The line beginning with "quite," which spills over the right margin, is what this bug was originally opened to report.  But bug #60731 raises the question of whether the actual bug above is in the output of the second or the third .ce call.  One of them seems to be wrong, since they handle the same situation (input longer than the requested output line) differently (one breaking the line, one overflowing the line length).