[bug #60731] undocumented difference in .ce behavior between groff and traditional troff

2023-04-19 Thread Dave
Follow-up Comment #7, bug #60731 (project groff):

[comment #0 original submission:]
> The Texinfo manual says .ce centers text "without filling" ...
> 
> On the other hand, the description of .ce in section 4.2 of
> CSTR #54 does not mention filling,

My second statement above is misleading: while strictly true that CSTR#54's
.ce description does not mention "filling" by that name, it does say "A break
occurs after each of the N input lines," which clearly communicates that no
filling is done.  (Bjarni set me straight on this with his latest comment over
in bug #46914.)

Thus the first statement above is groff's rewording of this longstanding
principle.  As there's no controversy over any troff's filling behavior within
a .ce block, this is an academic point regarding this bug, but I want to set
the record straight, and/or scold my past self for the misreading.


___

Reply to this item at:

  

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




[bug #60731] undocumented difference in .ce behavior between groff and traditional troff

2023-04-14 Thread G. Branden Robinson
Update of bug #60731 (project groff):

  Status: In Progress => None   

___

Follow-up Comment #6:

This is not in progress until I figure out bug #46914.


___

Reply to this item at:

  

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




[bug #60731] undocumented difference in .ce behavior between groff and traditional troff

2023-03-30 Thread G. Branden Robinson
Follow-up Comment #5, bug #60731 (project groff):

No, I won't.  That's a different project's bug.

I mean bug #46914.  >:-|


___

Reply to this item at:

  

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




[bug #60731] undocumented difference in .ce behavior between groff and traditional troff

2023-03-30 Thread G. Branden Robinson
Follow-up Comment #4, bug #60731 (project groff):

Uh-oh.  The story gets worse.  I'll follow up in bug #49614.


___

Reply to this item at:

  

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




[bug #60731] undocumented difference in .ce behavior between groff and traditional troff

2023-03-30 Thread G. Branden Robinson
Update of bug #60731 (project groff):

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

___

Follow-up Comment #3:

Back in my court; updating Status and Assigned to.


___

Reply to this item at:

  

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




[bug #60731] undocumented difference in .ce behavior between groff and traditional troff

2023-03-30 Thread Dave
Update of bug #60731 (project groff):

  Item Group: Incorrect behaviour => Documentation  

___

Follow-up Comment #2:

[comment #1 comment #1:]
> presumably it's a sprinkle of DWIM behavior for .ce.

This seems eminently reasonable (other than it occasionally not working
correctly, but we can leave bug #46914 for another day).

> I'm inclined to consider this a documentation issue;

Given the results of your peek under the hood, I agree.  Updated the Item
Group.

> You can try it out yourself.  It seems to have been modified
> only insofar as to make it buildable on modern Unix systems
> without too many screams from the compiler.

Thanks for the pointer!  Now I just have to ponder the question "Exactly how
many troffs do I need on my system?"


___

Reply to this item at:

  

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




[bug #60731] undocumented difference in .ce behavior between groff and traditional troff

2023-03-30 Thread G. Branden Robinson
Update of bug #60731 (project groff):

  Status:None => Need Info  
 Assigned to:None => barx   

___

Follow-up Comment #1:


> The Texinfo manual says .ce centers text "without filling" but is silent on
breaking.

It seems groff's `ce` request implements a procedure that is used nowhere else
in the formatter, such that lines are automatically broken when they reach the
output line length but _not_ filled.

This would look bad in conventional left-adjusted text (like reading emails in
an MUA window too narrow for the text, and which wraps lines crudely), but
presumably it's a sprinkle of DWIM behavior for .ce.

I'm inclined to consider this a documentation issue; to get authentic AT
troff output, you need to explicitly turn off filling when using the `ce`
request.


$ cat ATTIC/ce.roff
.ll 4i
.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
$ groff -Tascii ATTIC/ce.roff # 1.22.4, no difference in Git
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.
$ DWBHOME=~/dwb ~/dwb/bin/nroff ATTIC/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'
   requests.


That the first two specimens of these three produce distinct output in groff
but not in DWB troff suggests to me that this behavior is deliberate.

By the way, you might have noticed that I tested with DWB troff rather than
Heirloom.  This is because, to my knowledge, DWB 3.3 troff is the origin of
Heirloom troff; the latter added many features.

You can try it out yourself.  It seems to have been modified only insofar as
to make it buildable on modern Unix systems without too many screams from the
compiler.


$ git remote -v
origin  https://github.com/n-t-roff/DWB3.3.git (fetch)
origin  https://github.com/n-t-roff/DWB3.3.git (push)


Tossing to you for feedback.


___

Reply to this item at:

  

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




[bug #60731] undocumented difference in .ce behavior between groff and traditional troff

2021-06-05 Thread Dave
URL:
  

 Summary: undocumented difference in .ce behavior between
groff and traditional troff
 Project: GNU troff
Submitted by: barx
Submitted on: Sat 05 Jun 2021 01:35:57 AM CDT
Category: Core
Severity: 2 - Minor
  Item Group: Incorrect behaviour
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

= Preamble =

It's not clear to me whether this is a behavior bug or a documentation
omission.  That is, I don't know whether groff's authors deliberately made
this .ce behavior different from historical troff and merely forgot to
document it, or whether they intended .ce to work as it historically did.  I'm
filing it as "Incorrect behaviour" because I had to pick one or the other, but
it could as easily be switched to "Documentation."

I'm using Heirloom troff as the standard bearer here for "traditional troff,"
though I realize that's a simplification.  But it's what I have access to, and
it does demonstrate a notable difference.

= Documentation =

The Texinfo manual says .ce centers text "without filling" but is silent on
breaking.  

On the other hand, the description of .ce in section 4.2 of CSTR #54 does not
mention filling, but does (almost) say that no breaking occurs: "If the input
line is too long, it will be left adjusted."

= Behavior =

To see the behavioral difference between groff and Heirloom troff, run the
example code from the .ce section of the latest (as of this writing, commit
16a0fc88) version of the Texinfo manual. 
(http://git.savannah.gnu.org/cgit/groff.git/tree/doc/groff.texi?id=16a0fc88#n7128
links directly to this example.)  This example is designed to show the
difference in filling behavior between .ce and ".ad c", but also shows the
difference in breaking behavior between groff and Heirloom.

Groff (1.23.0.rc1) produces the output (in nroff) the manual says it does,
showing that .ce input is broken but not filled:


This is a small text fragment that shows
the differences
between the `.ce' and the `.ad c' requests.

This is a small text fragment that shows
 the differences between the `.ce' and
 the `.ad c' requests.



In Heirloom nroff, however, .ce input is neither broken nor filled.


This is a small text fragment that shows the differences
between the `.ce' and the `.ad c' requests.

This is a small text fragment that shows
 the differences between the `.ce' and
 the `.ad c' requests.



The traditional nonbreaking behavior does also mean that the line overruns the
requested line length (as would any text where breaking is explicitly
disabled).

The behavior difference holds for typeset output as well, though the line
length in the example needs to be reduced (from 4i to, say, 2i) to see the
difference.




___

Reply to this item at:

  

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