bugGNU roff - Bugs: bug #62814, [PATCH] consolidate or distinguish...

 
 

bug #62814: [PATCH] consolidate or distinguish tty.tmac and tty-char.tmac

Submitter:  Dave <barx>
Submitted:  Tue 26 Jul 2022 02:19:42 AM UTC
   
 
Category:  Macro package - others/general Severity:  1 - Wish
Item Group:  Feature change 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

Wed 16 Oct 2024 06:07:26 PM UTC, comment #12: 

I replied (http://lists.gnu.org/r/groff/2024-09/msg00082.html) to Branden's email; the pertinent-to-this-bug portion of the reply (slightly recast to utilize savannah's markup) is pasted below.



> A person who has composed a table entry or any portion of a document
> where filling has off, and employed a special character like \(mo or
> \(*e or \(ca, is likely working from an expectation that whatever gets
> typeset at that place in the text is not going to be wider than, say,
> one em.


A fair point.  But the alternative, on a terminal where tty-char.tmac is not used, is a "special character not defined" warning and these characters missing from the output altogether.  (None of them are defined in tty.tmac.)  But yes, omitting those characters from the output does keep them from being wider than 1 em...

> 2.  a user's preference of whether the "visual" vs. "semantic" fallback
>     character definitions are used.


But that's not the choice the user is presented with.  As comment #0 notes, "both files contain (disjoint) sets of tty fallback character definitions."  So the choices are "semantic" fallbacks vs. missing characters.

The sets being disjoint was true when I wrote that in 2022.  It's not strictly true as of last month's commit c9b3c99a6, which moved a number of alphabetic characters with diacritical marks from fallbacks.tmac to tty.tmac, giving tty.tmac and tty-char.tmac slightly different fallback definitions for these characters.  But even this overlap has little bearing on the points above: both versions of each of these fallbacks is a net 1 en wide; both versions are defined with the \z escape to overstrike two characters, just with slightly different characters in each case.  (If anything, these common elements between the two files should be removed, and one set of overstruck characters be considered the canonical terminal fallback.  As bug #62983 points out, whatever terminal you're using is unlikely to support overstriking anyway.)

Dave <barx>
Group Member
Tue 24 Sep 2024 06:20:29 AM UTC, comment #11: 

Branden replied to comment #10 off-savannah; see http://lists.gnu.org/r/groff/2024-09/msg00063.html

Said reply points out shortcomings to the patch of comment #9.  Nonetheless, I feel the patch is an improvement over the status quo (which suffers the same shortcomings), so I leave the patch on offer until someone does the slightly heavier lifting required to address those shortcomings.

Dave <barx>
Group Member
Sun 22 Sep 2024 10:40:42 PM UTC, comment #10: 

Branden wrote in bug #66233:

> It feels to me more like the alternation of renderings as
> "tty-char" does should be controlled by a device-specific
> register instead of by selective load of a macro package that
> nroff defaults to performing.  The latter technique messes up
> nroff's orthogonality, in my opinion.


Ingo opposed using a register in comment #3, hence I wrote my proposed patch to make grotty load tty-char.tmac unconditionally (not just when the nroff script is used to launch it), but in a way that allows it to be easily disabled if desired, per subsequent discussion with Ingo.  I'm not married to this approach, but there has thus far been no objection to it, and I do strongly agree with his point from comment #1: "i think most users would be better served by loading [tty-char.tmac] by default."

I'm not sure if Branden's remarks constitute an objection, because I'm not sure what orthogonality is being messed up, and thus whether or not that applies to my proposal.

Dave <barx>
Group Member
Sat 24 Aug 2024 10:09:19 PM UTC, comment #9: 

Patch rebased to git HEAD.  Remarks in comment #7 still apply.

(file #56382)

Dave <barx>
Group Member
Tue 20 Aug 2024 07:27:21 AM UTC, comment #8: 

Commit 32393c7e3 invalidated this patch.  Will post an update in the near future.

Dave <barx>
Group Member
Tue 18 Jul 2023 06:35:59 PM UTC, comment #7: 

Attached is a patch which implements the fix proposed in comment #6.

I tweaked some of Ingo's wording from comment #1 to include in comments at the top of tty-char.tmac.  (Some of the points he covered were already in comments there.)

I did not include Ingo's instructions from comment #5 concerning how to locally edit system tmac files if one lacks root access.  As he points out, this is documented elsewhere, but if developers think it's worth providing a pointer to that information in a place users might need it as a courtesy, I'll modify the patch.

(file #54936)

Dave <barx>
Group Member
Sun 13 Nov 2022 12:42:07 AM UTC, comment #6: 

Heh, I see James Clark anticipated this bug report back in groff 1.06, adding these lines to tty.tmac (then named tmac.tty) in commit b04d345e:

.\" If you want the character definitions in tmac.tty-char to be loaded
.\" automatically, remove the `\"' from the next line.
.\"do mso tmac.tty-char

These lines remain, almost unchanged, today.  So all it would take to resolve this bug is to reverse their sense, uncommenting the "mso" line and editing the comment to instruct users how to not include tty-char automatically.

Alternately, Ingo has addressed my concerns with the solution he proposed in comment #3, so that'd be another way to go.

In either case, it might also be good to incorporate Ingo's lucid explanation in comment #1 of the difference between the two files' goals into comments in the files themselves.

Dave <barx>
Group Member
Tue 02 Aug 2022 03:09:40 PM UTC, comment #5: 

comment #4:

> While not as often a problem in practice these days, the troffrc file is not editable by ordinary users, only by root.


As documented in the GNU troff(1) manual, that's trivial to solve for advanced users:

Copy troffrc to ~/tmac/troff, edit it as desired, then use "troff -M ~/tmac" or set GROFF_TMAC_PATH=~/tmac in the envoronment.

Ingo Schwarze <schwarze>
Group Member
Tue 02 Aug 2022 07:48:34 AM UTC, comment #4: 

comment #3:

> Please don't overengineer it by defining registers and adding .if statements


The advantage of an .if block, even if the condition is never used by any user, is that (assuming conventional code indentation) it very obviously visually groups together all the definitions of a certain classification.  (This is less a consideration if the two groups are kept in separate files, also a valid choice.)

> So power users who don't want it by default can simply comment it out


While not as often a problem in practice these days, the troffrc file is not editable by ordinary users, only by root.

Dave <barx>
Group Member
Mon 01 Aug 2022 10:53:33 AM UTC, comment #3: 

Please don't overengineer it by defining registers and adding .if statements and the like.

tty.tmac is called from troffrc.
One simple idea would be to just call tty-char.tmac from the same place.
So power users who don't want it by default can simply comment it out and call -m tty-tmac manually in those cases where they do want it.

Ingo Schwarze <schwarze>
Group Member
Mon 01 Aug 2022 12:04:29 AM UTC, comment #2: 

comment #1:

> So i think most users would be better served by loading it by default.


That's my gut feeling, though as someone who doesn't use most of this file's character palette, I defer to the judgment of more experienced users.  In general it just seems more user-friendly to render characters in a suboptimal way than to throw warnings and leave those spots empty.

> If you want to be extra careful, you could leave these in
> their own file though, such that people who want to scutinize a
> document for characters that render badly to ASCII can more
> easily do so by disabling loading the file in one way or another.


Giving power users that option would be good.  One possible mechanism would be wrapping the lower-quality definitions in an .if block, in such a way that a user defining a certain register on the command line would cause that block to be skipped.  Then it wouldn't matter as much which file they lived in.

There could be separate registers to control each set of fallbacks, in fact, in case a user wants to disable them all, such as for a testing scenario of the type Branden alluded to in the email thread.

Dave <barx>
Group Member
Sun 31 Jul 2022 05:31:34 PM UTC, comment #1: 

Arguably, the definitions in tty.tmac are of such a high quality that any user of terminal output wants to use term unconditionally, and warnings about characters in the input document that need any of these fallbacks would make little sense.

Most of the fallbacks in tty-char.tmac, on the other hand, are arguably desperate attempts to somehow render the respective characters even when good renderings don't really exist, and most are of dubious or even poor quality.  Some users might possibly prefer warnings about unavailable characters to poor or cryptic renderings, and hence decide to not load tty-char.tmac, in particular if they consider changing the input file to more gracefully render to ASCII.

That said, while i see why some users might want to not load tty-char.tmac for some uncommon purposes, personally i never felt a need to suppress its loading for my purposes.  Quite to the contrary, it happened several times that i simply forget loading it, resulting in badly degraded output.  So i think most users would be better served by loading it by default.

If you want to be extra careful, you could leave these in their own file though, such that people who want to scutinize a document for characters that render badly to ASCII can more easily do so by disabling loading the file in one way or another.

Ingo Schwarze <schwarze>
Group Member
Tue 26 Jul 2022 02:19:42 AM UTC, original submission:  

As discussed in the thread starting at http://lists.gnu.org/r/groff/2022-07/msg00041.html, it is unclear what utility is served by having tmac/tty-char.tmac loaded in different circumstances from tmac/tty.tmac.

troffrc unconditionally loads tty.tmac when the postprocessor is grotty--congruent with how it handles other postprocessors--so it's only tmac/tty-char.tmac that might not be loaded for some terminal output.

It seems that these files should always be loaded in tandem (whether by loading both files, or combining the files' content into one), or a use case for using tty.tmac without tmac/tty-char.tmac documented.

Presently, both files contain (disjoint) sets of tty fallback character definitions.  As Branden and I agreed in the email thread, all fallback character definitions should live in the same place, wherever ends up making the most sense for that.

For modularity, tty-char.tmac could continue to be its own file for this purpose, separating these definitions from other terminal-setup tasks that tty.tmac performs.  But if so, and absent a demonstrable (and preferably documented) use case for not loading these definitions, it seems tty.tmac ought to unconditionally include tty-char.tmac.

(One item from the email discussion has been resolved: Branden wrote "I think that definition [of "\[sd]"] in tty-char.tmac should be dropped," and this was done in commit 175c42d7.)

Dave <barx>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #56382:  62814.revised.patch added by barx (2KiB - text/x-diff - updated; still see comment #7)
file #54936:  62814.patch added by barx (2KiB - text/x-diff - see comment #7)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by schwarze (Posted a comment)
  • -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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-08-24 barx Attached File- Added 62814.revised.patch, #56382
    2023-07-18 barx Attached File- Added 62814.patch, #54936
        Summaryconsolidate or distinguish tty.tmac and tty-char.tmac [PATCH] consolidate or distinguish tty.tmac and tty-char.tmac

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code