bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dave
Subject: [bug #63332] recent fallbacks.tmac change degrades ASCII output
Date: Thu, 1 Dec 2022 04:20:40 -0500 (EST)

Follow-up Comment #10, bug #63332 (project groff):

Replying to the rest of comment #5, as promised.  Some of it may be moot; I'm
not sure how far the miscommunication extended that was resolved in comment
#8, so I'll try not to belabor points that may no longer be relevant.  Feel
free to ask for clarification if I skim over anything too much.

> So here's my new patch.

Now applied, so we're good here.

> I'm dubious about tty-char.tmac's definition of \(rn.

Looking at it now, I agree with this--but it's also been unchanged for over 20
years.  (Maybe readers just have low expectations for equations rendered on
the terminal.)

> Well, character definitions aren't coupled in any way, as far
> as I know, to the "troff/nroff mode" bit in the formatter.

Right, not by default, but I was talking about the explicit coupling provided
by the definitions sequestered behind tests for that mode.

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

Understood; my point is that this request is invoked after fallbacks.tmac is
processed, mooting those aforementioned tests.

> Post-1.23 it might be worth looking into loading fallbacks.tmac
> later, and maybe combining it with tty-char.tmac in some way.

OK.  But for 1.23 itself, without further mitigation, a few characters will
render badly on terminals (e.g., as in comment #7).

Then again, their 1.22.4 rendering was a warning message and a complete
omission of the characters, so this is, if not a step forward, at least not
one backward either.

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

Yes, and this is fine to defer.

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

Babies do teeter and fall a lot.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]