From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/1792 Path: main.gmane.org!not-for-mail From: Karsten Tinnefeld Newsgroups: gmane.comp.tex.context Subject: Re: PDF Questions Date: Tue, 28 Mar 2000 15:05:52 +0200 Sender: owner-ntg-context@let.uu.nl Message-ID: <200003281305.PAA22417@goedel.cs.uni-dortmund.de> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035392600 3230 80.91.224.250 (23 Oct 2002 17:03:20 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2002 17:03:20 +0000 (UTC) Cc: NTG-ConTeXt mailing list Original-To: Hans Hagen Xref: main.gmane.org gmane.comp.tex.context:1792 X-Report-Spam: http://spam.gmane.org/gmane.comp.tex.context:1792 > 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