bugGNU roff - Bugs: bug #64144, [man] problems with fonts with no...

 
 

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

Submitter:  Deri James <deri>
Submitted:  Thu 04 May 2023 12:10:56 AM UTC
   
 
Category:  Macro man Severity:  2 - Minor
Item Group:  Incorrect behaviour Status:  Need Info
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 04 May 2023 06:29:01 PM UTC, comment #3: 

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?

G. Branden Robinson <gbranden>
Group administrator
Thu 04 May 2023 02:07:28 PM UTC, comment #2: 

Hi Branden,

Yes, it ought to be two issues, sorry, I just found both with one test.

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.

Cheers

Deri

Deri James <deri>
Group Member
Thu 04 May 2023 01:02:27 AM UTC, comment #1: 

Hi Deri,

This sounds like 2 different issues, one arising from my recent change to afmtodit, and one in the man macro package.

See if this patch does this trick:


$ git di tmac/an.tmac
diff --git a/tmac/an.tmac b/tmac/an.tmac
index 9e38ba569..8f199430c 100644
--- a/tmac/an.tmac
+++ b/tmac/an.tmac
@@ -1480,11 +1480,14 @@ contains unsupported escape sequence
 .\}
 .
 .\" type size
+.
+.\" We take special care with the output comparison operator here
+.\" because a CJK font lacking a hyphen glyph might be selected.
 .if !r S \{\
 .  nr S 10
-.  if '\*[.T]'X75-12' \
+.  if '\?\*[.T]\?'\?X75-12\?' \
 .    nr S 12
-.  if '\*[.T]'X100-12' \
+.  if '\?\*[.T]\?'\?X100-12\?' \
 .    nr S 12
 .\}
 .


Please reassign back to me when you have results.

Probably the same thing will have to be done for mdoc(7).

G. Branden Robinson <gbranden>
Group administrator
Thu 04 May 2023 12:10:56 AM UTC, original submission:  

Some fonts (CJK) don't have a space glyph defined, and afmtodit can't add a spacewidth directive to the troff font, and you have no way of knowing you needed to add a -w flag until after the font is installed and troff starts complaining, even though the output is fine.

Not having the hyphen glyph is weird, each time you run with the man macro (and possibly others), you get this message:-

troff:/home/derij/groff-git/groff/build/../tmac/an.tmac:1512: warning: character '-' not defined

This is because some devices have a hyphen in their name, so code such as this:-

.  if '\*[.T]'X75-12' \
.    nr S 12
.  if '\*[.T]'X100-12' \
.    nr S 12

Triggers the warning! Perhaps a judicious use of \f(TR and \fP would fix?

I found these minor issues when developing the UTF-16 bookmark support for gropdf. See attached Japanese man page.

Deri James <deri>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #54703:  groff.7.pdf added by deri (428KiB - application/pdf)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by deri (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-05-04 deri Assigned toderi gbranden
    2023-05-04 gbranden StatusNone Need Info
        Assigned toNone deri
        SummaryProblems with fonts with no /space glyph and no hyphen glyph [man] problems with fonts with no /space glyph and no hyphen glyph
    2023-05-04 deri Attached File- Added groff.7.pdf, #54703

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code