Follow-up Comment #7, bug #44018 (group groff):

Sharing an issue that I think may be related.

When setting output lines of mainly or exclusively CJK scripts as opposed to
Western ones, because hyphenation is disabled and word spaces are less common
or, in some cases, unused, I think warnings in the "break" category are more
likely.

Not certain yet; issues with CJK man pages demand more study.  I am also
concerned that we might not support CJK full-width characters correctly on
terminals.  If we get incorrect information from `wcwidth()`, this seems a
likely prospect.


commit c9d9a4e1e743d84de96ef4f6d2bde6b09bc67b1e
Author: G. Branden Robinson <g.branden.robin...@gmail.com>
Date:   Fri Mar 21 14:50:12 2025 -0500

    [troff]: Warn on failure to adjust the output line.
    
    * src/roff/troff/env.cpp (distribute_space): I planted an `assert()`
      land mine for myself back in December and it finally went off.  Remove
      assertion that the amount of `desired_space` for adjustment must be
      nonnegative.  While rare, this can in fact happen with perverse inputs
      such as long, unhyphenable character sequences or short output line
      lengths.  Throw new warnings in category "break" when adjustment is
      desired but impossible: (1) the output line has no adjustable spaces
      on it, or (2) any adjustable spaces would have to be squeezable/
      shrinkable to achieve a fit, and that is not yet implemented in GNU
      troff (see Savannah #44018).  (Even if/when we do implement it, there
      will be a [likely configurable] limit to how narrow an adjustable
      space can become.)
    
    * doc/groff.texi.in (Warnings):
    * src/roff/troff/troff.1.man (Warnings): Document additional
      circumstances under which warnings in "break" category are thrown.
      Clarify existing circumstances.
    
    Fixes <https://savannah.gnu.org/bugs/?66392>.
    
    Also annotate places in code that I think will likely need to change
    upon tackling Savannah #44018.


Apparently when writing that final sentence in the commit, I forgot that this
ticket was already resolved.  Probably because I am uncertain, as noted above,
that we've comprehensively solved breaking and adjustment of output lines with
CJK characters.

But I haven't seen any evidence in 5 years that we infinitely loop upon
hitting them either, so maybe I should accept victories where they occur.  :)


    _______________________________________________________

Reply to this item at:

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

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

Attachment: signature.asc
Description: PGP signature

Reply via email to