bugGNU roff - Bugs: bug #65403, Meaning of ".if c" in...

 
 

bug #65403: Meaning of ".if c" in nroff mode undocumented

Submitter:  Dave <barx>
Submitted:  Sat 02 Mar 2024 10:40:39 PM UTC
   
 
Category:  Core Severity:  2 - Minor
Item Group:  Documentation 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

Thu 07 Mar 2024 07:30:32 PM UTC, comment #7: 

comment #6:

> There's a ticket about this already, wondering about the
> complexity of it.  See bug #56015.


Oh, the ticket where I proposed a patch less than two months ago?  Yes, I'm, uh, dimly aware of it.

> But even if the translation weren't occurring, you'd still
> find that `rchar` didn't work on a font-supplied character.


I wouldn't expect it to, but it seemed immaterial here since neither ascii nor latin1 has a font supplying \[bu].  The purpose of the .rchar in that test was to remove the effect of the .fchar pointed out in comment #3.

> I'm blocked on that pending negotiation with Peter.  ;-)


Apparently my brain has blocked any information relevant to this issue.  I promise to stop posting puzzles to which I already know the solution for the rest of today.

Dave <barx>
Group Member
Thu 07 Mar 2024 05:44:11 PM UTC, comment #6: 

Because it gets translated first.


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


There's a ticket about this already, wondering about the complexity of it.  See bug #56015.

But even if the translation weren't occurring, you'd still find that `rchar` didn't work on a font-supplied character.

At that point you will discover bug #63985.

I'm blocked on that pending negotiation with Peter.  ;-)

G. Branden Robinson <gbranden>
Group administrator
Thu 07 Mar 2024 05:36:15 PM UTC, comment #5: 

Hmm, I'm hard-pressed to explain this, though.

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

The bullet (U+2022) is not a Latin-1 character.  It does not appear in tmac/latin1.tmac or any file in font/devlatin1.  The DESC files in font/devascii and font/devlatin1 are identical.

Dave <barx>
Group Member
Sun 03 Mar 2024 02:24:54 AM UTC, comment #4: 

comment #3:

> Right, because \[bu] is defined for that output device with
> `fchar`, in tty.tmac.


Oh.  Right.  I knew that, of course.  fidgets awkwardly with shirt cuffs

Dave <barx>
Group Member
Sun 03 Mar 2024 01:59:27 AM UTC, comment #3: 

comment #2:

> comment #1:
> > An unfortunate property of the "unicode" directive documented in
> > groff_font(5) is that it causes this test to always succeed.
>
> Be that as it may, the test for \[bu] also succeeds in devascii, despite font/devascii/DESC not specifying the "unicode" directive,
> and no other files in font/devascii having "bu" in their "charset" sections.


Right, because \[bu] is defined for that output device with `fchar`, in tty.tmac.

When you query an ordinary or special character with, say, `.if c`, and you get a "yes" answer, you don't know where the "defined character" comes from.  Might be a fully fledged character definition.  Might be a fallback character.  Might be font-specific fallback character.  Might come from a special font.  Might be a real glyph in the currently mounted font.

If that seems like a uselessly vague "yes" to you, see bug #64004.

G. Branden Robinson <gbranden>
Group administrator
Sun 03 Mar 2024 01:49:10 AM UTC, comment #2: 

comment #1:

> An unfortunate property of the "unicode" directive documented in
> groff_font(5) is that it causes this test to always succeed.


Be that as it may, the test for \[bu] also succeeds in devascii, despite font/devascii/DESC not specifying the "unicode" directive, and no other files in font/devascii having "bu" in their "charset" sections.

Dave <barx>
Group Member
Sun 03 Mar 2024 12:14:05 AM UTC, comment #1: 

Yes.  An unfortunate property of the "unicode" directive documented in groff_font(5) is that it causes this test to always succeed.

G. Branden Robinson <gbranden>
Group administrator
Sat 02 Mar 2024 10:40:39 PM UTC, original submission:  

Branden said in bug #59962: "grotty(1), the output driver for terminal devices...has no way to query the terminal device regarding its repertoire of supported glyphs or Unicode code points....  People familiar with groff may wonder about this claim given the existence of '.if c', '.fchar', and similar.  As I understand it, these work at the interface between groff language input and the output driver."

In short, ".if c" doesn't do what you'd probably expect in grotty.  This simple test (originally posted in bug #56015) 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.

However, this seems un(der)documented.  All the "Operators in Conditionals" section of the Texinfo manual says about what 'c GLYPH' tests is "True if GLYPH is available."  Particularly, "available" is not defined, and may seem too obvious to need defining, but the above shows the "obvious" interpretation doesn't apply to grotty.

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

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code