Re: PDF book of unreleased pages (was: strncpy clarify result may not be null terminated)

G. Branden Robinson
2023-11-20T00:46:41Z

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

Hi Alex and Deri,

I'm going to address just a few small parts of this message...

At 2023-11-19T21:58:03+0100, Alejandro Colomar wrote:
> You can always `find ... | xargs cat | troff /dev/stdin`

...not if you need to preprocess any of the input. With tbl(1), for
instance.

> My problem is probably that I don't know what's done by `gropdf`, and
> what's done by `troff -Tpdf`. I was hoping that `troff -Tpdf` still
> didn't need to know about the entire book, and that only gropdf(1)
> would need that.

This stuff is documented in groff's Texinfo manual, and in the groff(1)
and roff(7) man pages.

Here's an excerpt of the last.

Using roff
When you read a man page, often a roff is the program rendering
it. Some roff implementations provide wrapper programs that make
it easy to use the roff system from the shell’s command line.
These can be specific to a macro package, like mmroff(1), or more
general. groff(1) provides command‐line options sparing the user
from constructing the long, order‐dependent pipelines familiar to
AT&T troff users. Further, a heuristic program, grog(1), is
available to infer from a document’s contents which groff
arguments should be used to process it.

The roff pipeline
A typical roff document is prepared by running one or more
processors in series, followed by a a formatter program and then
an output driver (or “device postprocessor”). Commonly, these
programs are structured into a pipeline; that is, each is run in
sequence such that the output of one is taken as the input to the
next, without passing through secondary storage. (On non‐Unix
systems, pipelines may have to be simulated with temporary
files.)

$ preproc1 < input‐file | preproc2 | ... | troff [option] ... \
| output‐driver

Once all preprocessors have run, they deliver pure roff language
input to the formatter, which in turn generates a document in a
page description language that is then interpreted by a
postprocessor for viewing, printing, or further processing.

gropdf(1) is the output driver for the PDF "device". So "groff -T pdf
input.tr" and "troff -T pdf input.tr | gropdf" are equivalent.

(Yes, you still need the `-T pdf` arguments, even to troff proper.

roff(7) again:

Concepts
[...]
When a device‐independent roff formatter starts up, it obtains
information about the device for which it is preparing output
from the latter’s description file (see groff_font(5)). An
essential property is the length of the output line, such as “6.5
inches”.
)

> > Your model of slicing and dicing man pages to be processed
> > individually is doable using a website to serve the individual
> > pages, see:-
> >
> > http://chuzzlewit.co.uk/WebManPDF.pl/man:/2/accept
> >
> > This is running on a 1" cube no more powerful than a raspberry pi 3.
> > The difference is that the "magic sauce" added to each man page sets
> > the links to external http calls back to itself to produce another
> > man page, rather than internal links to another part of the pdf. You
> > can get an index of all the man pages, on the (very old) system,
> > here.
> >
> > http://chuzzlewit.co.uk/
>
> Yep, I've seen that server :)

Is it just me, or are the fonts not getting embedded in the PDFs
generated by chuzzlewit? They look fine on my desktop machine but
pretty bad on my Android tablet.

Regards,
Branden