From: Alejandro Colomar <alx@kernel.org>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: linux-man@vger.kernel.org, groff@gnu.org,
"G. Branden Robinson" <branden@debian.org>,
Deri James <deri@chuzzlewit.myzen.co.uk>
Subject: Re: Problems building the unifont PFA and DIT files for the PDF book
Date: Sun, 21 Apr 2024 00:20:02 +0200 [thread overview]
Message-ID: <ZiQ_mTQHPq3ig723@debian> (raw)
In-Reply-To: <20240420155231.hwvoxfyqnefimh3s@illithid>
[-- 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 --]
next prev parent reply other threads:[~2024-04-20 22:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-20 12:26 Problems building the unifont PFA and DIT files for the PDF book Alejandro Colomar
2024-04-20 15:52 ` G. Branden Robinson
2024-04-20 20:11 ` Brian Inglis
2024-04-20 22:32 ` Alejandro Colomar
2024-04-20 22:20 ` Alejandro Colomar [this message]
[not found] ` <2272286.muIFQpQJ8V@pip>
2024-04-21 20:08 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZiQ_mTQHPq3ig723@debian \
--to=alx@kernel.org \
--cc=branden@debian.org \
--cc=deri@chuzzlewit.myzen.co.uk \
--cc=g.branden.robinson@gmail.com \
--cc=groff@gnu.org \
--cc=linux-man@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.