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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux