bugGNU roff - Bugs: bug #46914, breaking behavior inconsistent...

 
 

bug #46914: breaking behavior inconsistent within a .ce block

Submitter:  Dave <barx>
Submitted:  Sun 17 Jan 2016 01:06:09 AM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 30 Apr 2023 02:26:58 PM UTC, comment #15: 

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.

Dave <barx>
Group Member
Sun 30 Apr 2023 12:39:12 PM UTC, comment #14: 


comment #13:

> 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.


These might in fact turn out to be the same issue given the point below...

> 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.)


The formatter has no conception of columns.  There is only a line length.  See the example in the groff Texinfo manual for how to write your own columnation macros.

Columns are achieved by manipulating the line length and page offset, making the former smaller and the latter (progressively) larger, and by `mk` marking a vertical location on the page and `rt` returning to it to advance to the next column (at which point the page offset is increased).

> > 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.


I'm still at sea too.  Oh well.

I'm sticking with my stance in comment #9 until given a reason to alter it.

G. Branden Robinson <gbranden>
Group administrator
Sun 30 Apr 2023 02:10:09 AM UTC, comment #13: 

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.

Dave <barx>
Group Member
Sat 29 Apr 2023 07:20:36 PM UTC, comment #12: 


comment #11:

>   Similar "subject" is also discussed in bug #60731
>
>   It is the job of '.ce' to ignore the right margin,


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

This ticket should be retitled.  Dave, any suggestions?

G. Branden Robinson <gbranden>
Group administrator
Sat 29 Apr 2023 07:16:00 PM UTC, comment #11: 

  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.

Bjarni Ingi Gislason <bjarniig>
Mon 24 Apr 2023 01:01:38 AM UTC, comment #10: 

s/for not worthwhile/or not worthwhile/

G. Branden Robinson <gbranden>
Group administrator
Mon 24 Apr 2023 01:00:58 AM UTC, comment #9: 


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.

G. Branden Robinson <gbranden>
Group administrator
Sun 23 Apr 2023 09:38:26 PM UTC, 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.

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


(For anyone else trying to find this function, its correct name is possibly_break_line.)  possibly_break_line() does pass was_centered as the third argument in its call to output_line(). I guess you mean was_centered isn't used directly by possibly_break_line() itself?

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


Is the purpose of this change to require the user to explicitly disable fill mode before calling .ce?  I disagree with that change, but I might also be misunderstanding you, because your later ce.roff calls .ce with fill mode active.

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


I don't follow your meaning here.  Are you talking about a specific input file, and if so, which one?  Or do you generally mean input files that call .ce while filling is active?

Dave <barx>
Group Member
Sun 16 Apr 2023 12:12:15 AM UTC, comment #7: 

  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.


Bjarni Ingi Gislason <bjarniig>
Fri 31 Mar 2023 05:33:39 PM UTC, comment #6: 

comment #5:

> 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!


Good catch!  Had I been more eagle-eyed, I would have noticed that in the final centered block in the output posted in comment #1.

But it's clearly not always happening, or the first block would be output as:

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


It looks like it happens only on input lines that are also being broken, and thence on output lines that appear before the break--which is not as unreasonable, as such lines are usually at or near full measure anyway.

But the "usually" is an important caveat, because it's easy to contrive a counterexample:

$ cat ce3.roff
.ll 36n
.nh
.ce
I often say "supercalifragilisticexpialidocious" despite its atrocious sound.
.pl \n(nlu
$ nroff ce3.roff
I              often             say
"supercalifragilisticexpialidocious"
    despite its atrocious sound.

But even in the much milder case you first spotted, I agree the adjustment serves no useful purpose: centering is already a form of adjustment, and that should take precedence since it's the form the user explicitly requested.

Still... case 3 in comment #1 case is an interesting illustration of the occasional usefulness of the interword adjustment in a centered line, at least on a terminal, where spaces are a fixed width.  (This will never be true in typesetting, where spaces can be as thin as need be.)  In a centered line where only one space need be added, the options are the beginning, the middle, and the end, and this is the one case where the middle actually looks best; neither other option would make the line "look" as centered.

But I'm skeptical that's something that can be determined algorithmically in a reliable way.  In most cases, I think turning off adjustment on centered lines will give the best results, so that might be the best approach to take across the board.

Dave <barx>
Group Member
Thu 30 Mar 2023 09:07:08 PM UTC, comment #5: 

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.

G. Branden Robinson <gbranden>
Group administrator
Thu 30 Mar 2023 06:36:31 PM UTC, comment #4: 

comment #1:

> 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).


Further analysis in yonder 60731 seems to indicate that the breaking is the intended behavior (my assumption when I initially reported this).

Dave <barx>
Group Member
Sun 20 Feb 2022 04:27:47 AM UTC, comment #3: 

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.

Dave <barx>
Group Member
Fri 18 Feb 2022 02:05:17 AM UTC, comment #2: 

  The line is only split, if a space is after a non-space in the
excessive part of the line.

  Script:

.pl 20v
.fam C
.\".ll 20u*\w' 'u
.ll (u;20*\w' ')
.ad b\" (usually) default
12345678901234567890
Some line with long singleword\"
.ce 4
Some line with long singleword\" No break
Some line with long singleword \" With a break
Some line with longe singleword\" No break
Some line with longer singleword\" With a break

  Result (test-nroff) :

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


Bjarni Ingi Gislason <bjarniig>
Sat 05 Jun 2021 09:16:03 AM UTC, comment #1: 

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).

Dave <barx>
Group Member
Sun 17 Jan 2016 01:06:09 AM UTC, original submission:  

I see this bug in groff 1.22.2.

A line centered with .ce can sometimes extend past the right margin.  Adding enough text eventually causes the line to be broken so it correctly stays within the margins.  The bug is illustrated in the second centered example below.

.ll 2i
some text some text some text some text some text some text
some text some text some text some text some text some text
.sp
.ce
some centered text
.sp
some text some text some text some text some text some text
some text some text some text some text some text some text
.sp
.ce
quite a bit more centered text in this case
.sp
some text some text some text some text some text some text
some text some text some text some text some text some text
.sp
.ce
so, quite a bit more centered text in this case
.sp
some text some text some text some text some text some text
some text some text some text some text some text some text

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by bjarniig (Posted a comment)
  • -email is unavailable- added by bgarrigues (Updated the item)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-04-30 barx Summary.ce sometimes ignores right margin breaking behavior inconsistent within a .ce block
    2017-09-01 bgarrigues CategoryNone Core

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code