[bug #64144] [man] problems with fonts with no /space glyph and no hyphen glyph

[G. Branden Robinson]

Follow-up Comment #3, bug #64144 (project groff):

[comment #2 comment #2:]
> Hi Branden,
> 
> Yes, it ought to be two issues, sorry, I just found both with one test.

No worries.  I'll come back to the afmtodit issue below.

> 
> Your patch did stop the warning from an.tmac, brilliant, but I could not
test whether the if statement still "works", I never include X11 support when
I build groff.

Okay.  I'm fairly confident it will work; I tested it as follows.


$ cat EXPERIMENTS/escape-question-mark.groff 
.ds A FNORD
.ie '\?\*[A]\?'\?FNORD\?' .tm YES
.el                       .tm NO


...and it produced the expected results.

I think this might drive further documentation clarifications.  I didn't
really _expect_ that to work; I half-expected otherwise, given `\?`'s existing
documentation.  There is more about the way \! and \? work that I think I need
to understand.

Regarding afmtodit and the -w flag...I think maybe font installation scripts
_should_ be calling the command with that flag, for the reason I added this
feature in the first place.


commit 5a5a447b2a834f92112609a67821c1a37fdc66cd
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Nov 11 15:49:24 2022 -0600

    [afmtodit]: Implement "-w" command-line option.
    
    * src/utils/afmtodit/afmtodit.pl: Add new command-line option to specify
      the generated font description's "spacewidth" parameter; in commit
      bf7f6862c3, 2021-09-24, I made libgroff complain if this directive is
      missing (since any font, even a "special" one, can be selected as
      current and the formatter's behavior when encountering an input space
      should be well-defined under that circumstance).  Adding this option
      enables a well-formed font description to be produced.
    
    * src/utils/afmtodit/afmtodit.pl (usage):
    * src/utils/afmtodit/afmtodit.1.man (Synopsis, Options): Document it.
    
    * NEWS: Add item.


I think the CJK scenario might be an even better motivating example than
explicit selection of a "special" font, since CJK fonts are text fonts and
_will_ be selected by users under normal operation.

Shouldn't the space width be well-defined in that event?

My *very limited* understanding is that CJK characters are with great
consistency drawn within a square bounding box, and don't have
"variable-width" forms as Western alphabetic scripts typically do, though they
are often variable-width in practice due to heterogeneous script usage, i.e.,
inclusion of Hindu-Arabic numerals or the Latin script for referential
purposes (jp: romaji).

In that event I suppose the width of a space in a CJK font should be
"fullwidth", in other words the same as the width of most (all?) glyphs in the
font.

What I don't think we should let the formatter do in a prescribed scenario is
permit its fallback space-width calculating logic to occur, which as it
happens is tuned for Western scripts.

https://git.savannah.gnu.org/cgit/groff.git/tree/src/libs/libgroff/font.cpp?h=1.23.0.rc4#n1037

What do you think?


    _______________________________________________________

Reply to this item at:

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

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