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

[G. Branden Robinson]

Update of bug #63332 (project groff):

                  Status:               Need Info => In Progress            

    _______________________________________________________

Follow-up Comment #5:

[comment #4 comment #4:]
> I confirm that your patch solves the \(dd and \(dg problem.

Cool, thanks!

I'm going to rearrange the discussion to front-load the more immediate
concerns, then return to our drawing-room mystery later in this reply.

> [comment #3 comment #3:]
> > None of this explains why most of the other new fallbacks
> > don't have the same problem.
> 
> I didn't actually test most of the others, but maybe you have.  It sounds
like you tested at least \(bu.

Yeah, and a few others, but I wasn't comprehensive and I now see I needed to
be.

The per mille sign and root en extender are also trouble.  (And also both not
in ISO Latin-1--so that hypothesis is not yet overturned.  But it's weakening:
neither the em and en dashes nor the directional quotation marks are.)


$ cat EXPERIMENTS/fallbacks.groff 
.ta 1i
.nf
en      \(en
em      \(em
oq      \(oq
cq      \(cq
lq      \(lq
rq      \(rq
dg      \(dg
dd      \(dd
bu      \(bu
pc      \(pc
%0      \(%0
fm      \(fm
sd      \(sd
fo      \(fo
fc      \(fc
rn      \(rn
f/      \(f/
ti      \(ti
$ ./build/test-groff -Tascii -mtty-char EXPERIMENTS/fallbacks.groff | cat -s
troff:EXPERIMENTS/fallbacks.groff:13: warning: special character '%0' not
defined
troff:EXPERIMENTS/fallbacks.groff:18: warning: special character 'rn' not
defined
en        -
em        --
oq        `
cq        '
lq        "
rq        "
dg        <*>
dd        <**>
bu        o
pc        .
%0
fm        '
sd        "
fo        <
fc        >
rn
f/        /
ti        ~



So here's my new patch.


diff --git a/tmac/fallbacks.tmac b/tmac/fallbacks.tmac
index 633dbc711..9ba22c0f5 100644
--- a/tmac/fallbacks.tmac
+++ b/tmac/fallbacks.tmac
@@ -167,20 +167,21 @@
 .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
 .fchar \[u2026] .\|.\|.\" horizontal ellipsis
 .fchar \[u2027] \[pc]\" hyphenation point
-.fchar \[u2030] \[%0]\" per mille sign
+.\"fchar \[u2030] \[%0]\" per mille sign \" Savannah #63332 again
 .fchar \[u2032] \[fm]\" prime
 .fchar \[u2033] \[sd]\" double prime
 .fchar \[u2039] \[fo]\" left single chevron
 .fchar \[u203A] \[fc]\" right single chevron
 .if t .fchar \[u203D] \o'?!'\" interrobang
-.fchar \[u203E] \[rn]\" overline
+.\"fchar \[u203E] \[rn]\" overline \" Savannah #63332 again
 .fchar \[u2044] \[f/]\" fraction slash
 .fchar \[u2052] %\" commercial minus sign
 .fchar \[u2053] \[ti]\" swung dash


I'm dubious about tty-char.tmac's definition of \(rn.  It would be fine for
overstriking terminals, none of which has a device definition in groff.  I
wonder if there's a terminfo capability for that?

> > 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.
> 
> Sounds good to me.

Cool.  I'll go ahead with the above.

> I was convinced that a more surgical ".if t" on those lines would also do
the trick--but it doesn't.

Well, character definitions aren't coupled in any way, as far as I know, to
the "troff/nroff mode" bit in the formatter.  So it doesn't surprise me
(unlike Paul Eggert's claims today about the braindeadness of Solaris's troff,
which shocked even my low expectations of that implementation).

> Weirdly, even adding the line ".if t .tm troff mode" to that file prints
"troff mode" on stderr when groff is run with -Tascii.  I presume this is
because tmac/troffrc
<http://git.savannah.gnu.org/cgit/groff.git/tree/tmac/troffrc> loads
fallbacks.tmac _before_ loading the device-specific .tmac file.

Right.  The device description file doesn't say whether it's a "troff" or
"nroff" device; instead a request does that.

> This means the other "t" conditionals in fallbacks.tmac also don't do what
was intended.

I don't think that's true.  There is no alternative to "troff mode" and "nroff
mode", you're either in one or the other, and the default is troff mode. 
Observe:


$ echo ".if t .tm troff mode" | troff -R
troff mode
$ echo ".if t .tm troff mode" | troff -R -Tascii
troff mode


Still, I wonder about the timing of composite and fallback character setup. 
Post-1.23 it might be worth looking into loading fallbacks.tmac later, and
maybe combining it with tty-char.tmac in some way.

But more important is understanding how `character_exists()` _really_ works,
or I predict only more frustration.

One data point did pop up when I turned on backtraces (-b).


troff: backtrace: '.../groff/build/../tmac/fallbacks.tmac':178: composite
character '%0'
troff: backtrace: file 'EXPERIMENTS/fallbacks.groff':13
troff:EXPERIMENTS/fallbacks.groff:13: warning: special character '%0' not
defined
troff: backtrace: '.../groff/build/../tmac/fallbacks.tmac':184: composite
character 'rn'
troff: backtrace: file 'EXPERIMENTS/fallbacks.groff':18
troff:EXPERIMENTS/fallbacks.groff:18: warning: special character 'rn' not
defined


Oh, "composite character", eh?  Is _that_ what the formatter thinks that is
(like \[e aa])?

My nose twitches.  But I've resolved to chase that scent later.

It seems even baby steps toward Unicode are fraught with peril.


    _______________________________________________________

Reply to this item at:

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

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