PDF Questions

PDF Questions

[Christopher G D Tipper]

I realise this isn't a ConTeXt specific set of questions, but I see that PRAGMA-ADE is now the home for pdfTeX, so maybe Hans may have some input.

Basically, I noticed that Hans had protected the ConTeXt manuals (and I wanted to highlight some minor spelling errors in the English version with Acrobat). No doubt Hans is perfectly capable of fixing his own typos, but this security thing is essential for websites. I was wondering if there was a way of manipulating the security properties of a PDF from pdfTeX using something like the \pdfliteral or \pdfobj attributes. I downloaded the Adobe PDF 1.3 Specification and it doesn't seem to mention security. Do we need to sign a non-disclosure agreement for this stuff?

At the moment I feel very ripped-off for paying for Acrobat. Distiller is cool, (but Ghostscript 6.0 is catching up fast) however, if you have Word, Distiller is the way to go. But I'm trying to ween myself off Word, and Acrobat-proper is useless. The only thing I need it for now is thumbnails and security (which reminds me, the thumbpdf package in pdfLaTeX I have breaks in PDF 1.3--does anyone know how to do this in ConTeXt?)

Regards,
Christopher
-
Nil Desperandum Illegitimi - Don't let the bastards get you down (with apologies to Ovid)

e-conomist - Informed analysis of the Wired World
              http://users.hol.gr/~ctipper/index.htm

Re: PDF Questions

[Tobias Burnus]

Hi Christopher,

> Basically, I noticed that Hans had protected the ConTeXt manuals (and I wanted to highlight
> some minor spelling errors in the English version with Acrobat). No doubt Hans is perfectly
> capable of fixing his own typos, but this security thing is essential for websites. I was
> wondering if there was a way of manipulating the security properties of a PDF from pdfTeX
> using something like the \pdfliteral or \pdfobj attributes. I downloaded the Adobe PDF 1.3
> Specification and it doesn't seem to mention security. Do we need to sign a non-disclosure
> agreement for this stuff?

As far as I know is this a kind of postprocessing stuff, so I don't
think this is doable in pdftex.

> At the moment I feel very ripped-off for paying for Acrobat. Distiller is cool, (but
> Ghostscript 6.0 is catching up fast) however, if you have Word, Distiller is the way to go.
Why do you need Distiller for Word (instead of Ghostscript)?

> But I'm trying to ween myself off Word, and Acrobat-proper is useless. The only thing I need
> it for now is thumbnails and security (which reminds me, the thumbpdf package in pdfLaTeX I
> have breaks in PDF 1.3--does anyone know how to do this in ConTeXt?)
Concerning the thumbnail package, I would suggest to report this problem
to Haiko Overdiek
(hope the spelling is right). Presently ConTeXt doesn't support
something like this, but I think this would be an easy part (Hans?).

Concerning the Acrobat-free creation of two-pass things, you might hope
for the next version of Ghostscript. Ghostscript-CVS/6.20 does already
support linearisation (Adobe calls this for what ever reason
`optimation'). Supporting security would be a user project. (Peter
Deutsch says he is willing to include such support, if somebody
contributes it.)

Tobias

Re: PDF Questions

[Hans Hagen]

At 04:19 PM 3/27/2000 +0300, Christopher G D Tipper wrote:

> see that PRAGMA-ADE is now the home for pdfTeX, 

Not so much *the* home (which is thanh's site) but *a* home, at least for
some samples and the manuals -)  

>Basically, I noticed that Hans had protected the ConTeXt manuals (and I
wanted to highlight some minor spelling errors in the English version with
Acrobat). No doubt Hans is perfectly capable of fixing his own typos, but
this security thing is essential for websites. I was wondering if there was
a way of manipulating the security properties of a PDF from pdfTeX using
something like the \pdfliteral or \pdfobj attributes. I downloaded the
Adobe PDF 1.3 Specification and it doesn't seem to mention security. Do we
need to sign a non-disclosure agreement for this stuff?

I'm not sure about what manual you talk, but the only reason I can think of
protecting some of them was to tag them as 'don't change' which was a way
to prevent acrobat asking 'do you want to save ...' each time a document is
used, which is the case when one has fields included. 

[The beta manuals are definitely not protected, since that way David Arnold
can send me corrections as notes, which in turn I can postprocess in
context into hyperlinked endnotes.] 

[If there will be a command line utility I may consider protecting them for
editing just to be sure they move around the internet as they are. But I
suppose I will be too lazy for that.] 

>At the moment I feel very ripped-off for paying for Acrobat. Distiller is
cool, (but Ghostscript 6.0 is catching up fast) however, if you have Word,
Distiller is the way to go. But I'm trying to ween myself off Word, and
Acrobat-proper is useless. The only thing I need it for now is thumbnails
and security (which reminds me, the thumbpdf package in pdfLaTeX I have
breaks in PDF 1.3--does anyone know how to do this in ConTeXt?)

I never looked into thumbnails since I see no real reason for using them,
although I must admit I have thoughts about making funny metapost ones.
Thumbnails are just bitmap graphics (xforms) and pointed to by simple key
value pairs. Maybe the thumbnail graphics you use are somehow broken. 

Protection, optimization, encryption is a multipass pass activity, and
therefore beyond pdftex. You can use acrobat exchange for that (a cheap old
version will do). Sometimes exchange comes on cdroms with documents. 

A next release of GS will come with an optimizer, and I will not be
surprised if protection is part of that. 

Hans 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
-----------------------------------------------------------------

Re: PDF Questions

[Hans Hagen]

At 03:34 PM 3/27/2000 +0200, Tobias Burnus wrote:

>(hope the spelling is right). Presently ConTeXt doesn't support
>something like this, but I think this would be an easy part (Hans?).

I just took a look at the specs. I don't think we can use the xform
primitive, so we some rather well defined bitmaps in ascii format and
compose the object ourselves. 

>Concerning the Acrobat-free creation of two-pass things, you might hope
>for the next version of Ghostscript. Ghostscript-CVS/6.20 does already
>support linearisation (Adobe calls this for what ever reason

In the first pass? As second pass? I thought it was a separate program? 

>`optimation'). Supporting security would be a user project. (Peter
>Deutsch says he is willing to include such support, if somebody
>contributes it.)

I suggest you to be that someone -) Anyhow, there are enough programmers on
this list to pick up that thread. 

Hans

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
-----------------------------------------------------------------

Re: PDF Questions

[Ed L. Cashin]

Hans Hagen <pragma@wxs.nl> writes:

> >`optimation'). Supporting security would be a user project. (Peter
> >Deutsch says he is willing to include such support, if somebody
> >contributes it.)
>
> I suggest you to be that someone -) Anyhow, there are enough
> programmers on this list to pick up that thread.

Didn't someone knowledgable-sounding on the pdftex list say that it's
complicated by the fact that Adobe is not releasing some keys
necessary to make it work?

-- 
--Ed Cashin                     PGP public key:
  ecashin@coe.uga.edu           http://www.coe.uga.edu/~ecashin/pgp/

Re: PDF Questions

[Hans Hagen]

>Didn't someone knowledgable-sounding on the pdftex list say that it's
>complicated by the fact that Adobe is not releasing some keys
>necessary to make it work?

RC4 is a copywritten, proprietary algorithm of RSA Data Security, Inc. Adobe
Systems has licensed this algorithm for use in its Acrobat products.
Independent
software vendors may be required to license RC4 to develop software that
encrypts
or decrypts PDF documents. For further information please send e-mail to
products@rsa.com or visit the RSA web server at
http://www.rsa.com/.

So, anyone paying for the licence ... we only need encryption -) Incredible
that they didn't use a public method. When does the patent end? Anyhow,
this encryption sort of violated portability anyway. Imagine that you would
need a decription device for novels and paperbacks. 

Hans

Hans

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
-----------------------------------------------------------------

Re: PDF Questions

[Tobias Burnus]

Hi Hans et alii,

> > Presently ConTeXt doesn't support
> >something like this, but I think this would be an easy part (Hans?).
> I just took a look at the specs. I don't think we can use the xform
> primitive, so we some rather well defined bitmaps in ascii format and
> compose the object ourselves.
Haiko's thumbpdf works like this:
0. The user produces from his TeX source a PDF file.
1. Now the thumbnails (thumb???.png) are generated by ghostscript,
   if the user does not want to provide his own ones.
2. With pdfTeX a second pdf file (thumbpdf.pdf) is produced, which
   contains the thumbnails set by the \pdfimage command.
   The program `thumbpdf.tex' looks for files with names
   `thumb000.png' to `thumb999.png' and additional ones
   specified in `thumbopt.tex'.
3. Then the above generated pdf file is parsed to get the object
   representation of the thumbnails. This is written to a TeX
   readable file (thumbdta.tex).
4. If the user's TeX source include the package (thumbpdf.sty),
   the object data are read and inserted by the \pdfobject command.
   Now \pdflastobject reports the object number of the thumbnails.
   Before every shipout of a page the thumbnail for this page is
   specified in the page attributes. This is done automatically,
   so an user have to input the package only.

> >Concerning the Acrobat-free creation of two-pass things, you might hope
> >for the next version of Ghostscript. Ghostscript-CVS/6.20 does already
> >support linearisation (Adobe calls this for what ever reason
> In the first pass? As second pass? I thought it was a separate program?
Well the first pass is PDFTeX or pdfwriter or distiller, the second pass
is `pdfopt' of Ghostscript.

> >`optimation'). Supporting security would be a user project. (Peter
> >Deutsch says he is willing to include such support, if somebody
> >contributes it.)
> I suggest you to be that someone -) Anyhow, there are enough programmers on
> this list to pick up that thread.
I'll look into this (I think it would be great, if this would work), but
I
have only a slight idea what will be needed.
The starting place would be PDFSpec.pdf, page 63 ff. and
http://www.ozemail.com.au/~geoffk/pdfencrypt/pdf_sec.ps

"Ed L. Cashin" wrote:
> Didn't someone knowledgable-sounding on the pdftex list say that it's
> complicated by the fact that Adobe is not releasing some keys
> necessary to make it work?
I don't know whether this is true, but it might be; though I wouldn't
quite understand why: We can decrypt PDF files (via pdf_sec.ps), so
we have quasi the private key. Why shouldn't we also get the public key?
-- The other question is (a) the RSA patent (I don't know how long this
is valid, and in which countries this applies) and (b) the cryption laws
of the USA. This probably will prevent the direct inclusion in GS, but
for the non-USA members of the list, this shouldn't be a problem during
developement. (Since the key is only 40-bit long and the USA are
relaxing
their policies this might be a former problem, but I'm not a lawer.)

Tobias

Re: PDF Questions

[Hans Hagen]

Hi Tobias, 

>> I just took a look at the specs. I don't think we can use the xform
>> primitive, so we some rather well defined bitmaps in ascii format and
>> compose the object ourselves.

>1. Now the thumbnails (thumb???.png) are generated by ghostscript,
>   if the user does not want to provide his own ones.

Is GS able to do this fast and efficiently, say in one call instead of 1000
launches? 

>3. Then the above generated pdf file is parsed to get the object
>   representation of the thumbnails. This is written to a TeX
>   readable file (thumbdta.tex).

Hm. I think step 3 can be omitted and done directly. 

Anyhow, this process is really something for a last run -) 

Hans

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
-----------------------------------------------------------------

Re: PDF Questions

[Slawek Zak]

> So, anyone paying for the licence ... we only need encryption -) Incredible
> that they didn't use a public method.

Because there would be public, freely available encoders for PDF,
maybe.

/s

Re: PDF Questions

[Hans Hagen]

Hi Karsten, 

>> >Ideally, there would be a 
>> >	\pdfpermissions {/printing  (enabled)
>> >			 /copying   (disabled)
>> >			 /ownerpass (thelionsleepstonight) }
>> 
>> This would not work, since there are no such keys. Also, it would have to
>> be real primitives, since pdftex does not interpret what goes into objects
>> and attr's. 
>
>Nor did I mean, implement it in exactly this way. There are always two, 
>the machine parser and the human parser, and there are at least two 
>different styles for tex coding: *tex syntax using []{}-lists and ps 
>syntax, which is used in pdftex for most pdf specialities. I thought it 
>adequate adopting it for this stuff as well, though it is no native 
>code.

Your right, but since pdftex is also the backend, its syntax does not
always fit tex. Most of those \pdfpage(s)attr, annot, resource, etc
primitives are actually a special kind of \special. 

\pdfcatalog{/PageMode /FullScreen}

is for instance just a way to force things into the catalog. Pdftex does
interpret the strings. If it was a primitive, \pdfpermissions would need to
be interpreted. There was a time that pdftex indeed did some interpretation
in some cases. Your case could at first sight probably be solved by
something: 

\pdftrailer{}

which would just pass the content to the trailer. Then, objects could be
created and set using \pdfobj that contain the copying and printing flags.

The problem here is that pdftex would need to encrypt, know the password,
key, etc, so here we should in fact have: 

\pdfcopyingpassword{...} % to be set before first shipout 
\pdfprintingpassword{..} % idem 

which probably be rather inflexible for future extensions. In context, the
high level wrapper would provide: 

\setupinteraction[printprotection=...]

with ... being: no, yes, or password. Or something like that.

The problem with \pdf... primitives is that on one hand they are tex ones
and the other hand driver specific ones. Pretty nasty to get that syntax
right. 

Hans 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
-----------------------------------------------------------------

Re: PDF Questions

[Karsten Tinnefeld]

> I know since NTS is prototyped in Java -) I just considered it a funny
> contraditionary. They could have made it a private class.

What I knew was what Phil Taylor and Karel Skoupý told us in Dortmund
a year ago. That time I did not know any Java.

But then again, nts.tug.org tells me you have become project leader. 
Wow, I guess you should know.

> >Ideally, there would be a 
> >	\pdfpermissions {/printing  (enabled)
> >			 /copying   (disabled)
> >			 /ownerpass (thelionsleepstonight) }
> 
> This would not work, since there are no such keys. Also, it would have to
> be real primitives, since pdftex does not interpret what goes into objects
> and attr's. 

Nor did I mean, implement it in exactly this way. There are always two, 
the machine parser and the human parser, and there are at least two 
different styles for tex coding: *tex syntax using []{}-lists and ps 
syntax, which is used in pdftex for most pdf specialities. I thought it 
adequate adopting it for this stuff as well, though it is no native 
code.

Karsten
-- 
Karsten Tinnefeld                       tinnefeld@ls2.cs.uni-dortmund.de
Fachbereich Informatik, Lehrstuhl 2                   T +49 231 755-4737
Universität Dortmund, D-44221 Dortmund, Deutschland   F +49 231 755-2047

Re: PDF Questions

[Hans Hagen]

At 03:05 PM 3/28/2000 +0200, you wrote:
>> This is a funny one. The java code clearly says: 
>> 
>>  public RC4()
>> 
>> Looks pretty public to me, especially for non java experts -)
>
>Simply means that every method may access the class, create variables 
>of its type, call its functions, etc.

I know since NTS is prototyped in Java -) I just considered it a funny
contraditionary. They could have made it a private class.

>Without any reply, I asked pdftex-l on February 17th,
>--8<--
>Has anyone yet startet a project to implement the 
>pdf standard encryption mechanism with pdfTeX?
>
>Ideally, there would be a 
>	\pdfpermissions {/printing  (enabled)
>			 /copying   (disabled)
>			 /ownerpass (thelionsleepstonight) }

This would not work, since there are no such keys. Also, it would have to
be real primitives, since pdftex does not interpret what goes into objects
and attr's. 

>field setting permission flags, owner and user password, if any,
>maybe being entered/input separately.

actually it's an object 

  /Filter /Standard /V 1 /R 2 /O

to which the Encrypt key points

  trailer<</Size 26/Info 8 0 R /Encrypt 11 0 R

so \pdftrailerattr would be more appropriate. 

>I still think that whether or not encryption is to be done in a 
>separate pass, information about this should be kept in the tex file.

Sure, that will not be the problem. Since that can be passed on. 

Hans

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
-----------------------------------------------------------------

Re: PDF Questions

[Karsten Tinnefeld]

> This is a funny one. The java code clearly says: 
> 
>  public RC4()
> 
> Looks pretty public to me, especially for non java experts -)

Simply means that every method may access the class, create variables 
of its type, call its functions, etc.

Without any reply, I asked pdftex-l on February 17th,
--8<--
Has anyone yet startet a project to implement the 
pdf standard encryption mechanism with pdfTeX?

Ideally, there would be a 
	\pdfpermissions {/printing  (enabled)
			 /copying   (disabled)
			 /ownerpass (thelionsleepstonight) }
field setting permission flags, owner and user password, if any,
maybe being entered/input separately.

As ianal I cannot determine whether or not usage of the (fake) rc4/md5 
algorithms would be a serious problem nowadays, but this (and the 
demand for a encrypted-only pw storage) may be a reason for a partially 
separate tool.

Comments?
--8<--

I still think that whether or not encryption is to be done in a 
separate pass, information about this should be kept in the tex file.

Karsten
-- 
Karsten Tinnefeld                       tinnefeld@ls2.cs.uni-dortmund.de
Fachbereich Informatik, Lehrstuhl 2                   T +49 231 755-4737
Universität Dortmund, D-44221 Dortmund, Deutschland   F +49 231 755-2047

Re: PDF Questions

[Hans Hagen]

Hi Karsten, 

Thanks for the pointers. 

>	http://moriartys.com/cryptix/doc/cryptix.provider.cipher.RC4.ht

This is a funny one. The java code clearly says: 

 public RC4()

Looks pretty public to me, especially for non java experts -) 

Hans

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
-----------------------------------------------------------------

Re: PDF Questions

[Karsten Tinnefeld]

Hans Hagen wrote,
> RC4 is a copywritten, proprietary algorithm of RSA Data Security, Inc. Adobe
> Systems has licensed this algorithm for use in its Acrobat products.
> Independent
> software vendors may be required to license RC4 to develop software that
> encrypts
> or decrypts PDF documents. For further information please send e-mail to
> products@rsa.com or visit the RSA web server at
> http://www.rsa.com/.
> 
> So, anyone paying for the licence ... we only need encryption -) Incredible
> that they didn't use a public method. When does the patent end? Anyhow,
> this encryption sort of violated portability anyway. Imagine that you would
> need a decription device for novels and paperbacks. 

Yes, but there is another algorithm on the net that reportedly does
exactly the same on all inputs anybody tested. If you want to do 
encrypted pdf according to the pdf specs, you of course have to license 
rsas property. But if you just want to produce something that works 
exactly as if is were encrypted pdf, though it is not, there is no 
point in licensing this algorithm.

The source is on, e.g.,
	http://members.tripod.com/~tomstdenis/crypto.htm

On the other hand, rsa.com do not agree on this:
	http://remus.prakinf.tu-ilmenau.de/ssl-users/archive1/0060.html

Again on the one hand, people just use and distribute it:
	http://moriartys.com/cryptix/
	http://moriartys.com/cryptix/doc/cryptix.provider.cipher.RC4.html

Karsten
-- 
Karsten Tinnefeld                       tinnefeld@ls2.cs.uni-dortmund.de
Fachbereich Informatik, Lehrstuhl 2                   T +49 231 755-4737
Universität Dortmund, D-44221 Dortmund, Deutschland   F +49 231 755-2047