[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: |
Sat, 12 Nov 2022 18:06:53 -0500 (EST) |
URL:
<https://savannah.gnu.org/bugs/?63354>
Summary: Refine fallbacks.tmac
Project: GNU troff
Submitter: barx
Submitted: Sat 12 Nov 2022 05:06:51 PM CST
Category: Macro - 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: Sat 12 Nov 2022 05:06:51 PM CST By: Dave <barx>
A few of the fallback definitions in tmac/fallbacks.tmac
<http://git.savannah.gnu.org/cgit/groff.git/tree/tmac/fallbacks.tmac> could be
refined for robustness, typographic quality, or code consistency.
----
The file organization reflects its assemblage over time: it begins with two
blocks of \[u....] characters (one for diacritics, one for roman numerals),
goes into some mnemonic Latin-* fallbacks, then goes back to \[u....]
definitions (these added in (commit 132182bd
<http://git.savannah.gnu.org/cgit/groff.git/commit/?id=132182bd>, fixing bug
#58930). To me it makes more sense to have all the Unicode definitions
together, though perhaps there's some logic to the current arrangement I
haven't discerned.
Also, above some of the blocks is a simple comment giving the basic purpose of
the block, while others lack this.
----
As comment 23 of bug #58930 points out in two other cases, the user is
likelier to .tr simple ASCII characters than escapes representing those
characters. Most of the Unicode characters defined in the final block do use
escapes in their definitions. Some of those that don't are probably OK
because users are unlikely to .tr characters extremely common in text such as
the period and the hyphen. But two definitions might benefit from guarding
against this:
* \[u2016], currently defined as two "|"s, might be more robustly defined as
two "\[ba]"s.
* \[u2052] is defined as "%". This is trickier to change, because bug #63334
precludes the use of the alternate \[u0025], and groff provides no other way
to specify this character. So we either have to live with this small risk, or
make this bug dependent on 63334.
----
The figure dash (\[u2016]) as currently designed works well with some figures
but not others, in at least the TR font. Consider the PostScript output of:
echo '7\[u2012]5 6\[u2012]0' | groff
In the second pair of figures, the dash touches the figure on either side;
ideally there should be a bit of space between the dash and any adjacent
figure. (This will have to amount to shortening the dash, since the space
taken up by the entire glyph must remain constant.)
----
Over in bug #58930 I brought up the spacing between adjacent \[u2026]s. I
quote your reply there (in comment 24):
> I'm tempted to punt on this one, too. Possibly no serious
> font for typesetting even needs to encode these characters,
If you mean that most fonts will already have a U+2026 glyph, and therefore
this fallback will rarely be used, I agree. (If you mean something else, can
you please clarify?) Every general-purpose font groff ships includes this
character. Further, the Symbol font (which also includes it) being a default
special font means that even users using a locally installed font that lacks a
U+2026 will get it for free without doing any extra work.
All this might argue for removing this definition from fallbacks.tmac
entirely.
> and in groff, if you want a well-typeset leader, a fundamental
> formatter feature (Control+A) will give you one of whatever
> length you like.
True, but a leader is not the only situation where one might use adjacent
ellipses. Someone writing dialogue might decide that "Um\[u2026]\[u2026]"
conveys a greater degree of uncertainty than simply "Um\[u2026]". This will
look fine with Times's or Symbol's ellipsis, but the fallbacks.tmac one,
should it ever be pressed into service, will not fare so well:
.nf
Baseline demonstration.
\[u2026]\[u2026]\[u2026]
Switch to a font without u2026, and remove the Symbol fallback.
.ft ZD
.special
\[u2026]\[u2026]\[u2026]
I see no problems with the \[u2024] definition, being a single character. The
\[u2025] one will exhibit the problem shown above. But I don't know in what
situations one even uses U+2025, so I'd agree that punting in this case seems
the best option.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?63354>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
- [bug #63354] Refine fallbacks.tmac,
Dave <=
- [bug #63354] Refine fallbacks.tmac, Dave, 2022/11/12
- [bug #63354] Refine fallbacks.tmac, Dave, 2022/11/14
- [bug #63354] Refine fallbacks.tmac, Dave, 2022/11/15
- [bug #63354] Refine fallbacks.tmac, Dave, 2022/11/16
- [bug #63354] Refine fallbacks.tmac, Dave, 2022/11/20
- [bug #63354] Refine fallbacks.tmac, Dave, 2022/11/20
- [bug #63354] Refine fallbacks.tmac, Dave, 2022/11/20
- [bug #63354] Refine fallbacks.tmac, Dave, 2022/11/21