[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?


> 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