[bug #63354] Refine fallbacks.tmac

[Dave]

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

Concerning U+2026:

[comment #19 comment #19:]
> The (PostScript) Symbol font won't be there on nroff devices.

A valid point that I hadn't considered.

> And if you're right for troff devices that Symbol is _always_ there
> and it _always_ defines this glyph, it _can't_ degrade typography.

This forgets the lesson I had to learn the hard way (see comment #3) that
.fchar definitions take precedence over special fonts.  So as things stand,
the definition in fallbacks.tmac will always hide the Symbol font's u2026,
degrading typography when using fonts that lack their own u2026.  And this
hiding seems to happen even with the lowest-precedence member of the .*char
family, .schar: given the following input, groff uses the "schar" definition
rather than falling back to the u2026 in Symbol:

.schar \[u2026] FOO
.ft ZD
\[u2026]

> You might however be forgetting grodvi and grolbp, which don't
> offer the PS Symbol font.

Indeed I was.  And offhand I'm not sure how to accommodate those without also
degrading PostScript.

> On nroff devices, users of "ascii" and "latin1" devices
> actually come out ahead of "utf8" users.

Luckily, we can easily test for terminal devices and give them different
fallbacks.

For grodvi and grolbp, all I can do is observe that (a) terminal, PostScript
and PDF are likely more important output formats for a vast majority of users,
and (b) grodvi and grolbp had no u2026 fallback in prior releases, so lacking
one in 1.23 isn't a regression.

Thus I'm starting to think the best solution is to make the u2026 fallback
terminal-only for 1.23.  But if there's a way to keep the PostScript/PDF
behavior as it was in 1.22.4 but also improve other non-terminal output, I'm
open to that.


    _______________________________________________________

Reply to this item at:

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

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