bugGNU roff - Bugs: bug #56015, [PATCH] [grotty] should handle...

 
 

bug #56015: [PATCH] [grotty] should handle bullet character more intelligently

Submitter:  Jeff Conrad <jeffconrad>
Submitted:  Thu 28 Mar 2019 06:12:09 AM UTC
   
 
Category:  Driver grotty Severity:  3 - Normal
Item Group:  Rendering/Cosmetics Status:  Confirmed
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 13 Mar 2024 04:49:52 AM UTC, comment #9: 

comment #5:

> rely on ".if c" detecting characters' availability--which, as
> Branden notes in his novella-length comment in bug #59962,


[Specifically, its comment 6, and more specifically, that comment's footnote and its antecedent.]

> doesn't seem to do what you'd want in grotty.  A simple test
> seems to bear this out:


A resolution to bug #65403 will clarify what ".if c" does in grotty, but the simple test I offered here is flawed, as Branden explains in comment 3 over in #65403.

Dave <barx>
Group Member
Sat 27 Jan 2024 05:57:33 AM UTC, comment #8: 

If we're all in agreement about dropping \[pc] and \[md] as bullet fallbacks:

  • Since the two ".if c" calls setting them up don't do what's expected anyway, it seems that the code block Jeff quoted can be ripped out of tty.tmac wholesale.
  • Comment #2 posits that .fchar is the correct mechanism for handling this situation.  While it has issues as well, it's used to define a plethora of other fallback characters in tty.tmac, so if .fchar is deemed inadequate as a mechanism to define grotty fallbacks, that issue goes far beyond the bullet, and this bug is limited to the bullet's rendering.


So what should be the fallback on terminals where no bullet is available?

Since few if any modern terminal emulators support overstriking (see comment 1 in bug #62983), and grotty output is far likelier to be put on a screen than on a printer, I think this fallback shouldn't involve overstriking, which rules out an overstruck "o" and "+", which is what tty.tmac currently defines (once the aforementioned code block is removed) and is one of Jeff's suggestions.

That leaves the asterisk as the one idea that everyone in this thread can get behind: Jeff, Branden, and I have all endorsed it (respectively in the original submission, comment #1, and comment #5).

In light of all the above, I submit the following patch for feedback.

diff --git a/tmac/tty.tmac b/tmac/tty.tmac
index 2a28a7dd2..0ebd77a2c 100644
--- a/tmac/tty.tmac
+++ b/tmac/tty.tmac
@@ -8,15 +8,7 @@
 .
 .po 0
 .
-.if !'\*[.T]'utf8' \{\
-.  ie c\[pc] \
-.    tr \[bu]\[pc]
-.  el \
-.    if c\[md] \
-.      tr \[bu]\[md]
-.\}
-.
-.fchar \[bu] \z+o
+.fchar \[bu] *
 .fchar \[14] 1/4
 .fchar \[12] 1/2
 .fchar \[34] 3/4


Dave <barx>
Group Member
Fri 26 Jan 2024 11:32:15 PM UTC, comment #7: 

Jeff and I agree that \[pc] and \[md] are both poor choices for a bullet.  Branden leads off comment #1 with "I'm a +1 on this" but then proposes a code snippet designed to replace the bullet (if none exists) with, in order of preference, \[pc], \[md], or asterisk, two of which Jeff explicitly opposed in his initial report.  (I say "designed to" rather than "does" because we now know ".if c" tests do nothing useful in grotty contexts.  But that's a resolvable coding issue.)  So Branden, can you clarify whether you're willing to take \[pc] and \[md] out of consideration as replacement bullet characters?

Dave <barx>
Group Member
Fri 26 Jan 2024 08:53:33 PM UTC, comment #6: 

Branden put this bug in Need Info status with comment #2, presumably based on his stated need to research the history of the change cited in that comment.  That history was unveiled a couple months later in comment #3, and if any further info is required, it's not clear what it is.

As comment #5 notes, the two ".if c" statements are useless in tty.tmac.  But these long predate the comment #2-referenced commit: the first dates back to James Clark's creation of the file in commit b04d345ed in 1992, and the second to Werner's commit fbd6cbb8a in Apr 2000.  The comment #2-referenced commit merely wrapped these conditionals in a further test for non-UTF8 terminals, the purpose of which I think is clear from the associated email thread linked in comment #3.  But this additional test is not the source of the issue Jeff Conrad is reporting; if anything, this additional test keeps that issue from being more widespread.

Dave <barx>
Group Member
Tue 11 May 2021 06:52:33 AM UTC, comment #5: 

comment #4:

> I can't say I really understand the reasoning in the logic
> of the original or as modified.


Nor I.  But at least our understanding circa 2021 is recorded here for future generations to look back on and shake their heads at.

Jeff's one misstatement aside (he calls the translation "unconditional" when in fact it's wrapped in a !utf8 condition), I agree with his point that \[pc] and \[md] are both poorer substitutions for \[bu] than an asterisk, or even a lowercase o without the overstrike.  So I would remove \[pc] and \[md] from consideration entirely, and use either a real bullet or some ASCII replacement, probably *.

The proposed code snippets in comment #0 and comment #1 both rely on ".if c" detecting characters' availability--which, as Branden notes in his novella-length comment in bug #59962, doesn't seem to do what you'd want in grotty.  A simple test seems to bear this out:


$ cat bullet_test
.if c\[bu] .tm Bullet exists.
$ groff -Tutf8 bullet_test
Bullet exists.
$ groff -Tascii bullet_test
Bullet exists.


So tty.tmac seemingly needs to make its decisions based on which "device" (utf8, latin1, etc.) the user has asked for.

Given all the above, does the logic need to be anything more complicated than

.if !'\*[.T]'utf8' \
. tr \[bu]*

Bug #55799 aside, I don't know whether .tr or .char makes more sense for this; I use .tr above not because I prefer it but just because it's what the current code uses.

Dave <barx>
Group Member
Tue 11 May 2021 02:47:45 AM UTC, comment #4: 

I can't say I really understand the reasoning in the logic of the original or as modified.

grotty(1) supports four encodings, which it calls "ascii", "latin1", "cp1047", and "utf8".

"ascii" has neither the centered period (\[pc]) nor the middle dot (\[md]).

"latin1", and its permutation, "cp1047", have the "middle dot" (\[md]).

"utf8" has both, as well as a bullet \[bu].

I don't understand why (1), we're using .tr for these \[bu] replacements instead of .char or .fchar and (2) why we're pretending that we don't know what the encoding will cover if it's not UTF-8 and not ASCII.


G. Branden Robinson <gbranden>
Group administrator
Tue 11 May 2021 02:02:22 AM UTC, comment #3: 

The mailing-list thread that prompted this commit seems to be the one beginning at http://lists.gnu.org/archive/html/groff/2015-06/msg00040.html.

Dave <barx>
Group Member
Thu 28 Mar 2019 09:14:09 AM UTC, comment #2: 

Oh.  I need to (temporarily?) retract my +1.

We already have the concept of a fallback character; it's what the .fchar request is for.  And an overstriking fallback is the very next thing in tty.tmac anyway.

Werner is the person who added this special casing for \[bu] back in 2015.


commit e7ea3e1106e0745ff252808e30d13a81478402eb
Author: Werner Lemberg <wl@gnu.org>
Date:   Wed Jun 17 19:47:20 2015 +0200

    * tmac/tty.tmac: Fix mapping of \[bu] character for -Tutf8.

    Problem reported by carsten.kunze@arcor.de.


I'll have to go to the mailing list to see if I can track this down.  The motivation is not spelled out here.

G. Branden Robinson <gbranden>
Group administrator
Thu 28 Mar 2019 08:54:50 AM UTC, comment #1: 

I'm a +1 on this.

Except I'd go ahead and fall back to the asterisk if none of bullet, period centered, and middle dot are available:


.if !c\[bu] \{\
. ie c\[pc] \
. tr \[bu]\[pc]
. el \
. ie c\[md] \
. tr \[bu]\[md]
. el \
. tr \[bu]*
.\}


I would not count on modern "tty" devices to be capable of arbitrary overstriking, since they're made of glass.

We can of course develop a new "papertty" device, but if there wasn't much demand for it in 1991 I'm guessing there will be even less now.

G. Branden Robinson <gbranden>
Group administrator
Thu 28 Mar 2019 06:12:09 AM UTC, original submission:  

tty.tmac unconditionally translates \(bu to \(pc or \(md if either is available.

.ie c\[pc] \
.  tr \[bu]\[pc]
.el \
.  if c\[md] \
.    tr \[bu]\[md]

This seems a strange choice Under any conditions, this seems a strange choice versus the more common approximation of an asterisk or the venerable ‘+’ overstruck with a lowercase ‘o’; the middle dot and math dot are small, barely visible, and bare little resemblance to a bullet. The choice is absolutely bizarre when a true bullet is available.

Is this possibly an artifact of pre-devutf8 days?  Even if it is decided to keep the unusual dots when a true bullet is unavailable, Would it not make more sense in general to have something like

.if !c\[bu] \{\
.  ie c\[pc] \
.    tr \[bu]\[pc]
.  el \
.    if c\[md] \
.      tr \[bu]\[md]
.\}

Jeff Conrad <jeffconrad>

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2024-01-27 barx Summary[grotty] should handle bullet character more intelligently [PATCH] [grotty] should handle bullet character more intelligently
    2024-01-26 barx Item GroupIncorrect behaviour Rendering/Cosmetics
        StatusNeed Info Confirmed
    2022-10-07 gbranden CategoryDriver - others/general Driver grotty
    2022-01-11 gbranden Summarytty device should handle bullet character more intelligently [grotty] should handle bullet character more intelligently
    2019-03-28 gbranden StatusNone Need Info
        Assigned toNone gbranden
    2019-03-28 gbranden SummaryTranslation of bullet to MIDDLE DOT tty device should handle bullet character more intelligently

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code