bug-groff
[Top][All Lists]
Advanced

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

[bug #63354] Refine fallbacks.tmac


From: Dave
Subject: [bug #63354] Refine fallbacks.tmac
Date: Tue, 15 Nov 2022 14:25:04 -0500 (EST)

Follow-up Comment #3, bug #63354 (project groff):

Um, you know that last comment where I said I was wrong?  Well, turns out I
was wrong, and I was actually right.  (So, also wrong.)

What I missed is that whatever special fonts are in play have no bearing on
the situation, because the clearly documented order of glyph-searching places
.fchar definitions _before_ special fonts.  So as long as the \[u2026] .fchar
in fallbacks.tmac is in force, whatever is happening in special-font-land is
irrelevant.

This is verifiable in practice.  Using the same input file from comment #2,
this command run using the latest groff code produces this output:

$ groff -Z ellipsis_demo | sed -n '/font 11 S/,/x trailer/p'
x font 11 S
f11
V24000
H72000
t.
h1666
t.
h1666
t..
h1666
t.
h1666
t..
h1666
t.
h1666
t.
n12000 0
x trailer

Then I commented out the \[u2026] definition in fallbacks.tmac and ran it
again.

$ groff -Z ellipsis_demo | sed -n '/font 11 S/,/x trailer/p'
x font 11 S
f11
V24000
H72000
Cu2026
h10000
Cu2026
h10000
Cu2026
h10000
n12000 0
x trailer

Here it's "easy" (if you're adept at reading intermediate output) to see that
in the former case, groff is constructing the ellipsis from spaced periods,
while in the latter, it's calling upon a character named u2026, which it's
pulling from the current font, which is S.

This also explains why I was led astray in comment #2: I took the mere loading
of font S as evidence that groff must be using that font's u2026--when in fact
it was using that font's period, as a special-font fallback because the last
requested font (ZD) also lacks a period glyph.

So please disregard comment #2.  The final example in the [comment #0 original
submission] is fine as-is, though the ".special" line is irrelevant (which is
fine, since it doesn't do anything anyway: bug #63366 remains a valid point
about special-font handling) and can be removed.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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