URL: <https://savannah.gnu.org/bugs/?66980>
Summary: fallbacks.tmac: refine U+2026 (horizontal ellipsis)
fallback
Group: GNU roff
Submitter: barx
Submitted: Thu 03 Apr 2025 04:02:56 AM CDT
Category: Macro package - others/general
Severity: 2 - Minor
Item Group: Rendering/Cosmetics
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Thu 03 Apr 2025 04:02:56 AM CDT By: Dave <barx>
This bug report consolidates information strewn across many comments in bug
#63354.
tmac/fallbacks.tmac currently defines \[u2026], the horizontal ellipsis, as:
.fchar \[u2026] .\|.\|.\" horizontal ellipsis
Problem 1: Two of these characters next to each other will be set badly.
Observe the typeset output of:
.nf
Baseline demonstration.
\[u2026]\[u2026]\[u2026]
Switch to a font without u2026.
.ft ZD
\[u2026]\[u2026]\[u2026]
For PostScript and PDF output, results are better if the .fchar for this
character is removed entirely:
* If a font lacks this character, groff looks for it in a special font, which
in devps and devpdf includes font S (Symbol), which contains a u2026 glyph.
* In PostScript (and probably PDF), a document cannot remove S as a special
font (this is not clearly documented; see bug #63366), so a u2026 glyph will
always be available.[1]
* A glyph in the current font takes precedence over one defined by .fchar.
But no user-defined character has lower precedence than a glyph in a special
font (see comment 2 in bug #44235), so _any_ .*char definition will obscure
the u2026 glyph in font S.
Even without the adjacent-ellipses problem, groff should generally prefer
using a font glyph over a constructed one. But with the current
fallbacks.tmac code, the above points prevent this any time the current font
lacks its own u2026.
Problem 2: Removing this .fchar, the ideal solution for devps and devpdf,
degrades devdvi and devlbp output. As Branden points out, these devices
"don't offer the PS Symbol font. grolbp in fact doesn't offer any special
fonts at all."
I said, and Branden agreed, that "terminal, PostScript and PDF are likely more
important output formats for a vast majority of users." At the time (December
2022, before the groff 1.23 release), I also pointed out that "grodvi and
grolbp had no u2026 fallback in prior releases, so lacking one in 1.23 isn't a
regression." Unfortunately, that ship has sailed.
Therefore, whether and how to tweak the \[u2026] fallback, to improve devps
and devpdf output without degrading devdvi and devlbp output, is an open
question.
[1] In bug #63366 Branden describes an "ugly hack" to remove Symbol as a
special font. But such a power user will be able to resolve the subsequently
missing u2026 glyph on their own; groff needn't supply a fallback to
accommodate them.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66980>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
