Encrypting PDF documents and setting document permissions

Nowadays many applications are able to create PDF files. Most of them do not support advanced PDF features like encrypting PDF files or setting document permissions.


Document permissions are settings that configure what the user is allowed to do with a PDF file (let's say you can forbid the user to print the PDF file or to extract images from the PDF).


PoDoFo includes now a nice commandline utility in its SVN version (and in the next relase 0.6.0) called podofoencrypt.


podofoencrypt can be used to encrypt any existing PDF file and set document permissions on the file. You can select between weak rc4v1 encryption and strong rc4v2 encryption. An owner password has always to be set. The owner password is only used internally by PDF processing applications. The optional user password can be used if you want the user to have to enter a password before he can view the PDF in a user application.


Let's see a small example on howto use podofoencrypt to encrypt a PDF file with a user password which allows the user to print the PDF but not to extract text or images from it.

./podofoencrypt -o dominik -u user --print example.pdf output.pdf   

A quick look at the document properties dialog in Adobe Reader shows that you are allowed to print the PDF but do nothing else with it.



I would like to get some feedback on the new encryption feature of PoDoFo and especially on the new podofoencrypt tool. So please get it from svn and try it out.

Dom

TFORMer 5.0.0 released

Besides developing OpenSourceSoftware I do also work for TEC-IT Datenverarbeitung GmbH. Last week we finally released TFORMer 5.0.0. A cross platform, easy to use and very powerful report printing framework.


I worked over the last 3 years on this version and we all put a lot of work into this release. Most importantly, the source is completely portable over a broad range of platforms and architectures. The Linux version is relased for several RPM based distributions and as deb for Ubuntu. AIX, HPUX and Solaris builds are available on request. Please note that the same source is also compiled on Windows (from which we ported it to all these platforms).


TFORMer can print to PDF, PostScript and HTML files and of course to any system printer using CUPS. More output formats will be available with TFORMer 5.1 :) The PDF and PostScript output are really highquality and were the two projects you got me to learn both output formats.


I am proud of the quality of the Linux version. We ship with an easy to use installer, which installs either an RPM or a DEB. The software is installed, with documentation (PDF format and man page), several templates, demo reports, sample code for C and .Net and of course development libraries for C and C#. After the software has been installed and report is printed automatically (if the users agrees to do so) and everything works - I can't imagine reporting has ever been easier on Linux.


The C API is great and powerful, but the new .Net API is sexy! First of all, the wrapper is portable between Mono on Linux and .Net on Windows. We load the TFORMer.dll when run on Windows and we load libTFORMer.so on Linux when we are executed on Unix.


Have you ever created a PDF report so easy?

  // Create a TFORMer Job
  Job job = new Job();

  // Load a predefined form layout
  job.RepositoryName = "MyForm.tff"M

  // create an in-memory data-source
  DataSourceRecordSet datasource = new DataSourceRecordSet();

  // Set some datafields
  job.DataSource = datasource;
  Record record = new Record();
  record.Data.Add("Email", "support@tec-it.com");
  record.Data.Add("JobTitle", "Support Engineer");
  record.Data.Add("Name", "Mr. Harald Backoffice");
  datasource.Records.Add(record);

  // Set the output file name and type
  job.OutputName = "out.pdf";
  job.PrinterType = PrinterType.PdfFile;

  // Print 
  job.Print();

Easy - Ja??!


A free demo version is available (for Windows and several Linux versions). So give it a try.

The future of SchafKopf

Someday SchafKopf has to be ported to KDE4. We all know that, but as of now, no one in the team has volunteered to do so (and no one else either).


One reason might be that we (Benni, Christian, Lenz and I) all agree that SchafKopf in its current state is not really maintainable. We hacked together a nice Card Game which is fun to play - but it is far away from the perfect Schafkopf implementation!


While driving home today, after I talked to Lenz over Schafkopf and Python I think it is time to start the discussion about what should be done with SchafKopf for KDE4.


My idea on how it should look - well this is most likely not even my idea but our idea that arose sometime - is the following.

• We need a Schafkopf server process


• Players can connect to this server


• Human and AI players are implemented


• The GUI connects to the server too

This has the following advantages. We can support different GUIs (Qt4, GTK, console and a web front end similar to all these online poker rooms - just for your favorite Bavarian card game). So we could write a simple Qt4 GUI (should go pretty fast because all logic is in the server) and have a KDE4 port.


The server can be implemented in another language than the GUI. As a reason we can choose a language that is maybe better suited for AI stuff than C++. My first idea was: Use Common Lisp! Two reasons: Firstly I wanted to learn Common Lisp and secondly it is famous for its usage in AI research. I even hacked together a small server in LISP. It understands the basic Schafkopf rules. You can look at the source if you want. It went pretty fast using Lisp, but it would need some work.


Well, talked to Lenz today and - even if he is a great Lisp fan - he thinks a server in Lisp has two big disadvantages:

• Lisp is not very common on users systems. Users will have a hard time compiling SchafKopf


• Only few developers know Common Lisp, so we won't get much code contributions

He suggested Python to be used for the server. Python is well known by many developers. We can code in a functional way where necessary, so we should be as fast as when developing in Lisp and python is available on almost every system.


What can I say? The guy in the black clothes is right! If we want to get a SchafKopf version for KDE4 with a clean source that is maintainable we should

• write a SchafKopf server in Python


• write a Qt4 GUI that connects to the server

Who wants to join me in this project? Any other ideas?

KRename4 - the porting has begun

Porting KRename to KDE4 has started and slowly it is getting into shape. Porting is the wrong word though.... KRename4 will be a rewrite most parts. I think KDE4 is a good point to make a clean application out of KRename.

KRename 4 will....

• ... have the GUI created with designer instead of a hardcoded GUI
• ... be covered by unit tests: Unit tests are essential to make sure no regressions are introduced. Currently the testing framework is a hand written set of macros, but I might switch to Qt TestLib
• ... be good designed code: separation between GUI and renaming core
• ... have comments in the source where appropriate

All these changes will hopefully lead to a very clean KRename4. A KRename4 where others can easily contribute code! The first version will be a functional identical port of the current KDE3 version and the following version will include some nice features, mostlikely an optional JavaScript interpreter so that you can write custom functions for renaming files.

Above you can see how it currently looks, not very different from the KRename 3.0.14 and counters do not work at all.... but it's getting along.

If you want to give it a try get it from svn and compile it (requires KDE4 alpha installed and cmake):

svn co https://krename.svn.sourceforge.net/svnroot/krename/trunk krename
mkdir krename-build
cd krename-build

cmake ../krename
make


Here you go :)

domseichter's blog

So ... I started a blog.

The reason is that I am currently porting KRename (a batch renamer for KDE) to KDE4 and it is going to become great. I want to give some status report here in my blog and hopefully I can show some nice stuff about KRename4 and KDE4 in general.

Additionally you will find here news on another project I am working on right now: PoDoFo. PoDoFo is a portable PDF generation and parsing library in C++. So if you are interested in PDF: check it out.