Re: Problems building the unifont PFA and DIT files for the PDF book

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 6415 bytes --]

Hi Branden,

On Sat, Apr 20, 2024 at 10:52:31AM -0500, G. Branden Robinson wrote:
> Since (I believe I saw you say that) you're using GNU Unifont only to
> patch up missing code point coverage from other fonts, in your
> application it probably makes sense to specify it as a "special" font.
> 
> afmtodit(1):
>      The -s option should be given if the font is “special”, meaning
>      that groff should search it whenever a glyph is not found in the
>      current font.  In that case, font‐description‐file should be listed
>      as an argument to the fonts directive in the output device’s DESC
>      file; if it is not special, there is no need to do so, since
>      troff(1) will automatically mount it when it is first used.
> [...]
>      -s     Add the special directive to the font description file.
> 
> I see that the foregoing advice is incomplete: updating the output
> device's "DESC" file is only one approach; another is to add a `special`
> request to the document, and that's the one I suggest you take for your
> man pages book.
> 
> So you might put
> 
> .special Unifont
> 
> in your front.groff file or similar.

Thanks!  Yep, I'm using it (thanks to Deri):

$ grep -rh Unifont share/mk/build/pdf/book/
	print ".pdfpagenumbering D . 1\n.nr PDFOUTLINE.FOLDLEVEL 0\n.defcolor pdf:href.colour rgb 0.00 0.25 0.75\n.pdfinfo /Title \"The Linux man-pages Book\"\n.special TinosR UnifontR S\n";

> > Here's how I've been groff-ifying the Tinos font:
> > 	AFMTODIT	.tmp/fonts/devpdf/TinosR
> > 	afmtodit -e /usr/share/groff/current/font/devpdf/enc/text.enc .tmp/fonts/devpdf/TinosR.afm /usr/share/groff/current/font/devpdf/map/text.map .tmp/fonts/devpdf/TinosR
> > 	/usr/local/bin/afmtodit: AGL name 'mu' already mapped to groff name 'mc'; ignoring AGL name 'uni00B5'

[...]

> > 	/usr/local/bin/afmtodit: both patah and yodyod_patah map to u05B7 at /usr/local/bin/afmtodit line 6586.
> > 
> > Are any of those warnings something I should take care of?  Or should
> > I just ignore them?  If they're unimportant, can I ask that low
> > severity warnings not be printed?  Or should I just 2>/dev/null?
> 
> The afmtodit(1) man page, and groff's "PROBLEMS" file (in the source
> distribution, since these warnings can arise when building groff)
> address this point.  Whether it's a problem depends on what you wanted.

Thanks.

> afmtodit(1):
> 
> Diagnostics
>      AGL name 'x' already mapped to groff name 'y'; ignoring AGL name
>      'uniXXXX'
>             You can disregard these if they’re in the form shown, where

This still leaves undocumented the warnings of the form

	both patah and yodyod_patah map to u05B7 at /usr/local/bin/afmtodit line 6586.

I guess I should ignore them too...

> > Well, apart from those warnings, that works.  Now, I repeat the process
> > with the Unifont:
> [...]
> > 	$ make build-pdf-book
> > 	GROPDF		.tmp/man-pages-6.7-70-gd80376b08.pdf
> > 	troff:.tmp/fonts/devpdf/UnifontR: error: font description 'spacewidth' directive missing
> [...]
> > Did I do anything wrong with the Unifont?  I suspect of treating it as a
> > Regular font without any indication that I should.
> 
> No, you simply need to tell groff how wide a space should be in that
> font.  In groff, a space is not a kind of glyph, because it doesn't put
> any "ink" on the "page"; instead it's a (discardable) horizontal
> motion.[1]  "Discardable" because if it occurs at the end of an output
> line, it is discarded.

[...]

> afmtodit(1):
>      -w space‐width
>             Use space‐width as the width of inter‐word spaces.

Hmmm, why did TinosR not trigger a warning about it?  I didn't specify
that either.  Do some fonts come with a predetermined space-width and
others not?

> 
> You will probably want to know what number to use for a font's space
> width.  This is a judgment typographers make.  The groff Texinfo manual
> and groff_diff(7) page share a rule of thumb.
> 
>      .ss word‐space‐size [additional‐sentence‐space‐size]
>             A second argument sets the amount of additional space
>             separating sentences on the same output line.  If omitted,
>             this amount is set to word‐space‐size.  Both arguments are
>             in twelfths of current font’s space width (typically one‐
>             fourth to one‐third em for Western scripts; see
>             groff_font(5)).  The default for both parameters is 12.
>             Negative values are erroneous.
> 
> My approach is to generate the font description file _without_
> the `-w` option, then read the resulting to file to see how wide the
> glyphs are.
> 
> If I do this for the URW Times roman font:
> 
> $ grep '^M' build/font/devpdf/TR
> M       889,662 2       77      M       --      004D
> 
> I can see that the "M" is 889 basic units wide (see groff_font(5) for an
> explanation of this file format and its terminology).
> 
> One third of 889 (rounded to an integer) is 296, so, personally, I'd say
> "-w 296".  But in principle, any value between 223 and 296 is "sound",
> and ultimately, the "correct" value is whatever best pleases you as a
> typographer when considering your document.  It's also worth noting that
> when adjustment is enabled, as is the case in AT&T and GNU troffs by
> default, an inter-word space will seldom be _exactly_ this "spacewidth"
> in any case, except where the document (or a macro package) has
> explicitly disabled adjustment.

Thanks!

> 
> Regards,
> Branden
> 
> [1] I do observe that the URW font descriptions shipped by groff include
>     a special character called "space".  Syntactically, this would be
>     accessed within a groff document via a special character escape
>     sequence: `\[space]`.  I've never seen a document do this.  I admit
>     that I don't have any idea why this is present or what its semantics
>     are: I need a PostScript or PDF expert to tell me.[2]  It does occur
>     to me that we might enhance afmtodit make of use of it as the
>     default "spacewidth".

That sounds like a great idea.

Have a lovely night!
Alex

> [2] Or I can self-help; I have copies of the _PostScript Language
>     Reference Manual_ (3rd ed.) and a version of ISO 32000 lying around.



-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]