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: 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/




reply via email to

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