[bug #65619] [afmtodit] want a default value for space width if unspecified

[Deri James]

Follow-up Comment #8, bug #65619 (group groff):

[comment #7 comment #7:]
> As a refresher, I'm wondering what should be done about some of the space
glyphs identified in comment #5.

> So, check for "space", "uni0020", and "uni00A0" in that order?

Yes.

> sterlingmonospace;FFE1

This is not a space it's '￡' FULLWIDTH POUND SIGN

> ideographicspace;3000

Yes.

> nbspace;00A0

This is uni00A0 (see above)

> spacehackarabic;0020

Same as uni0020.

> Advice desired.

Attached are three PDFs.

UniSpaces.pdf: Documents any glyph in the unifont.ttf font (which covers
-FFFE) where the unicode name includes 'space'. This is a mono-spaced font
so the widths given are not particulary helpful.

TinosSpace.pdf: Similar, but covering the Tinos-Regular.ttf font, which gives
proportional widths (the 4 fields in the first line of each glyph are:
unicode, groff name, width, postscript name).

U-TR: Just showing off my new font tool for a complete font. :-)

My take is that EM SPACE and EN SPACE are too large, and EM divisions would be
unreliable, so I think the glyphs suggested above is what I will use to
calculate 'spacewidth'. 

(file #56142, file #56143, file #56144)

___

Additional Item Attachment:

File name: UniSpaces.pdf  Size: 15KiB


File name: U-TR.pdf   Size: 415KiB


File name: TinosSpace.pdf Size: 19KiB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-67b04ef8737d6f02579af43d702ebae34ebfcbfd.tar.gz


___

Reply to this item at:

  

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

[bug #65619] [afmtodit] want a default value for space width if unspecified

[G. Branden Robinson]

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

As a refresher, I'm wondering what should be done about some of the space
glyphs identified in comment #5.


___

Reply to this item at:

  

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

[bug #65619] [afmtodit] want a default value for space width if unspecified

[G. Branden Robinson]

Follow-up Comment #6, bug #65619 (group groff):

Deri noted in comment #23 to bug #63018:

> Look for different 'spaces' to set 'spacewidth'.
> Implement -ww switch - force even if 'space' found.
> Warn if -w used and 'space' found (but advise rerun with -ww to override). 

I replied in comment #24:
> I ask that we spell these '-w' (fallback) and '-W' (force),
> respectively.  Or maybe pick other another letter altogether for
> one (or both).
>
> Generally, in Unix commands, repeating an option flag, when it is
> meaningful at all, means to do something "harder" or "more", not to 
> do it differently.



___

Reply to this item at:

  

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

[bug #65619] [afmtodit] want a default value for space width if unspecified

[G. Branden Robinson]

Update of bug #65619 (group groff):

 Assigned to:gbranden => deri   

___

Follow-up Comment #5:

[comment #3 comment #3:]
> A useful change to afmtodit would be to look for other space glyphs in the
font (u0020 and u00A0) if space is not found, then if none are found, use the
value given on the command line, and if that is missing, it is not a special
font, warn user the font will be unusable in groff and suggest they rerun
afmtodit with a suitable -w flag.

This proposal sounds good to me.  *Normally*, I think the Unix command-line
model treats options as overrides rather than fallbacks.  But sometimes you
need the latter.  Sometimes you need both (witness _preconv_).

So, check for "space", "uni0020", and "uni00A0" in that order?

Hmm, that may be too simple.

There are over 100 matches for "space" in the Adobe Glyph List.

Leaving aside "monospace" names for A-Z, a-z, 0-9, and some other stuff.  I
_was_ going to guess the 94 graphical code points, but I see fun stuff like
this too.

sterlingmonospace;FFE1

That ain't ASCII.  That ain't ASCII a 'tall.

But with respect to (non-zero-width) spaces, I see:

ideographicspace;3000
nbspace;00A0

There may be others, not sure I got 'em all.

Here's a fun one:

spacehackarabic;0020

NFI if we should deal with that one.

Advice desired.


___

Reply to this item at:

  

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

[bug #65619] [afmtodit] want a default value for space width if unspecified

[Dave]

Update of bug #65619 (group groff):

  Status: Invalid => Need Info  
 Open/Closed:  Closed => Open   

___

Follow-up Comment #4:

Reopening since comment #3 raises an objection to -w's current behavior and
suggests a "useful change to afmtodit," which based on comment #1 would solve
the problem Alex is seeing.

It's not clear (to me), though, how the below case should be handled, or if
this is the proper use case for -w:

[comment #1 comment #1:]
> Other CJK fonts have proportional western glyphs and fixed width
> CJK, with no space glyph defined, this is when afmtodit fails to
> write a spacewidth parameter. See font TakaoPGothic as an example).


___

Reply to this item at:

  

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

[bug #65619] [afmtodit] want a default value for space width if unspecified

[Deri James]

Follow-up Comment #3, bug #65619 (group groff):

Afmtodit has always used the width of the space glyph (if defined in the
font), what your change did was enable this to be overridden on the command
line, which is probably wrong. If the intention was to provide a fallback
value when a spacewidth was not present, the logic could have been written
that way.

A useful change to afmtodit would be to look for other space glyphs in the
font (u0020 and u00A0) if space is not found, then if none are found, use the
value given on the command line, and if that is missing, it is not a special
font, warn user the font will be unusable in groff and suggest they rerun
afmtodit with a suitable -w flag.

This was Branden's change:-

+my $sw = 0;
+$sw = conv($width{"space"}) if defined $width{"space"};
+$sw = $space_width if ($space_width);
+
 print("name $name\n");
 print("internalname $psname\n") if $psname;
 print("special\n") if $opt_s;
 printf("slant %g\n", $italic_angle) if $italic_angle != 0;
-printf("spacewidth %d\n", conv($width{"space"})) if defined $width{"space"};
+printf("spacewidth %d\n", $sw) if $sw;




___

Reply to this item at:

  

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

[bug #65619] [afmtodit] want a default value for space width if unspecified

[G. Branden Robinson]

Update of bug #65619 (group groff):

Severity:  3 - Normal => 1 - Wish   
  Status:None => Invalid
 Assigned to:None => gbranden   
 Open/Closed:Open => Closed 
 Summary: Provide a default value for afmtodit(1) -w, when
unspecified => [afmtodit] want a default value for space width if unspecified

___

Follow-up Comment #2:

Looks like Deri's right.

Lines 28-37 and 485-487 seem to do this work.

https://git.savannah.gnu.org/cgit/groff.git/tree/src/utils/afmtodit/afmtodit.pl?h=1.23.0#n28
https://git.savannah.gnu.org/cgit/groff.git/tree/src/utils/afmtodit/afmtodit.pl?h=1.23.0#n485

Closing as invalid; the desired behavior is already present in _groff_ 1.23.0,
and in fact it looks like I'm the one who implemented it, back in November
2022, though I have no recollection of putting in the logic to deduce it from
the hash first.


commit 5a5a447b2a834f92112609a67821c1a37fdc66cd
Author: G. Branden Robinson 
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.


The other half of this is that output drivers will compute a space width even
if the font description files generated by _afmtodit_(1) lack them.


commit bf7f6862c384f9cff80737cccf6b8fafd4197e1c
Author: G. Branden Robinson 
Date:   Fri Sep 24 17:48:26 2021 +1000

[libgroff]: Make `spacewidth` mandatory.

* src/libs/libgroff/font.cpp (font::load): Throw error if a font
  description file is missing a `spacewidth` directive, since it is now
  re-documented as mandatory.  Atypically, we don't return false in this
  scenario; instead we proceed with the existing logic to compute a
  space width for the font based on typical practices for Western
  alphabetic fonts (see, e.g., .

Thanks to Deri James for the discussion.




___

Reply to this item at:

  

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