This is the weekly report about the development of the GNU PDF project.
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.
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.