[pdftex] PTEX.FileName contains file system information
James Quirk
jjq at galcit.caltech.edu
Sun Aug 5 04:36:13 CEST 2007
On Sun, 5 Aug 2007, Reinhard Kotucha wrote:
> Stephan Hennig writes:
>
> > Hi,
>
> > when an external pdf graphics is included into a LaTeX document with the
> > line
>
> > \includegraphics{pic}
> >
> > the resulting file contains a line
>
> >> /PTEX.FileName (pic.pdf)
>
> > That is, the names of imported pdf files can be seen in the output file
> > by inspecting it with an editor. What is the rationale for putting file
> > system related information into pdf output?
>
> This information can be used by a PDF post-processor in order to
> process included graphics separately.
>
> I assume that you have document security in mind. But /PTEX.FileName
I think Stephan was more concerned by the fact that if he
wrote a review, using pdftex, the recipient of the review
might look at the PDF and see a pathname that gave away
his identity. This is a legitimate concern. Hence his
desire that the PTEX information be stripped out.
> is only one issue. You can always convert a PDF file to PS, edit the
> PS file, and convert it back to PDF.
There's no need to mess around with the PDF->PS->PDF conversions.
You can simply use:
setenv LANG C
then edit the PDF directly, say using vi, replacing any
sensitive information with spaces. Or you could write
a simple Perl/Python/Ruby script to do the editing automatically.
>
> If you are concerned about security you should encrypt the file. This
> is the only way to make a PDF file "readonly". A very good tool is
> pdftk.
>
> My personal opinion is that removing /PTEX.FileName doesn't improve
> security very much but for post-processors this information can be
> very useful.
I use a PDF post-processor to take care of things that can't be done using
TeX directly, or at least involve hideous expertise that I don't possess.
For instance, it allows me to obtain multi-line links that cope with both
page-breaks and hyphenations. Now when LuaTeX becomes mainstream I expect
that custom PDF post-processing will become much more commonplace.
Therefore I'm thinking, are there any plans to provide a standardized PDF
post-processor for TeX, written in Lua? Or at least, will a set of
guide-lines be put in place for how a PDF post-processor should work so as
to ensure that different efforts don't trample on one another?
James
>
> I suggest to leave things as they are.
p.s. I side with Stephan on this one. Including a full pathname to an
included PDF should not be the default behaviour.
>
> Regards,
> Reinhard
>
>
More information about the pdftex
mailing list