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:
signature.asc
Description: PGP signature
