[bug #63332] recent fallbacks.tmac change degrades ASCII output

[G. Branden Robinson]

Update of bug #63332 (project groff):

                  Status:               Confirmed => Need Info              

    _______________________________________________________

Follow-up Comment #3:

Hi Dave,

This one is challenging my understanding, and I am anxious about it causing
further slippage of the already monumentally slipped 1.23.0.rc2.

First, I have a proposal for knocking this off the 1.23.0 criticality path. 
It seems to un-degrade the \(dd and \(dg characters.


diff --git a/tmac/fallbacks.tmac b/tmac/fallbacks.tmac
index 633dbc711..39a2e8072 100644
--- a/tmac/fallbacks.tmac
+++ b/tmac/fallbacks.tmac
@@ -167,8 +167,9 @@
 .fchar \[u2019] \[cq]\" right single quotation mark
 .fchar \[u201C] \[lq]\" left double quotation mark
 .fchar \[u201D] \[rq]\" right double quotation mark
-.fchar \[u2020] \[dg]\" dagger
-.fchar \[u2021] \[dd]\" double dagger
+.\" XXX: The next two are troublesome; see Savannah #63332.
+.\"fchar \[u2020] \[dg]\" dagger
+.\"fchar \[u2021] \[dd]\" double dagger
 .fchar \[u2022] \[bu]\" bullet
 .fchar \[u2024] .\" one dot leader
 .fchar \[u2025] .\|.\" two dot leader


Please confirm on your installation.

The terrible news is that I don't know _why_ this works.

Here's a brief brain dump for when I can get back to this.

* node.cpp:character_exists() returns true (early) if ci->get_macro() returns
a non-null pointer.  I think this means that it's been defined with a `char`
or related request.  The RHS is termed a "macro" internally even if that's a
bit confusing for ordinary users.  I think our Texinfo manual also has some
casual language about character definitions being "wrapped up in a macro".

* I think the above is why we're getting false positives on our .if c tests.

* This is still a valid thing to want to do.

* However maybe we need a new ".if g" conditional operator that _really_ does
check to see if a glyph is available in the current font.  An honest-to-God
"can you draw this glyph?" query.

* None of this explains why most of the other new fallbacks don't have the
same problem.  Like \(bu.  The best guess I have for now is that because the
bullet is in ISO 8859-1 (the daggers aren't), some special logic path is
followed that doesn't hose things up.

So if that patch is enough to fix the regression, I'd like to apply it, un-tag
this for 1.23.0, and move on to other things, returning to it when I have more
time and understand character/glyph resolution better.  Even according to our
existing docs it's something like a 7-step procedure.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63332>

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