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.robin...@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/
