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

Re: How to create a PDF-Printer from the command line

On Wed 10 Jan 2018 at 10:46:43 (+0100), tomas@tuxteam.de wrote:
> On Wed, Jan 10, 2018 at 09:02:08AM +0000, Curt wrote:
> [...]
> >  You (a thirty-year veteran latex user we learn elsewhere): Please explain the
> >  first step (which is how to create a latex file).
> > 
> > > than TeX/LaTeX is a useless way to turn a *text* file into a PDF.
> Perhaps the conflict can be tackled better by making something
> explicit what has been implicit all along: is (La)TeX text, or
> is it not? Both standpoints exist, and this dichotomy can even
> be seen in the mime types database y'all have received as a
> present with your distribution; but note some peculiarity:
>   tomas@trotzki:~$ egrep '\<(la)?tex\>' /etc/mime.types 
>   application/x-latex                             latex
>   application/x-tex-gf                            gf
>   application/x-tex-pk                            pk
>   text/vnd.latex-z
>   text/x-tex                                      tex ltx sty cls
> Note something? (I'm ignoring for the moment .gf and .pk, which
> arguably can be seen as binary for now). LaTeX goes under the
> umbrella "application" (ain't text) and tex (with its LaTeX
> sibling sty and LaTeX-3 sibling .cls) under "text". What is
> going on here?
> A couple of years ago, XML seemed like the promise from the
> future, I was looking how to serve XML files over HTTP. For me
> (coming from a more Unix-y and free background) it was clearly
> "text": everything I can grab at with my vi(m) or Emacs is text,
> and XML, though slightly disgusting at times, fell squarely into
> that category. So "text/xml" shall it be.
> My surprise was not small when I realized that clients from the
> Microsoft camp nearly freaked out at that proposal. They wanted
> "application/xml".
> To me, this was a clear culture clash between a DIY, think-for-
> yourself culture (hey, it's text: just throw an editor at it
> and hack at it) versus an authoritarian one ("only use
> with vendor-approved software; warranty void, and if we ever
> find out how (DMCA?), we'll send the black helicopters"[1])
> Yeah. Both standpoints exist, and I think we should respect
> each other and just acknowledge the difference.
> But for me, (La)TeX *are* text :-)

Yes, you can put me in the text camp, and a little further over
than you, I believe. I have several extensions in my ~/.mime-types
which are set to "text/plain" which means (in mutt, anyway) that
such attachments are displayed just as if they were email text.
latex wasn't in that list only because I'm not in the habit of
attaching LaTeX files—I would attach the generated PDF. But thanks
for the heads-up.

>From the point of view of the OP and this thread, it's self-evident
that the output PDF was required to contain a listing of the text
file itself, *not* the results of its interpretation by software
that just happens to produce PDF-formatted files amongst its output.

A possibly sensible method involving LaTeX (if that happened to be
installed on the target system) might be to post some boilerplate
code that could be used to top and tail the original file; this
would likely involve \verbatim directives and suchlike. Not having
used it like that, I have no idea how generalised that could be made.

But that's very different from suggesting feeding the raw file to
fooLaTeX and seeing what comes out of the other end. Different, too,
from saying that if it happens to be valid LaTeX code, process it
and print the output instead. The latter might produce


in 30 point bold Palatino, whereas a listing should contain a line like

\mychapter{Program summary}

I might just mention that many of us will have experience of
pretty-printing (IIRC a2ps can do that) which is a halfway house:
suitable text files are constrained in their contents (typically
they are source code to some programming language) but processed
by the printing system to improve its readability. It's certainly
*not* processed by the target interpreter/compiler.


Reply to: