Follow-up Comment #9, bug #67252 (group groff): [comment #8 comment #8:] > The issue of this ticket is, "should the user expect fallback > character definitions to drastically alter the metrics of the > character"?
That's a larger issue. The issue of _this_ ticket is how to handle the
overset tables in groff_char(7). I see four options, two of which I expect
you to quickly reject (but I record all four for completeness):
* The tables could be reconfigured to not assume single-character widths.
* The tables could be conditionally reconfigured depending on the output
encoding. (This may require low-level groff that's normally not suitable for
man pages.)
* The problem characters could be always omitted from output encodings that
don't support them.
* Leave output as-is, and accept that users will get subpar tables with some
terminal widths in limited output encodings.
> I'm thinking "no, unless the user explicitly asks for 'semantic'
> fallbacks".
That's a valid option for the larger issue. But in a man page, typically
displayed using the "man" command, there would need to be a new option
(analogous to the existing --no-hyphenation and --no-justification) to enable
the user to explicitly ask for this.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67252>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
