Follow-up Comment #13, bug #67252 (group groff):

Catching up with Dave and Ingo:

[comment #10 comment #10:]
> [comment #8 comment #8:]
>> I disagree with this claim.  They're suitable any time your device's
>> fonts don't have coverage.
> 
> Good point.
> 
> However:
> * The only place tty-char.tmac is loaded automatically is from nroff.sh.
> * The only place tty-char.tmac is documented is in comments in itself and in
> tty.tmac (and even there, suboptimally: bug #62814).  (See also bug #61958.)
> * As you note, there's no clean way to separate the "semantic" fallbacks from
> the others; users would have to manually copy the ones they want, or edit
> tty-char.tmac.
> So while some tty-char.tmac fallbacks are useful outside terminal output, the
> current infrastructure effectively supports them only when running nroff.
> 
> This is worth redressing, but that's another issue for another ticket.

[comment #12 comment #12:]
> [comment #10 comment #10:]
>> This is worth redressing, but that's another issue for another ticket.
> 
> Join me in welcoming bug #67356 to the world.

Excellent.  The proposal there is (I paraphrase) "let users of any output
driver opt in to semantic fallbacks".

Separate issue #1: There may be some fallbacks in "tty-char.tmac" that should
remain confined to the _grotty_ output driver's supporting macro file.  That's
essentially bug #62814.

Separate issue #2: We should warn (or be configurably able to) when unfilled
lines are overset.  That's bug #66977.

Separate issue #3: _groff_char_(7) should be revised to present glyph tables
that don't overset when semantic fallbacks are used.  If that's all that
remains of this ticket, I am inclined to close it as "Rejected".

Is the foregoing a fair redrawing of the multifarious issues arising from
comment #0?

[comment #11 comment #11:]
> gbranden@ Tue 08 Jul 2025 10:35:35 PM GMT:
> 
>> I don't know how hard a problem the issue in the present ticket
>> poses for mandoc(1)'s tbl implementation.
> 
> From a purist perspective, the problem is untractable, because
> 
> (1) The mandoc parse tree is supposed to be independent of the
> output device.

Yeah, *roff doesn't have that as a design criterion.  One has been able to
write conditionals based on properties of the output device for about 50 years
now.

> (2) The tbl(7) geometry is supposed to be based solely on the
> parse tree, i.e. independent of the output device as well.

This assumption fails for *roff for the same reason as (1).  _tbl_'s approach
is interesting.  It parameterizes the table dimensions, but doesn't _decide_
them.  The dimensions aren't computed until the formatter runs.  This creates
interesting problems when one's table length exceeds the space available on
the page.
 
> From that perspective, mandoc(1) decides about the width of table
> columns before it even knows what the output device will be.

On the other hand, I'll bet _mandoc_(1) knows whether it's going to be using
semantic fallbacks, and where, at the time it decides the table dimensions.
 
> That problem is not all that much related to how wide fallback
> strings are compared to the unavailable characters they replace.
> There are *many* features in groff that calculate widths depending
> on the output device and can then be used to change parsing,
> all of which, from the mandoc(1) perspective, are layering violations,

<rattles swear jar>

> for exampke the \w, \h, \l, and \n escape sequences, the .nr request,
> any kind of scaled widths (for example in terminal and PDF output,
> 1u means a totally defferent thing), and even font selection.
> So fallbacks aren't really special.

Agreed.  The text formatters' designs differ fundamentally here.

> From a practical perspective, i have given up on implementing the
> pure design described above.  While (1) the parse tree is still
> mostly device independent, for some time now, (2) the module "out.c"
> that was in theory supposed to be the device-independent, common
> part of all output modules, and that in particular contains the
> tblcalc() function governing tbl(7) column widths, has been
> calling device-dependent measurement functions, resulting in the
> table widths actually depending on the output device.

If I had advice to offer regarding the recovery of purity, I'd share it.

> For example:
> 
> $ man -T ascii -l man/groff_char.7.man
> [...]
> {}                    \[es]          u2205        empty set +
> <element of>          \[mo]          u2208        element of a set +
> <not element of>      \[nm]          u2208_0338   not element of set
> <proper subset>       \[sb]          u2282        proper subset +
> <not subset>          \[nb]          u2282_0338   not subset
> <proper superset>     \[sp]          u2283        proper superset +
> <not superset>        \[nc]          u2283_0338   not superset
> <subset or equal>     \[ib]          u2286        subset or equal +
> <superset or equal>   \[ip]          u2287        superset or equal +
> <intersection>        \[ca]          u2229        intersection, cap +
> <union>               \[cu]          u222A        union, cup +
> 
> Sure, a few lines end up wider than 78 columns, but overall, the
> page looks quite reasonable with mandoc(1).

I agree.  Overrunning 80 would be a worse problem.
 
> I don't quite understand what needs fixing here

Neither do I, hence my question about about the (re)drawing of ticket scopes.

> (except that general
> simplification and fewer knobs to teak would of course be welcome).

Well, a simplification I'd like to undertake is to get GNU _tbl_ *out* of the
business of warning about overset lines, and have GNU _troff_ do that, under
any circumstances where it occurs, not just table rendering (and not just
formatting of adjusted lines).

I think that would "layer" better, but some concern has been expressed about
"spurious" warnings arising from unfilled text that intentionally encroaches
into the margin.  My rebuttal to that point would involve the observation that
if you encroach beyond the margin past a certain point, you'll end up off the
page, and text will disappear.

But this is a matter of diagnostic issue only; no change to formatted output
is contemplated (beyond that implied by fairly well-understood fallback
characters).

> But maybe that's just me, i didn't try very hard to wrap my head
> around what you are discussing here.

Several mutually influencing issues were raised.

Bjarni's bug reports often seem to reflect a view that no diagnostic messages
should ever be issued, but that's an...unsophisticated perspective, I would
say.

Diagnostic messages exist to advise the user of things they probably want to
know, and upon which they are, ideally, empowered to act.  (Some fatal
diagnostics may reflect an insufficiency of system resources that is difficult
to address immediately.)

Considering that _groff_char_(7)'s purpose is to list a glyph for every
special character _groff_ supports without additional configuration, one
should not be surprised that diagnostics issue when one employs an output
device that is inherently incapable of rendering glyphs for some (or many) of
those special characters.  The text of the page itself speaks to this.


     On devices with a limited glyph repertoire, glyphs in the “keycap”
     and “appearance” columns on the same row of the table may look
     identical; except for the neutral double quote, this will not be
     the case on more‐capable devices.  Review your document using as
     many different output devices as possible.


┌───────────────────────────────────────────────────────────────────┐
   │ Keycap   Appearance and meaning   Special character and meaning   │

├───────────────────────────────────────────────────────────────────┤
   │ "        " neutral double quote   \[dq] neutral double quote      │
   │ '        ’ closing single quote   \[aq] neutral apostrophe
│
   │ -        ‐ hyphen                 \- or \[-] minus sign/Unix dash
│
   │ \        (escape character)       \e or \[rs] reverse solidus     │
   │ ^        ˆ modifier circumflex    \[ha] circumflex/caret/“hat”
│
   │ `        ‘ opening single quote   \(ga grave accent
│
   │ ~        ˜ modifier tilde         \[ti] tilde                     │

└───────────────────────────────────────────────────────────────────┘


Maybe I should have a more general advisory inaugurate the page's "Glyph
tables" section.


    _______________________________________________________

Reply to this item at:

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

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

Attachment: signature.asc
Description: PGP signature

Reply via email to