linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Problems building the unifont PFA and DIT files for the PDF book
@ 2024-04-20 12:26 Alejandro Colomar
  2024-04-20 15:52 ` G. Branden Robinson
       [not found] ` <2272286.muIFQpQJ8V@pip>
  0 siblings, 2 replies; 6+ messages in thread
From: Alejandro Colomar @ 2024-04-20 12:26 UTC (permalink / raw)
  To: linux-man, groff; +Cc: G. Branden Robinson, Deri James

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

Hi,

I've tried groff-ifying the Unifont, in the same way I do it with the
Tinos font.  However, I've had a few problems.

Here's the Tinos font that's packaged with Debian:

	$ apt-file find tinos | grep ttf
	texlive-fonts-extra-links: /usr/share/texlive/texmf-dist/fonts/truetype/google/tinos/Tinos-Bold.ttf
	texlive-fonts-extra-links: /usr/share/texlive/texmf-dist/fonts/truetype/google/tinos/Tinos-BoldItalic.ttf
	texlive-fonts-extra-links: /usr/share/texlive/texmf-dist/fonts/truetype/google/tinos/Tinos-Italic.ttf
	texlive-fonts-extra-links: /usr/share/texlive/texmf-dist/fonts/truetype/google/tinos/Tinos-Regular.ttf

And here's the Unifont:

	$ apt-file find unifont | grep otf | grep fonts | grep -v japanese
	fonts-unifont: /usr/share/fonts/opentype/unifont/unifont.otf
	fonts-unifont: /usr/share/fonts/opentype/unifont/unifont_csur.otf
	fonts-unifont: /usr/share/fonts/opentype/unifont/unifont_jp.otf
	fonts-unifont: /usr/share/fonts/opentype/unifont/unifont_jp_sample.otf
	fonts-unifont: /usr/share/fonts/opentype/unifont/unifont_sample.otf
	fonts-unifont: /usr/share/fonts/opentype/unifont/unifont_upper.otf
	fonts-unifont: /usr/share/fonts/opentype/unifont/unifont_upper_sample.otf

First problem:

In the Unifont, I don't see a "Regular" font.  I assumed I should take
the unifont.otf file.

Here's how I've been groff-ifying the Tinos font:

	$ make build-fonts-tinos -B --debug=pretty
	MKDIR		.tmp/fonts/devpdf/
	install -m 755 -d .tmp/fonts/devpdf/
	PFBTOPS		.tmp/fonts/devpdf/Tinos.pfa
	pfbtops </usr/share/texlive/texmf-dist/fonts/type1/google/tinos/Tinos.pfb >.tmp/fonts/devpdf/Tinos.pfa
	FONTFORGE	.tmp/fonts/devpdf/TinosR.afm
	fontforge   -lang=ff -c 'Open("/usr/share/texlive/texmf-dist/fonts/truetype/google/tinos/Tinos-Regular.ttf");Generate(".tmp/fonts/devpdf/TinosR.afm");'
	Copyright (c) 2000-2024. See AUTHORS for Contributors.
	 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
	 with many parts BSD <http://fontforge.org/license.html>. Please read LICENSE.
	 Version: 20230101
	 Based on sources from 2024-03-07 23:15 UTC-ML-D-GDK3.
	PythonUI_Init()
	copyUIMethodsToBaseTable()
	Program root: /usr
	The following table(s) in the font have been ignored by FontForge
	  Ignoring 'DSIG' digital signature table
	The glyph named null is mapped to U+0000.
	  But its name indicates it should be mapped to U+2400.
	The glyph named periodcentered is mapped to U+2219.
	  But its name indicates it should be mapped to U+00B7.
	The glyph named Delta is mapped to U+0394.
	  But its name indicates it should be mapped to U+2206.
	The glyph named Omega is mapped to U+03A9.
	  But its name indicates it should be mapped to U+2126.
	The glyph named mu is mapped to U+03BC.
	  But its name indicates it should be mapped to U+00B5.
	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: AGL name 'periodcentered' already mapped to groff name 'pc'; ignoring AGL name 'uni00B7'
	/usr/local/bin/afmtodit: both gravecomb and uni0340 map to u0300 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both acutecomb and uni0341 map to u0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both uni0313 and uni0343 map to u0313 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both uni02B9 and uni0374 map to u02B9 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both alphatonos and uni1F71 map to u03B1_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both epsilontonos and uni1F73 map to u03B5_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both etatonos and uni1F75 map to u03B7_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both iotatonos and uni1F77 map to u03B9_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both omicrontonos and uni1F79 map to u03BF_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both omegatonos and uni1F7D map to u03C9_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both Alphatonos and uni1FBB map to u0391_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both Epsilontonos and uni1FC9 map to u0395_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both Etatonos and uni1FCB map to u0397_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both iotadieresistonos and uni1FD3 map to u03B9_0308_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both Iotatonos and uni1FDB map to u0399_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both Upsilontonos and uni1FEB map to u03A5_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both dieresistonos and uni1FEE map to u00A8_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both Omicrontonos and uni1FF9 map to u039F_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both Omegatonos and uni1FFB map to u03A9_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both uni2000 and uni2002 map to u2002 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both uni2001 and uni2003 map to u2003 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both Ohm and uni2126 map to u03A9 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both uni1FE3 and upsilondieresistonos map to u03C5_0308_0301 at /usr/local/bin/afmtodit line 6586.
	/usr/local/bin/afmtodit: both uni1F7B and upsilontonos map to u03C5_0301 at /usr/local/bin/afmtodit line 6586.
	/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?

Well, apart from those warnings, that works.  Now, I repeat the process
with the Unifont:

	$ make build-fonts-unifont -B --debug=pretty
	MKDIR		.tmp/fonts/devpdf/
	install -m 755 -d .tmp/fonts/devpdf/
	FONTFORGE	.tmp/fonts/devpdf/Unifont.pfa
	fontforge   -lang=ff \
		-c 'Open("/usr/share/fonts/opentype/unifont/unifont.otf");Generate(".tmp/fonts/devpdf/Unifont.pfa");'
	Copyright (c) 2000-2024. See AUTHORS for Contributors.
	 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
	 with many parts BSD <http://fontforge.org/license.html>. Please read LICENSE.
	 Version: 20230101
	 Based on sources from 2024-03-07 23:15 UTC-ML-D-GDK3.
	PythonUI_Init()
	copyUIMethodsToBaseTable()
	Program root: /usr
	AFMTODIT	.tmp/fonts/devpdf/UnifontR
	afmtodit -e /usr/share/groff/current/font/devpdf/enc/text.enc .tmp/fonts/devpdf/Unifont.afm /usr/share/groff/current/font/devpdf/map/text.map .tmp/fonts/devpdf/UnifontR

Much nicer on stderr, which gave me hope at first.

But then I try to build the PDF book with both fonts.

	$ grep -rh -e Tinos -e 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";

And I get a warning about 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
	troff:fanotify_init.2:322: warning [page 192, 4.2i]: cannot adjust line
	troff:membarrier.2:272: warning [page 475, 3.0i]: cannot adjust line
	statx.2:240: warning: table wider than line length minus indentation
	troff:syscall.2:171: warning: cannot select font 'CW'
	troff:syscall.2:301: warning: cannot select font 'CW'
	troff:syscalls.2:205: warning [page 1074, 5.7i (diversion '3tbd17,0', 0.0i)]: cannot adjust line
	troff:syscalls.2:760: warning [page 1074, 5.7i (diversion '3tbd174,0', 0.0i)]: cannot break line
	troff:syscalls.2:1278: warning [page 1074, 5.7i (diversion '3tbd317,0', 0.0i)]: cannot break line
	^Cmake: *** [/home/alx/src/linux/man-pages/man-pages/contrib/share/mk/build/pdf/book/_.mk:39: .tmp/man-pages-6.7-70-gd80376b08.pdf] Interrupt

Did I do anything wrong with the Unifont?  I suspect of treating it as a
Regular font without any indication that I should.

(The Tinos changes are already in master.  The Unifont changes are in
 the contrib branch, since I'm not yet happy with them.)

Have a lovely day!
Alex

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

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: Problems building the unifont PFA and DIT files for the PDF book
  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:20   ` Alejandro Colomar
       [not found] ` <2272286.muIFQpQJ8V@pip>
  1 sibling, 2 replies; 6+ messages in thread
From: G. Branden Robinson @ 2024-04-20 15:52 UTC (permalink / raw)
  To: Alejandro Colomar; +Cc: linux-man, groff, G. Branden Robinson, Deri James

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

Hi Alex,

At 2024-04-20T14:26:17+0200, Alejandro Colomar wrote:
> First problem:
> 
> In the Unifont, I don't see a "Regular" font.  I assumed I should take
> the unifont.otf file.

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.

> 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: AGL name 'periodcentered' already mapped to groff name 'pc'; ignoring AGL name 'uni00B7'
> 	/usr/local/bin/afmtodit: both gravecomb and uni0340 map to u0300 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both acutecomb and uni0341 map to u0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both uni0313 and uni0343 map to u0313 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both uni02B9 and uni0374 map to u02B9 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both alphatonos and uni1F71 map to u03B1_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both epsilontonos and uni1F73 map to u03B5_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both etatonos and uni1F75 map to u03B7_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both iotatonos and uni1F77 map to u03B9_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both omicrontonos and uni1F79 map to u03BF_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both omegatonos and uni1F7D map to u03C9_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both Alphatonos and uni1FBB map to u0391_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both Epsilontonos and uni1FC9 map to u0395_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both Etatonos and uni1FCB map to u0397_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both iotadieresistonos and uni1FD3 map to u03B9_0308_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both Iotatonos and uni1FDB map to u0399_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both Upsilontonos and uni1FEB map to u03A5_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both dieresistonos and uni1FEE map to u00A8_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both Omicrontonos and uni1FF9 map to u039F_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both Omegatonos and uni1FFB map to u03A9_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both uni2000 and uni2002 map to u2002 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both uni2001 and uni2003 map to u2003 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both Ohm and uni2126 map to u03A9 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both uni1FE3 and upsilondieresistonos map to u03C5_0308_0301 at /usr/local/bin/afmtodit line 6586.
> 	/usr/local/bin/afmtodit: both uni1F7B and upsilontonos map to u03C5_0301 at /usr/local/bin/afmtodit line 6586.
> 	/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.

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
            the ignored AGL name contains four hexadecimal digits XXXX.
            The Adobe Glyph List (AGL) has its own names for glyphs;
            they are often different from groff’s special character
            names.  afmtodit is constructing a mapping from groff
            special character names to AGL names; this can be a one‐to‐
            one or many‐to‐one mapping, but one‐to‐many will not work,
            so afmtodit discards the excess mappings.  For example, if x
            is Delta, y is *D, and XXXX is 0394, afmtodit is telling you
            that the groff font description that it is writing cannot
            map the groff special character \[*D] to AGL glyphs Delta
            and uni0394 at the same time.

            If you get a message like this but are unhappy with which
            mapping is ignored, a remedy is to craft an alternative map‐
            file and re‐run afmtodit using it.

> 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.

If the formatter didn't discard spaces
at the ends of output lines, that would
defeat adjustment to both  margins,  as
one  can  observe in this example here.
Note the ragged margin ending the first
line.

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

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.

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".

[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.

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: Problems building the unifont PFA and DIT files for the PDF book
  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
  1 sibling, 1 reply; 6+ messages in thread
From: Brian Inglis @ 2024-04-20 20:11 UTC (permalink / raw)
  To: G. Branden Robinson, Alejandro Colomar
  Cc: linux-man, groff, G. Branden Robinson, Deri James

On 2024-04-20 09:52, G. Branden Robinson wrote:
> At 2024-04-20T14:26:17+0200, Alejandro Colomar wrote:
>> First problem:
>>
>> In the Unifont, I don't see a "Regular" font.  I assumed I should take
>> the unifont.otf file.

Hi folks,

That's the BMP ~63.5k characters ~57k glyphs; unifont_upper are the SMP ~57.5k 
glyphs with specialized scripts and extended graphics like emojis: unlikely to 
be required for any LGC man pages.

		https://unifoundry.com/unifont/index.html

> 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.
> 
>> 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: AGL name 'periodcentered' already mapped to groff name 'pc'; ignoring AGL name 'uni00B7'
>> 	/usr/local/bin/afmtodit: both gravecomb and uni0340 map to u0300 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both acutecomb and uni0341 map to u0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both uni0313 and uni0343 map to u0313 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both uni02B9 and uni0374 map to u02B9 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both alphatonos and uni1F71 map to u03B1_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both epsilontonos and uni1F73 map to u03B5_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both etatonos and uni1F75 map to u03B7_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both iotatonos and uni1F77 map to u03B9_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both omicrontonos and uni1F79 map to u03BF_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both omegatonos and uni1F7D map to u03C9_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both Alphatonos and uni1FBB map to u0391_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both Epsilontonos and uni1FC9 map to u0395_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both Etatonos and uni1FCB map to u0397_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both iotadieresistonos and uni1FD3 map to u03B9_0308_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both Iotatonos and uni1FDB map to u0399_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both Upsilontonos and uni1FEB map to u03A5_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both dieresistonos and uni1FEE map to u00A8_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both Omicrontonos and uni1FF9 map to u039F_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both Omegatonos and uni1FFB map to u03A9_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both uni2000 and uni2002 map to u2002 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both uni2001 and uni2003 map to u2003 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both Ohm and uni2126 map to u03A9 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both uni1FE3 and upsilondieresistonos map to u03C5_0308_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/usr/local/bin/afmtodit: both uni1F7B and upsilontonos map to u03C5_0301 at /usr/local/bin/afmtodit line 6586.
>> 	/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.
> 
> 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
>              the ignored AGL name contains four hexadecimal digits XXXX.
>              The Adobe Glyph List (AGL) has its own names for glyphs;
>              they are often different from groff’s special character
>              names.  afmtodit is constructing a mapping from groff
>              special character names to AGL names; this can be a one‐to‐
>              one or many‐to‐one mapping, but one‐to‐many will not work,
>              so afmtodit discards the excess mappings.  For example, if x
>              is Delta, y is *D, and XXXX is 0394, afmtodit is telling you
>              that the groff font description that it is writing cannot
>              map the groff special character \[*D] to AGL glyphs Delta
>              and uni0394 at the same time.
> 
>              If you get a message like this but are unhappy with which
>              mapping is ignored, a remedy is to craft an alternative map‐
>              file and re‐run afmtodit using it.
> 
>> 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.
> 
> If the formatter didn't discard spaces
> at the ends of output lines, that would
> defeat adjustment to both  margins,  as
> one  can  observe in this example here.
> Note the ragged margin ending the first
> line.
> 
> afmtodit(1):
>       -w space‐width
>              Use space‐width as the width of inter‐word spaces.
> 
> 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.

OpenType fonts are normally designed with an 1000 units/em, and Truetype may be 
1024 or 2048 units/em, so should use 333 or maybe 300 if you prefer a tighter 
look, close to your suggestion.

$ ttfdump /usr/share/fonts/urw-base35/NimbusRoman-Regular.otf | awk "/'head'/,/^$/"
    6. 'head' - checksum = 0x0cdb53f2, offset = 0x00016f4c, len =        54
    7. 'hhea' - checksum = 0x06b6057b, offset = 0x00016f84, len =        36
    8. 'hmtx' - checksum = 0x35d9ae6c, offset = 0x00016fa8, len =      3420
    9. 'maxp' - checksum = 0x03575000, offset = 0x00017d04, len =         6
   10. 'name' - checksum = 0x8993f63c, offset = 0x00017d0c, len =       620
   11. 'post' - checksum = 0xffb10032, offset = 0x00017f78, len =        32

'head' Table - Font Header
--------------------------
          'head' version:         1.0
          fontReversion:          1.0
          checkSumAdjustment:     0x69d6e98e
          magicNumber:            0x5f0f3cf5
          flags:                  0x0003
          unitsPerEm:             1000
          created:                0x00000000d5420807
          modified:               0x00000000d5420807
          xMin:                   -168
          yMin:                   -281
          xMax:                   1000
          yMax:                   1053
          macStyle bits:          0x0000
          lowestRecPPEM:          3
          fontDirectionHint:      2
          indexToLocFormat:       0
          glyphDataFormat:        0

For comparison Tinos ttf substitute for Times Roman:

$ ttfdump /usr/share/fonts/tinos/Tinos-Regular.ttf | awk "/'head'/,/^$/"
   12. 'head' - checksum = 0x0bd978fc, offset = 0x0000015c, len =        54
   13. 'hhea' - checksum = 0x19811ca6, offset = 0x00000194, len =        36
   14. 'hmtx' - checksum = 0xa4bce0e7, offset = 0x00000238, len =     13116
   15. 'kern' - checksum = 0xa39da9f5, offset = 0x0008d6f8, len =      5220
   16. 'loca' - checksum = 0x28e2bf88, offset = 0x0001a45c, len =     13120
   17. 'maxp' - checksum = 0x10d405bc, offset = 0x000001b8, len =        32
   18. 'name' - checksum = 0xc3ff0ad5, offset = 0x0008eb5c, len =      2052
   19. 'post' - checksum = 0xe841b7c5, offset = 0x0008f360, len =     34664
   20. 'prep' - checksum = 0xbd48485c, offset = 0x00019b40, len =      1550

'head' Table - Font Header
--------------------------
          'head' version:         1.0
          fontReversion:          1.20736
          checkSumAdjustment:     0x84b246c2
          magicNumber:            0x5f0f3cf5
          flags:                  0x001b
          unitsPerEm:             2048
          created:                0x00000000c844d0ce
          modified:               0x00000000d25f0c4c
          xMin:                   -1114
          yMin:                   -797
          xMax:                   5728
          yMax:                   2068
          macStyle bits:          0x0000
          lowestRecPPEM:          9
          fontDirectionHint:      2
          indexToLocFormat:       1
          glyphDataFormat:        0

> [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".
> 
> [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.

But Unifont uses 64 units/em, so 20-21?

$ ttfdump /usr/share/fonts/opentype/unifont/unifont.otf | awk '/head/,/^$/'
    5. 'head' - checksum = 0x5f163d75, offset = 0x000000bc, len =        54
    6. 'hhea' - checksum = 0x003adf37, offset = 0x000000f4, len =        36
    7. 'hmtx' - checksum = 0x3eb11f30, offset = 0x004a6b34, len =    228344
    8. 'maxp' - checksum = 0xdefe5000, offset = 0x00000118, len =         6
    9. 'name' - checksum = 0x5aec7895, offset = 0x00000184, len =      1000
   10. 'post' - checksum = 0x00030002, offset = 0x00000604, len =        32

'head' Table - Font Header
--------------------------
          'head' version:         1.0
          fontReversion:          0.0
          checkSumAdjustment:     0x3e8fcc29
          magicNumber:            0x5f0f3cf5
          flags:                  0x0003
          unitsPerEm:             64
          created:                0x0000000000000000
          modified:               0x0000000000000000
          xMin:                   -64
          yMin:                   -8
          xMax:                   64
          yMax:                   56
          macStyle bits:          0x0000
          lowestRecPPEM:          16
          fontDirectionHint:      2
          indexToLocFormat:       0
          glyphDataFormat:        0

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: Problems building the unifont PFA and DIT files for the PDF book
  2024-04-20 15:52 ` G. Branden Robinson
  2024-04-20 20:11   ` Brian Inglis
@ 2024-04-20 22:20   ` Alejandro Colomar
  1 sibling, 0 replies; 6+ messages in thread
From: Alejandro Colomar @ 2024-04-20 22:20 UTC (permalink / raw)
  To: G. Branden Robinson; +Cc: linux-man, groff, G. Branden Robinson, Deri James

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: Problems building the unifont PFA and DIT files for the PDF book
  2024-04-20 20:11   ` Brian Inglis
@ 2024-04-20 22:32     ` Alejandro Colomar
  0 siblings, 0 replies; 6+ messages in thread
From: Alejandro Colomar @ 2024-04-20 22:32 UTC (permalink / raw)
  To: Brian Inglis
  Cc: G. Branden Robinson, linux-man, groff, G. Branden Robinson, Deri James

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

Hi Brian,

On Sat, Apr 20, 2024 at 02:11:55PM -0600, Brian Inglis wrote:
> On 2024-04-20 09:52, G. Branden Robinson wrote:
> > At 2024-04-20T14:26:17+0200, Alejandro Colomar wrote:
> > > First problem:
> > > 
> > > In the Unifont, I don't see a "Regular" font.  I assumed I should take
> > > the unifont.otf file.
> 
> Hi folks,
> 
> That's the BMP ~63.5k characters ~57k glyphs; unifont_upper are the SMP
> ~57.5k glyphs with specialized scripts and extended graphics like emojis:
> unlikely to be required for any LGC man pages.
> 
> 		https://unifoundry.com/unifont/index.html

Thanks!

> > 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.
> > 

[...]

> OpenType fonts are normally designed with an 1000 units/em, and Truetype may
> be 1024 or 2048 units/em, so should use 333 or maybe 300 if you prefer a
> tighter look, close to your suggestion.
> 
> $ ttfdump /usr/share/fonts/urw-base35/NimbusRoman-Regular.otf | awk "/'head'/,/^$/"
>    6. 'head' - checksum = 0x0cdb53f2, offset = 0x00016f4c, len =        54
>    7. 'hhea' - checksum = 0x06b6057b, offset = 0x00016f84, len =        36
>    8. 'hmtx' - checksum = 0x35d9ae6c, offset = 0x00016fa8, len =      3420
>    9. 'maxp' - checksum = 0x03575000, offset = 0x00017d04, len =         6
>   10. 'name' - checksum = 0x8993f63c, offset = 0x00017d0c, len =       620
>   11. 'post' - checksum = 0xffb10032, offset = 0x00017f78, len =        32
> 
> 'head' Table - Font Header
> --------------------------
>          'head' version:         1.0
>          fontReversion:          1.0
>          checkSumAdjustment:     0x69d6e98e
>          magicNumber:            0x5f0f3cf5
>          flags:                  0x0003
>          unitsPerEm:             1000
>          created:                0x00000000d5420807
>          modified:               0x00000000d5420807
>          xMin:                   -168
>          yMin:                   -281
>          xMax:                   1000
>          yMax:                   1053
>          macStyle bits:          0x0000
>          lowestRecPPEM:          3
>          fontDirectionHint:      2
>          indexToLocFormat:       0
>          glyphDataFormat:        0
> 
> For comparison Tinos ttf substitute for Times Roman:
> 
> $ ttfdump /usr/share/fonts/tinos/Tinos-Regular.ttf | awk "/'head'/,/^$/"
>   12. 'head' - checksum = 0x0bd978fc, offset = 0x0000015c, len =        54
>   13. 'hhea' - checksum = 0x19811ca6, offset = 0x00000194, len =        36
>   14. 'hmtx' - checksum = 0xa4bce0e7, offset = 0x00000238, len =     13116
>   15. 'kern' - checksum = 0xa39da9f5, offset = 0x0008d6f8, len =      5220
>   16. 'loca' - checksum = 0x28e2bf88, offset = 0x0001a45c, len =     13120
>   17. 'maxp' - checksum = 0x10d405bc, offset = 0x000001b8, len =        32
>   18. 'name' - checksum = 0xc3ff0ad5, offset = 0x0008eb5c, len =      2052
>   19. 'post' - checksum = 0xe841b7c5, offset = 0x0008f360, len =     34664
>   20. 'prep' - checksum = 0xbd48485c, offset = 0x00019b40, len =      1550
> 
> 'head' Table - Font Header
> --------------------------
>          'head' version:         1.0
>          fontReversion:          1.20736
>          checkSumAdjustment:     0x84b246c2
>          magicNumber:            0x5f0f3cf5
>          flags:                  0x001b
>          unitsPerEm:             2048
>          created:                0x00000000c844d0ce
>          modified:               0x00000000d25f0c4c
>          xMin:                   -1114
>          yMin:                   -797
>          xMax:                   5728
>          yMax:                   2068
>          macStyle bits:          0x0000
>          lowestRecPPEM:          9
>          fontDirectionHint:      2
>          indexToLocFormat:       1
>          glyphDataFormat:        0
> 
> > [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".
> > 
> > [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.
> 
> But Unifont uses 64 units/em, so 20-21?

Thanks!!!

I've tried to build the Chinese man-pages book for shadow, but I still
don't get Chinese letters, so I wasn't able to test this value, but I'll
try debugging it in the following days.

Anyway, I've applied this value in a commit that I'll push tomorrow to
the Linux man-pages' master branch.

Have a lovely night!
Alex

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

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: Problems building the unifont PFA and DIT files for the PDF book
       [not found] ` <2272286.muIFQpQJ8V@pip>
@ 2024-04-21 20:08   ` Alejandro Colomar
  0 siblings, 0 replies; 6+ messages in thread
From: Alejandro Colomar @ 2024-04-21 20:08 UTC (permalink / raw)
  To: Deri; +Cc: G. Branden Robinson, linux-man

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

Hi Deri,

On Sun, Apr 21, 2024 at 08:58:03PM +0100, Deri wrote:
> This is one of Branden's changes to groff. Previously a missing spacewidth parameter was 
> ignored and groff would calculate a value. As far as I know noone has ever complained 
> about the typography groff produced when using a font with no spacewidth parameter, it 
> is now an error, but it does not stop it computing a value and continuing. For pdf and ps, 
> using the default DESC files for the devices, the computed value is 333.
> 
> However, UnifontM is a bit mapped mono font where all western glyphs have a width of 
> 500, so it would make sense edit that value into the UnifontM file by hand. For other 
> language glyphs the fixed width is 1000 but they don't normally need a space character 
> between glyphs, but you can adjust with .ss if necessary.
> 
> I would advise to use:-
> 
> .special TINOR UnifontM S

Yep, I used that order, following the patch you sent me a few weeks ago.

BTW, why do you call it TINOR and not TinosR?  Also, why UnifontM and
not UnifontR?  What's that M mean?

> Since this is the order you would like the fonts searched, typographically TINOR is much 
> better than UnifontM because the glyphs are drawn not bit mapped, so if a glyph exists in 
> both prefer to use TINOR.

Yep.

> If you want to produce man pages in CJK languages, it would be much better to install a 
> proper CJK font rather than rely on UnifontM, I suggested to use it to fill the gaps in the 
> iso-8859 pages. Now you want complete pages in other languages for shadow, you 
> should consider installing an appropriate font. I have attached two pdfs, one using 
> UnifontM and the other a proper CJK font. If you use your pdf viewers zoom control you 
> will soon see the difference in quality.

Yeah, I was looking for a font that's in a common Debian package.  I
found some, but they were in very obscure packages that I prefer not to
depend on.  I'll keep searching.

Have a lovely night!
Alex

> Cheers 
> 
> Deri

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

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-04-21 20:08 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
     [not found] ` <2272286.muIFQpQJ8V@pip>
2024-04-21 20:08   ` Alejandro Colomar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).