Re: Linux man-pages PDF book

[Alejandro Colomar <alx@kernel.org>]

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

[CC += linux-man@]

Hi Deri,

On Tue, Apr 16, 2024 at 01:14:12AM +0100, Deri wrote:
> > Maybe we could do the same, to reduce the work of prepare.pl?
> 
> Hi Alex,
> 
> Feel free to have a go. These are the main differences between groff-man-pages 
> (GM) and your book (LM):-
> 
> GM uses -mandoc not -man (by piping custom an.tmac).

I thought of using -mandoc too, for supporting other's pages, possibly
written in mdoc(7).  It shouldn't hurt.

> LM has separate sections so .TH should use bookmark level 2 (not 1).

Hmm.

> (git an.tmac now has:-
> 
> .\" Customize this at the command line to, for example, group multiple
> .\" man pages within a collection or containing document.
> .nr an*bookmark-base-level 0
> 
> so maybe the last stopper from using git head's an.tmac can be circumvented 
> (except of course it won't work - overwritten by zero!!!)).
> 
> GM uses .MR to handle intra-page links, LM uses .pdfhref L. As your desperate 
> to use Branden's code rather than mine,

It's not about using Branden's code or yours.  It's about not having to
effectively maintain a fork of a huge file in the Linux man-pages git
repository, of which I understand little.

> I'll attach a patch which drops 
> an.tmac and uses the HEAD version - you may be disappointed.

I applied a patch earlier today to do this:
<https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=a5c977a5bd3b7b705f4b91f3b375cc68d7122331>

I know the behavior is worse than with the fork that you contributed,
but I've reported the bug to Branden, and I expect he should fix it soon
(especially when you have explained the reason and the fix (and the
reason why his fix didn't work) in your email).

> I don't understand what your doing with the font, why convert to .pfa, why 
> move it - if you have the font just put texlive path into the download file in 
> .tmp/font/devpdf with TINOSR.

I don't understand it either.  That was the reason.  :)
Since you sent me a .pfa file, I kept having a .pfa file.  Nobody told
me I could just use a .pfb.

> The an.patch can be applied to groff, to restore your original section 
> hierarchy.

Thanks!  Branden, would you mind picking it?

> The shadow.patch can be applied to shadow which allows the book to 
> be built without my custom an.tmac, using the patched version.

I see that your patch does more than mine.  It uses pdfmom(1) instead of
troff(1), and it also changes prepare.pl.  Would you mind explaining why
is that done, or why is it necessary?  My patch, which is as simple as
using -man and droping an.tmac, seems to be working as well as before
(except for the section bookmarks).  Although I didn't check thoroughly
the shadow PDF; I may find more problems there, maybe?

> > Hmmm.  Your obvservation about matching the PDF navigator makes sense.
> > Deri, was the removal of -rC1 on purpose?
> 
> I don't really know, since you removed it, so I can't answer as to your 
> intention. The original single perl script which did the whole job had it in:-
> 
>  open(BK,"| ./test-pdfmake -Tpdf -k -pet -M. -mandoc -fTINO -F/usr/share/
> groff/site-font -manmark -rC1 -rCHECKSTYLE=3 > LinuxManBook.pdf");
> 
> You then deconstructed the script for your own edification, and at one stage 
> this was the result:-
> 
> #!/bin/sh
> # Copyright 2023, Alejandro Colomar <alx@kernel.org>
> # SPDX-License-Identifier: GPL-3.0-or-later
> 
> (
>         "$(dirname "$0")"/prepare_linux_man_book.pl "$1" \
>         | preconv \
>         | pic \
>         | tbl \
>         | eqn -Tpdf \
>         | troff -Tpdf -dPDF.EXPORT=1 -dLABEL.REFS=1 -dpaper=a4 \
>                 -M"$(dirname "$0")" -mandoc -manmark -rC1 -rCHECKSTYLE=3 \
>                 2>&1 >/dev/null \
>         | LC_ALL=C grep '^\. *ds ';
> 
>         "$(dirname "$0")"/prepare_linux_man_book.pl "$1";
> ) \
> | preconv \
> | pic \
> | tbl \
> | eqn -Tpdf \
> | (
>         troff -Tpdf -ms <"$(dirname "$0")"/LMBfront.ms;
>         troff -Tpdf -M"$(dirname "$0")" -mandoc -manmark \
>                 -F"$(dirname "$0")" -dpaper=a4 ;
> ) \
> | gropdf -F"$(dirname "$0")" -pa4;
> 
> You can see you have chosen to omit the -rC1 from the second run.

Hmmm, my bad.  I didn't know that it was necessary to specify it in
both runs.

> Then when 
> you decided a need for speed, I rewrote again a single pass version which did 
> not rely on Branden's .MR code at all. Now you want to use similar code as 
> used for the groff_man_pages book (back to using calls to .MR and using pdfmom 
> --roff to satisfy forward references).

Not really.  What I want is to have the script be as simple as possible.
The main problem is that I need to maintain it, but I have little
knowledge of perl(1) (or of PDF or roff(7), BTW).

> > I removed the Tinos.pfa file, since now I generate it at build time
> > from the Tinos.pfb file (installed with Debian's texlive-fonts-extra).
> 
> Completely unnecessary! Gropdf can use .pfb files.

Hmmm.  Didn't know.  Thanks!

> > Either the reorganization, or the generation of the font results in a
> > new warning:
> > 
> > troff:<standard input>:1649: error: cannot load font 'TINOR' to mark it as
> > special
> > 
> 
> Your _FONTSDIR must point to a directory which has a subdirectory called 
> 'devpdf' which holds TINOR and UnifontM and a suitable 'download' file which 
> gives the location of the actual .pf[ab] files (i.e. within texlive - no need 
> to copy it). The difference, with/without, is in the number of glyphs not 
> found messages.

I also need to understand what's that TINOR file, what type of file it
is, and how I can get it.  You gave me two files: the .pfa, and TINOR.
So I can use a .pfb instead of the .pfa; but what about the TINOR file?
How can I get it without maintaining a fork of it?  Also, how can I get
the Unifont files?  I don't see any .pfa or .pfb in any unifont
packages.

alx@debian:~$ apt-file show -x .*unifont.* | grep -i -e pfa -e pfb
alx@debian:~$ 

> 
> Cheers
> 
> Deri

Have a lovely night!
Alex

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

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