bugGNU roff - Bugs: bug #65954, [troff] next-generation alignment...

 
 

bug #65954: [troff] next-generation alignment and adjustment control

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Fri 05 Jul 2024 08:08:43 AM UTC
   
 
Category:  Core Severity:  1 - Wish
Item Group:  Feature change Status:  Postponed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 15 Jan 2025 11:37:00 AM UTC, comment #7: 

comment #6:

> comment #4:
> > groff doesn't have `ad` modes pl, pr, pb, and k that neatroff has,
>
> I wouldn't write those off in designing a scalable system; groff's current limitations are not set in stone.  In particular, there are at least two proposals for changing the adjustment algorithm (bug #40716 and bug #65558).


Good point.

> Your email calls mode k "keshideh adjustment (used for Arabic script)"; while I don't know what this script requires, groff does have ambitions to one day support writing directions other than left to right (bug #60060).


See https://en.wikipedia.org/wiki/Keshideh. It's a form of justification used for Arabic script that consists of stretching parts of characters rather than spreading blanks as is done for Latin script.

I am discussing the particulars of resolving this with Ali (neatroff's author); he also supports decoupling the various settings combined in `ad`. If groff has ambitions to support paragraph-at-once adjustment or keshideh justification in the future, it might just as well copy neatroff's approach once it's finalized; I will share details once it's in master. That will probably be more productive than writing here about each step in the design process.

Anonymous
Wed 15 Jan 2025 02:03:23 AM UTC, comment #6: 

comment #4:

> groff doesn't have `ad` modes pl, pr, pb, and k that neatroff has,


I wouldn't write those off in designing a scalable system; groff's current limitations are not set in stone.  In particular, there are at least two proposals for changing the adjustment algorithm (bug #40716 and bug #65558).  Your email calls mode k "keshideh adjustment (used for Arabic script)"; while I don't know what this script requires, groff does have ambitions to one day support writing directions other than left to right (bug #60060).

Dave <barx>
Group Member
Mon 13 Jan 2025 01:59:30 PM UTC, comment #5: 


comment #4:

> comment #3:
> Additionally, request `cl` is added [...]

s/cl/al/

Anonymous
Mon 13 Jan 2025 01:57:58 PM UTC, comment #4: 

comment #3:

> On the email discussion list, onf posted a new proposal and a patch to implement it in neatroff (http://lists.gnu.org/r/groff/2025-01/msg00041.html) so that interested parties can try out the modified syntax in a working troff.


Thanks for copying it here. I've been thinking about it some more since then, and the ability to restore previous value of `ad` in particular really complicates retaining backwards compatibility. Thankfully groff doesn't have `ad` modes pl, pr, pb, and k that neatroff has, so there seems to be a more straightforward way:

Outside compatibility mode, `na` disables justification and `ad` without args enables justification (i.e. `ad b`), with register `.j` being ignored. Nothing changes in compatibility mode. Additionally, request `cl` is added with the exact same behavior as included in the patch, i.e. args are l, c, r, and no argument restores previous value. Alternatively, a new request could be added (`adj` or `ju` or `just`?), which would do the exact same thing, so that `ad` can retain its old functionality and we don't break people's documents.

I can make neatroff behave like this too for others to try, but only if anyone else feels like it's a good idea; I feel like I tend to flood discussion with rushed activity, so I'd rather get your opinions first.

~ onf

Anonymous
Mon 13 Jan 2025 12:15:03 PM UTC, comment #3: 

On the email discussion list, onf posted a new proposal and a patch to implement it in neatroff (http://lists.gnu.org/r/groff/2025-01/msg00041.html) so that interested parties can try out the modified syntax in a working troff.

Dave <barx>
Group Member
Mon 25 Nov 2024 06:52:20 PM UTC, comment #2: 

Robust discussion about this took place on the email list, but it's hard to follow because it's entangled with multiple unrelated topics in lengthy messages.  I'll try to tease out the relevant bits here.  I'm also adding onf to this bug's cc.

onf wrote (http://lists.gnu.org/r/groff/2024-11/msg00103.html): "I don't feel like this fixes anything, honestly."  Then came an example, and an alternate proposal.

Branden replied (http://lists.gnu.org/r/groff/2024-11/msg00105.html): "It's pretty important to me to detangle adjustment from alignment.  Continuing to heap complications on the existing `ad` request doesn't seem like a promising path forward to me."  Elaboration and examples follow.

Based on this discussion, onf wrote a new response to this bug's proposal (http://lists.gnu.org/r/groff/2024-11/msg00121.html) that has received no further response in the 10 days since.  As that's the most recent word on the subject, I paste it here in full.

I have looked at the adjustment/alignment proposal again.

It makes sense, although I disagree with the addition of .adjust.
It seems unnecessary to me given that .fi doesn't accept a boolean
argument either. To me, the changes which allow .ad/.na to be used
just like .fi/.nf are enough.

Given that these changes make .ad finally true to its mnemonic of
"adjust", I would suggest renaming .align to .al because:
  * it matches the naming scheme used with .ad
  * it seems more natural given the arguments are single characters:
    compare .al r with .align r (one would expect .align right)
  * short names make more sense for basic functions that are expected
    to be used often such as adjustment, alignment, filling, and
    various font properties (and all of them currently have them)
  * even many requests added by groff use aggressively shortened
    names (.als instead of .alias being the most salient example),
    so it cannot be argued that long names are somehow preferred

Yes, I know I could do .als al align. It's just that I wish I didn't
have to type that at the top of each document I write in plain troff.

And given how many other basic functions are provided with two letter
requests, I don't think making this one easier to remember for
beginners would be of much value; they will have to remember all the
other ones (or create aliases for them) anyway.


Dave <barx>
Group Member
Wed 13 Nov 2024 03:41:56 PM UTC, comment #1: 

Part of this ready to go but I'm kicking it out to groff 1.25 anyway.

G. Branden Robinson <gbranden>
Group administrator
Fri 05 Jul 2024 08:08:43 AM UTC, original submission:  

Free the users from the surly bonds of `.ad` (with an argument)!


Here's a summary of what I'm pitching, in the style of groff(7).

     .ad        Enable output line adjustment.  Updates \n[.j].
     .ad b      Enable output line adjustment.  Updates \n[.j].
     .ad n      Enable output line adjustment.  Updates \n[.j].
     .ad C      Align output line to left, right, or center as C is "l",
                "r", or "c", respectively.  Updates \n[.j].
     .ad N      Configure output line alignment and adjustment per the
                integer N, which must be a valid value of the .j
                register.
     .na        Disable output line adjustment.  Updates \n[.j].

     \n[.j]         Output line alignment and adjustment encoded as an
                    integer; see .ad and .na.  Do not interpret or
                    perform arithmetic on its value.

(The numerical value of the `.j` register will change under my proposal,
but its semantics are otherwise unaltered: it would continue to work as
it always has.  The warning about not interpreting or performing
arithmetic on its value has been present since groff 1.23, and was, I
understand, folk knowledge among *roff practitioners long before that.)

I'm further considering adding two more registers.

     \n[.adjust]    Output line adjustment enablement (Boolean-valued).
                    See .ad and .na.
     \n[.align]     Output line alignment (string-valued; interpolates
                    "l", "r", or "c".  See .ad.

And I'd be happy to implement two new requests to get people out of the
`ad`/`na`/`\n(.j` quagmire altogether.

     .adjust    Enable output line adjustment.  Its is enabled by
                default.  Updates \n[.j].
     .adjust B  Enable or disable output line adjustment per Boolean
                expression B.  Updates \n[.j].
     .align C   Align output line to left, right, or center as C is "l",
                "r", or "c", respectively.  Updates \n[.j].

Each of these three tiers builds on the previous.  Just the first is
enough to suit my reformist passion, but I think the other two increase
user-friendliness in this area.


The discussion thread started from a claim by Bjarni that I believe to be incorrect (and his underlying model of the formatter's behavior ill-conceived).

The foregoing summary is from my second reply to him.

Earlier in the discussion I mused:


Decisions still to be made:

1.  Whether to expose `.align` and `.adjust(ment)` registers to more
    clearly communicate the information encoded in `.j`.  The former
    would be string-valued, interpolating "l", "c", or "r", and the
    latter a Boolean.

2.  Whether to introduce new `align` and `adjust` requests to manipulate
    these two properties separately.  They still would not be usable in
    portable man pages.

3.  Whether to alter the behavior of the `ad` request, as the attached
    patch contemplates.  Doing so accommodates man page authors' DWIM
    intentions, at some risk to altering the formatting of documents
    that follow `.ad c` or `.ad r` with `.ad`, expecting to restore left
    alignment instead of merely disabling adjustment.  It's not clear to
    me how many such documents actually exist.  I don't think I've ever
    seen one that I didn't write as a test case.

4.  Whether to retain AT&T-compatible `ad` behavior in AT&T
    compatibility mode.  Deciding #3 likely decides this one.


My opinion now is that the answer to all four is "yes".

G. Branden Robinson <gbranden>
Group administrator

 

(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 barx (Posted a comment)
  • -email is unavailable- added by barx
  • -email is unavailable- added by gbranden (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-11-25 barx Carbon-Copy- Added -email is unavailable-
    2024-11-14 gbranden StatusNone Postponed
    2024-11-13 gbranden StatusIn Progress None
    2024-11-11 gbranden DependenciesRemoved dependency from bugs #65099 -
    2024-08-22 gbranden StatusNone In Progress
        Assigned toNone gbranden
    2024-07-05 gbranden Dependencies- bugs #65099 is dependent

    Back to the top

    Powered by Savane 3.14-430a.
    Corresponding source code