He will be contributing regularly to the project while working on his master thesis.

Many thanks, Sonia!

Many thanks, Etienne!

software developers

We need hackers with a good background in C for the development of GNU PDF. No previous knowledge in the PDF format is required.

To get a general picture about the kind of tasks that should be done take a look to the tasks list (tasks marked as NEXT without an asignee are waiting for someone).

If interested please be sure to read our information for Newcomers.

manuals writer

We need an experienced technical writer to write down the User Manual for the GNU PDF Library.

Interested people please write to the development mailing list : pdf-devel@gnu.org.

web designer for gnupdf.org

We are looking after the improvement of the visual look of the GNU PDF webpages.

www.gnupdf.org is a mediawiki site, so we need someone skilled in CSS and php programming.

Interested people please write directly to the maintainer: pdf-maintainer@gnu.org.

Fixes in the Stream Module

This week we did a lot of work on the stream module. Juan Pedro Bolivar discovered a really bad bug in the stream module code that led to the rewrite of some parts of pdf-stm.

We wrote or adapted several filters: the ASCII hex encoder and decoder, the Run Length encoder and decoder and the Flate encoder and decoder.

Super Powered pdf-filter

We have extended the pdf-filter utility. Now it is possible to use a reading stream or a writing stream and to specify the stream cache size using command line parameters.

Of course all the written filters can be used by invoking pdf-filter.

Crypt Unit Tests Passing(now)

A problem with the initialization of the libgcrypt library was the cause of the fail of every unit test for the crypt module. David Vazquez found the error and sent a patch fixing it. Right now all the unit tests of the library are passing.

nocheck and fork-mode

The code of the GNU PDF Library is portable and works in both GNU and Windoze systems. The unit testing framework that we are using, check, makes use of fork to implement a fork-mode: each unit test is executed in a separate process. In that way the test driver is able to properly catch any signal produced by the software under test (such as a segmentation fault) and to detect endless conditions.

A problem with check is that it does not work in Windoze systems since it depends on the availability of the fork system call, so some time ago Aleksander Morgado wrote an alternative library called nocheck. We are using nocheck to pass the unit tests with Wine.

Zac Brown detected a little problem with nocheck: it was not defining some fork-mode specific functions and symbols and thus the unit tests were not compiling at all. He sent a patch fixing this issue, so nocheck is working again.

RSS Problem Fixed

The mediawiki-based rss reader in http://www.gnupdf.org is now working properly. The problem was related with the caching of the RSS made by magiperrs and a misconfiguration in the server.

Still Missing Examples

Unfortunately a lot of existing function entries (more than 90 actually) are lacking a proper usage example. We are looking for a volunteer to take over this task. If you have some spare time that you would want to donate to do this task please write to the development mailing list.

Changes to the Streams Implementation

This week we have been polishing a bit the stream design commited the last week. Juan Pedro Bolivar Puente and Gerardo E. Gidoni provided quite interesting points such as to not use the use of hash tables to maintain the internal state of the filters (using a void pointer instead), to use a specific dealloc function in each filter implementation and to use memcpy instead of strcpy in order to avoid problems with null characters (yes, the maintainer sometimes has big reasoning problems ).

We also determine that we need to maintain a minimum cache size in the stream filters in order to avoid problems when finalising the filters. It is the consequence of a design flaw, but it is not really important since we plan to use the system page size (usually 4k) for the cache. By far more than necessary by any filter implementation.

Unit Tests for the Hash Module

We are using lcov to generate a code coverage report in http://www.gnupdf.org/prmgt/coverage. The primary use of the coverage report is to determine the extension of testing code.

This week we realised that the coverage of the Hash Tester functions was not good at all, so Gerardo E. Gidone provided a bunch of new unit tests and now the coverage of pdf-hash-helper.c is at 100%! Quite nice.

Filter Implementations

This week we completed the implementation of four filters: an encoder and a decoder for ASCII Hex and an encoder and a decoder for RunLength.

We plan to have implementation for all the PDF standard filters quite soon.

Still Missing Examples

Unfortunately a lot of existing function entries (more than 90 actually) are lacking a proper usage example. We are looking for a volunteer to take over this task. If you have some spare time that you would want to donate to do this task please write to the development mailing list.

The big picture

We are getting close to complete the base layer of the library. After that milestone we will start working in the next layer: the object layer.

Opaque Pointers

Juan Pedro Bolivar, a GNU PDF contributor and also the maintainer of GNU Jump, suggested the use of opaque pointers in libgnupdf. The use of opaque pointers would improve the binary compatibility with applications using the library.

After a short discussion in the development mailing list we decided to go on and use opaque pointers in some of the ADTs of the library (not in all of them, since it is desirable for some of the ADTs to be allocated in the stack instead of the heap. In these cases we should provide the complete structure of the data type in the public header file).

The C/POSIX Locale and the Text Module

We finally fixed the problem with the C/POSIX locale. The initialization function of the text module was failing to work with that locale due to the lack of the specification of the language and country properties in the locale name. It comes that the country defined for C/POSIX is “ISO” (a strange country, isnt it?) and the language is the empty string.

A little patch for the initialization function solved the problem and now all the unit tests for the text module are passing.

Old Mac OS File Names

The PDF specification allow to store old Mac OS file names in PDF files. Despite Mac OS systems previous to Mac OS X is not in our list of target architectures, the GNU PDF Library should be able to manage those file specifications.

Fortunately Aleksander Morgado came with a solution: there is a function in the Core Foundation library in Mac OS X that convert old Mac OS paths to POSIX paths. So at least we will be able to process PDF documents containing old Mac OS file specifications when running in Mac OS X.

API Consistency Report

As part of our “continuous integration” efforts we have an automatically-generated API Consistency Report. This report is generated by a script that scans the texinfo source of the GNU PDF Library Reference Manual and the source tree. It can tell if a given function is documented in the report but it is not actually implemented in the library. It is really useful for us, since we are writing the API of each part of the library before to write the code for it.

This week Gerardo E. Gidoni sent a patch to improve the accuracy of the report.

New Stream Module

Finally (finally!) the lazy maintainer provided the new implementation of the stream module. The tasks of re/writing the stream filters are now in the NEXT state, waiting for some developer to take them.

The pdf-filter utility has been also converted to use the new stream implementation. As soon as we get the default disk filesystem we will be able to test it with the streams.

fly2org

We are using flyspray to manage the development tasks of the project. It is a nice and simple tasks manager. We wrote a little script fly2org to generate an Emacs org-mode file with all the development tasks. It will ease the life of some of the developers that uses org-mode to planning their life.

An up-to-date org-mode file can be obtained at any time by fetching the url http://www.gnupdf.org/prmgt/fly2org.php.

Development blog in www.gnupdf.org

Now that we are using this development blog in Planet GNU we replaced the News section of the webpage with a rss reader. Unfortunately the rss mediawiki plugin seems to not work correctly for non-logged users. We are looking into it (if you know of any solution for this or you are a php hacker and want to look into it, please drop a note in the development mailing list!).

Still Missing Examples

The GNU PDF Library Reference Manual still lacks a lot of usage examples for the public functions of the library. We believe that those examples will be quite useful for the people using the reference manual.

We are looking for a volunteer to take over this task. If you have some spare time that you would like to donate to do this task please write to the development mailing list.

The Big Picture

We are more close to completing the base layer of the library. After that milestone we will start working in the next layer, the object layer.

New Library Module for Cryptography

David Vazquez has submitted the initial implementation of the crypt module. The module implementation makes use of libgcrypt to provide encryption and decryption of memory buffers. We will use those functions to write the support for encryption filters in the stream module.

After the installation of the new module in the trunk we had some fun determining the minimum required version of libgcrypt that we needed to build the library. The conclusion was to require libgcrypt >= 1.2.4 and we think it is a reasonable requirement.

Abstract Data Types

We also created a new section in the GNU PDF Hackers Guide containing some conventions about how to implement Abstract Data Types. We did some work to adapt the existing code to the conventions.

Autobuild and Portability

Zac Brown sent an email to the development mailing list showing the convenience of using some kind of autobuild system to automatically build the library and run the test suite on several different target architectures. Ralph Giles came with the idea to use a solution named buildbot. Zac is now looking into it. If we finally decide to use buildbot then we will search for people willing to donate some machine power to build a kind of compilation and testing farm. That kind of setup would be really useful for any GNU package willing to be portable to non-GNU machines.

Zac also spent a three-day weekend adapting GNU PDF to compile for FreeBSD, OpenBSD and NetBSD. Currently compilation and unit tests succeed on FreeBSD and OpenBSD, however NetBSD is not currently linking with libiconv. His modifications also added a proper setting for timezone and GMT offset. This made GNU PDF compliant with AST/ADT standards, which represents time West of Greenwich Mean Time in negative intervals. Zac’s next goals include enabling compilation on OpenSolaris/Solaris as well as fixing support on NetBSD.

Tons of Usage Examples (and some missing)

The GNU PDF Library Reference Manual is getting large (currently more than 9000 lines of texinfo). For each public function in the library we are including usage examples. We believe that those examples will be quite useful for the people using the reference manual.

Unfortunately a lot of existing function entries (more than 90 actually) are lacking proper usage examples. We are looking for a volunteer to take over this task. If you have some spare time that you would like to donate to do this task please write to the development mailing list.

Text Module and Locales

At some point in this week the unit tests for the text module suddenly started to fail.

After some inquiries Gerardo E. Gidoni came with the reason: this week we installed the maintainer-makefile module from gnulib. The module provides a maint.mk file providing useful targets for the maintenance of the code (like syntax-check). The problem is that maint.mk sets the locale of the build process to POSIX and the text module is not prepared to work for that locale.

We are discussing this issue on the mailing list about how to manage the locale POSIX/C and what encoding/language/country to use.

Would be really good to have the opinion of a localization guru, so if you read this and know the answer, please drop a note in the mailing list .

The Big Picture

We are getting close to completing the base layer of the library. After that milestone we will start working in the next layer, the object layer.