-*- mode: org; fill-column: 78 -*-

GNU PDF Tasks
Generated at Thu Mar 11 18:45:30 CET 2010 by fly2org

* GNU PDF Library
** DONE Basic Types Module first implementation
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The several basic types documented in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Basic_Types_Module should be implemented in the `pdf-types.h' and `pdf-types.c' source files.


** DONE 64bit bignums first implementation
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

Implementation of the system-independent 64bit numbers described in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Basic_Types_Module


** DONE Text Module first implementation
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: aleksander
   :PercentComplete: 100
   :END:

A first implementation of the text module as defined in the GNU PDF Library Architecture: http://www.gnupdf.org/Lib:Architecture/Base_Layer/Text_Module

The API to be implemented is documented in the GNU PDF Library Reference Manual: http://www.gnupdf.org/Lib:Reference_Manual#Encoded_Text

** DONE 64bit bignums unit tests design
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

A collection of unit tests for the 64bit big numbers implemented in the Basic Types Module should be designed and documented in the GNU PDF Library Test Specification Document: http://www.gnupdf.org/Lib:Test_Specification_Document


The 64bit number API is documented in the reference manual: http://www.gnupdf.org/Lib:Reference_Manual#Big_Numbers
** DONE List Module first implementation
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The list module documented in http://www.gnupdf.org/Lib:Architecture/Base_Layer/List_Module should be implemented in the source files `base/pdf-list.h' and `base/pdf-list.c'. 
** DONE Time Module first implementation
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: aleksander
   :PercentComplete: 100
   :END:

The Time Module documented in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Time_Module and http://www.gnupdf.org/Lib:Reference_Manual#Time_Management should be implemented.
** DONE Time Module unit tests implementation
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

Implementation of the unit tests designed for the time module.
** DONE Text Module unit tests implementation
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: aleksander
   :PercentComplete: 100
   :END:

mplementation of the unit tests designed for the text module.
** DONE List Module unit tests implementation
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

Implementation of the unit tests for the List Module.
** DONE Use pdf_list_t instead of gl_list_t
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

Adaptation of the codebase to use pdf_list_t instead of gl_list_t
** DONE Fix conflicts in gnulib imported AC_USE_SYSTEM_EXTENSIONS
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

When regenerating the build system of the GNU PDF Library there are warnings about the AC_USE_SYSTEM_EXTENSIONS macro defined by the gnulib imported M4 macros. 

Output of the bootstrap script:

 jemarch@malditobastardo:~/gnu/src/libgnupdf$ ./bootstrap 
 Bootstrapping CVS GNU PDF Library with:
   autoreconf -i
 configure.ac:36: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
 m4/extensions.m4:23: AC_USE_SYSTEM_EXTENSIONS is expanded from...
 m4/extensions.m4:81: gl_USE_SYSTEM_EXTENSIONS is expanded from...
 m4/gnulib-comp.m4:21: gl_EARLY is expanded from...
 configure.ac:36: the top level
 configure.ac:36: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
 configure.ac:36: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
 m4/extensions.m4:23: AC_USE_SYSTEM_EXTENSIONS is expanded from...
 m4/extensions.m4:81: gl_USE_SYSTEM_EXTENSIONS is expanded from...
 m4/gnulib-comp.m4:21: gl_EARLY is expanded from...
 configure.ac:36: the top level
 configure.ac:36: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
 libtoolize: `config.guess' exists: use `--force' to overwrite
 libtoolize: `config.sub' exists: use `--force' to overwrite
 libtoolize: `ltmain.sh' exists: use `--force' to overwrite
 configure.ac:36: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
 m4/extensions.m4:23: AC_USE_SYSTEM_EXTENSIONS is expanded from...
 m4/extensions.m4:81: gl_USE_SYSTEM_EXTENSIONS is expanded from...
 m4/gnulib-comp.m4:21: gl_EARLY is expanded from...
 configure.ac:36: the top level
 configure.ac:36: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
 configure.ac:36: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
 m4/extensions.m4:23: AC_USE_SYSTEM_EXTENSIONS is expanded from...
 m4/extensions.m4:81: gl_USE_SYSTEM_EXTENSIONS is expanded from...
 m4/gnulib-comp.m4:21: gl_EARLY is expanded from...
 configure.ac:36: the top level
 configure.ac:36: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
 configure.ac:36: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
 m4/extensions.m4:23: AC_USE_SYSTEM_EXTENSIONS is expanded from...
 m4/extensions.m4:81: gl_USE_SYSTEM_EXTENSIONS is expanded from...
 m4/gnulib-comp.m4:21: gl_EARLY is expanded from...
 configure.ac:36: the top level
 configure.ac:36: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
 configure.ac:36: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
 m4/extensions.m4:23: AC_USE_SYSTEM_EXTENSIONS is expanded from...
 m4/extensions.m4:81: gl_USE_SYSTEM_EXTENSIONS is expanded from...
 m4/gnulib-comp.m4:21: gl_EARLY is expanded from...
 configure.ac:36: the top level
 configure.ac:36: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
 
 Now run configure with your desired options, for instance:
   ./configure CFLAGS=-g

** DONE Time Module unit tests design
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

A set of unit tests should be designed for the Time Module. The unit tests should cover all the functionalities described in the architecture document for the Time Module (see doc/gnupdf-arch.texi).



** DONE Document the functions debug structure in the refman
   [2009-03-03 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: davazp
   :PercentComplete: 100
   :END:

The use of the structure pdf_fp_func_debug_t (defined in pdf-fp-func.h) shall be documented in the reference manual (doc/gnupdf.texi).

** DONE Text Module unit tests design
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: aleksander
   :PercentComplete: 100
   :END:

A set of unit tests should be designed for the Text Module. The unit tests should cover all the functionalities described in the architecture document for the Text Module.

The unit tests should be documented in the Lib:Torture_Chamber/Text_Module wiki page.

See the Torture Chamber page for more information about test cases.
** DONE List Module unit tests design
   [2008-03-04 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

Unit tests should be designed for the List module.

The API of the list module is documented in the GNU PDF Library Reference Manual: http://gnupdf.org/Lib:Reference_Manual#Lists

The unit tests should be documented in the GNU PDF Library Test Specification Document: http://gnupdf.org/Lib:Test_Specification_Document 
** DONE Simplify pdf_text_ucd_wb_detect_next
   [2008-03-25 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: aleksander
   :PercentComplete: 100
   :END:

The pdf_text_ucd_wb_detect_next function pertaining to the text module of the library is reported to have a mccabe number of 44 (see http://www.gnupdf.org/Lib:Cyclomatic_Report).

The function should be modified to achieve a better cyclomatic complexity (mccabe number less or equal than 20).

** DONE Simplify pdf_text_get_unicode
   [2008-03-25 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: aleksander
   :PercentComplete: 100
   :END:

The pdf_text_get_unicode function pertaining to the text module of the library is reported to have a mccabe number of 30 (see http://www.gnupdf.org/Lib:Cyclomatic_Report).

The function should be modified to achieve a better cyclomatic complexity (mccabe number less or equal than 20).

** DONE Simplify pdf_text_ucd_special_case_conditions
   [2008-03-25 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: aleksander
   :PercentComplete: 100
   :END:

The pdf_text_ucd_special_case_conditions function pertaining to the text module of the library is reported to have a mccabe number of 44 (see http://www.gnupdf.org/Lib:Cyclomatic_Report).

The function should be modified to achieve a better cyclomatic complexity (mccabe number less or equal than 20).

** DONE File System module design
   [2008-04-06 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The file system module should be designed and documented in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Filesystem_Module
** DONE File System module API design
   [2008-04-06 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The API of the filesystem module should be designed and documented in the reference manual (http://www.gnupdf.org/Lib:Reference_Manual).
** DONE File System module unit tests design
   [2008-04-06 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: derhans
   :PercentComplete: 100
   :END:

The unit tests for the filesystem module should be designed and documented in the GNU PDF Library Test Specification Document (http://www.gnupdf.org/Lib:Test_Specification_Document).
** STARTED File System module unit tests implementation
   [2008-04-06 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 10
   :END:

The unit tests designed for the Filesystem module and documented in the TSD should be implemented in the torture/unit directory.
** DONE File System module implementation
   [2008-04-06 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The File System module (documented in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Filesystem_Module) should be implemented.

** DONE Hash module design
   [2008-04-06 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The Hash Module should be designed and documented in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Hash_Module
** DONE Hash module API design
   [2008-04-06 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The API of the Hash module (documented in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Hash_module) should be designed and documented in the GNU PDF Library Reference Manual (http://www.gnupdf.org/Lib:Reference_Manual).
** DONE Hash module unit tests design
   [2008-04-06 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

A complete set of unit tests should be designed for the Hash module and documented in the GNU PDF Library Test Specification Document (http://www.gnupdf.org/Lib:Test_Specification_Document).

** DONE Hash module unit tests implementation
   [2008-04-06 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The unit tests collection designed for the Hash module and documented in the TSD should be implemented in the torture/unit/base/hash directory.
** DONE Hash module implementation
   [2008-04-06 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The Hash module documented in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Hash_Module should be implemented.
The API to implement is available in the GNU PDF Library Reference Manual (http://www.gnupdf.org/Lib:Reference_Manual).
** DONE Error Module unit tests Design
   [2008-04-09 Wed]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

A set of unit tests should be designed for the Error Module and documented in the GNU PDF Library Test Specification Document (http://www.gnupdf.org/Lib:Test_Specification_Document).
** DONE Error Module unit tests Implementation
   [2008-04-09 Wed]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

The unit tests for the Error Module documented in http://www.gnupdf.org/Lib:Test_Specification_Document should be implemented in the /torture/unit source tree.
** DONE Change the API of the public functions to use 'const' in read-only parameters
   [2008-04-29 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The public functions should use the 'const' qualifier in read-only parameters. This will improve the readability of the API (by letting the client to quicly identify input and output parameters) and the quality of the code. 

This task involves the following steps:

1) Update the Reference Manual (doc/gnupdf.texi).
2) Update the implementation.
3) Update the affected unit tests.


** STARTED Write down appropriate usage examples in the public functions API
   [2008-05-20 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

The function entries in the GNU PDF Library Reference Manual (doc/gnupdf.texi) contain a "Usage example" part where the user can find comprehensive example on the usage of the function.

Right now most of the Usage exmaple sections do not contain appropriate examples.

This task is about writing down good usage examples in the manual.

Skills required: basic texinfo knowledge, C programming knowledge and good criteria.


** DISCARDED Default Filesystem Implementation
   [2008-05-22 Thu]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The Default Filesystem for the library should be implemented in the src/base/pdf-fsys-disk.[ch] files.

This filesystem should provide access to disk files and directories in all the supported plattforms (POSIX systems, MacosX systems and Windows systems) by implementing the Filesystem Implementation Interface documented in the GNU PDF Library Reference Manual. 

** NEXT Disk Filesystem Module Implementation
   [2008-06-13 Fri]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 80
   :END:

The disk filesystem (default filesystem) should be implemented. There is an initial implementation in 'src/base/pdf-fsys-disk.c' and 'src/base/pdf-fsys-disk.h'. This filesystem implement the filesystem interface and makes use of the generic filesystem code in 'src/base/pdf-fsys.c' and 'src/base/pdf-fsys.h'.

The filesystem interface is documented in the Reference Manual. Details about the design of the filesystem module can be found in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Filesystem_Module

Note that the implementation of the disk filesystem should be portable enough to work in both POSIX and Windoze systems. The utilization of gnulib modules (see http://www.gnu.org/software/gnulib) is the preferred way to deal with portability issues. If you dont know how to import a gnulib module then please ask the maintainer.


** DONE Stream module implementation
   [2008-06-16 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The stream module (documented in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Stream_Module) should be implemented.

** DONE Stream module infrastructure implementation
   [2008-06-16 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The infrastructure code of the stream module cover:

- pdf-stm.[ch]
- pdf-stm-filter.[ch]
- pdf-stm-mem.[ch]
- pdf-stm-file.[ch]


** DONE ASCII 85 Filter Implementation
   [2008-06-16 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: sfohey
   :PercentComplete: 100
   :END:

The existing ASCII85 encoding and decoding filters implementation should be adapted to use the new
interfaces and architecture described in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Stream_Module

The source files containing the current implementation are pdf-stm-f-a85.[ch]


** DONE ASCII Hex Filter Implementation
   [2008-06-16 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The existing ASCII Hex encoding and decoding filters implementation should be adapted to use the new
interfaces and architecture described in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Stream_Module

The source files containing the current implementation are pdf-stm-f-ahex.[ch]


** DONE Flate Filter Implementation
   [2008-06-16 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

The existing Flate encoding and decoding filters implementation should be adapted to use the new
interfaces and architecture described in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Stream_Module

The source files containing the current implementation are pdf-stm-f-flate.[ch]


** STARTED LZW Filter Implementation
   [2008-06-16 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 50
   :END:

The existing lzw encoding and decoding filters implementation should be adapted to use the new
interfaces and architecture described in http://gnupdf.org/manuals/gnupdf-arch.html/Stream-module.html#Stream-module

The source files containing the current implementation are pdf-stm-f-lzw.[ch]


** NEXT Predictor Filter Implementation
   [2008-06-16 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

The existing Predictor encoding and decoding filters implementation should be adapted to use the new
interfaces and architecture described in http://gnupdf.org/manuals/gnupdf-arch.html/Stream-module.html#Stream-module

The source files containing the current implementation are pdf-stm-f-pred.[ch]


** DONE RunLength Filter Implementation
   [2008-06-16 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

The existing Run Length encoding and decoding filters implementation should be adapted to use the new
interfaces and architecture described in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Stream_Module

The source files containing the current implementation are pdf-stm-f-rl.[ch]


** STARTED CCITT (Fax) Filter Implementation
   [2008-06-16 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 10
   :END:

The CCITT encoding and decoding filters should be implemented. They should use the interfaces and architecture described in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Stream_Module

We dont want to write a new implementation of the CCITT fax encoding if we can avoid it, so this task includes the study of existing implementations.


** DONE Code coverage analysis and report
   [2008-06-19 Thu]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

Code coverage analysis should be integrated in the build.

A configure option --enable-code-coverage should activate the pertinent gcc options and Makefile.am actions to generate gcov statistics when unit tests are ran.

An html report should be generated in prmgt/ using the lcov program. The autobuild script in gnupdf.org will then udpdate the report somewhere in http://www.gnupdf.org


** DONE Automatic generation of the Sources Guide
   [2008-06-19 Thu]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

It is getting hard to maintain the http://www.gnupdf.org/Lib:Sources page up-to-date. The proposed solution is to write a script in prmgt/ that will traverse the sources directories searching for MANIFEST.wiki files. Each MANIFEST.wiki file will contain a description of the meaning of the directory and a little description of each file existing in that directory.

Please ask in pdf-devel@ for more information about this task.

 
** DONE Missing usage example section in the wiki
   [2008-06-28 Sat]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The wiki output generated by texi2html is not including the "Usage example" section in function definitions. 
** DONE Inline warnings with gcc 4.3
   [2008-07-20 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The compilation of the library with gcc-4.3 raises some errors about the inlined functions in the list and the hash module. For example:

./base/pdf-list.h:971: warning: 'gl_sortedlist_indexof_from_to_inline' is static but used in inline function 'pdf_list_sorted_indexof_from_to' which is not static

It seems that the management of inline functions changed in gcc 4.3. The code should be fixed in order to actually get the inline of the code done.

** DONE Memory disposal functions for hash entries
   [2008-07-20 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

The hash module should be modified to allow the specification of
memory disposal functions in entry insertion time.


** DONE Crypt module design
   [2008-07-29 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: davazp
   :PercentComplete: 100
   :END:

The design of the crypt module should be written down and uploaded to http://www.gnupdf.org/Lib:Architecture/Base_Layer/Crypt_Module

The requirements for the module should be discussed in the development mailing list.
** DONE Crypt module API design
   [2008-07-29 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: davazp
   :PercentComplete: 100
   :END:

The API of the crypt module should be designed and written down in the Reference Manual (gnupdf.texi) under the "Encryption Module" section in the "Base Layer" chapter.


** DONE Crypt module unit tests design
   [2008-07-29 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: davazp
   :PercentComplete: 100
   :END:

Unit tests for the functions pertaining to the Crypt Module should be designed and written down in the Tests Specification Document (gnupdf-tsd.texi).


** DONE Crypt module unit tests implementation
   [2008-07-29 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: davazp
   :PercentComplete: 100
   :END:

The unit tests for the Crypt Module should be implemented. The description of the tests is in the Tests Specification Document, section "Encryption Module Tests".

** DONE Crypt module implementation
   [2008-07-29 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: davazp
   :PercentComplete: 100
   :END:

The Crypt Module should be implemented.

The design of the module is in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Crypt_Module

The API of the module is in the GNU PDF Library Reference Manual, section "Encryption Module".


** DISCARDED pdf_char_t sign
   [2008-08-19 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

The 'pdf_char_t' is defined in 'pdf-types.h' as:

typedef unsigned char pdf_char_t;

It is quite common to pass both pdf_char_t and pdf_char_t* values to system functions expecting 'char' and 'char*' values.

The problem is that in some architectures (notably intel) the char data type is signed, and thus we get warnings like:

pointer targets in passing argument 1 of 'freopen' differ in signedness

Some places in the codebase makes use of explicit (char *) casts to avoid the warnings, but would be much better to change the definition of pdf_char_t to be a synonim of char (instead of unsigned char).

This task involves to:

1) Change the definition of pdf_char_t to be a synonim of char
2) Remove all the spurious (char *) casts from the codebase
3) Make sure that no code in the codebase relies on the sign of pdf_char_t

** DONE Improve the accuracy of the api consistency report
   [2008-09-13 Sat]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

The script that generates the API consistency report (http://www.gnupdf.org/Lib:API_Consistency_Report) is not working properly.

A lot of functions are marked as non-implemented in the report despite de fact they are implemented in the source code of the library.

The script prmgt/check-api-doc-consistency.pl should be modified to not generate false negatives.


** DONE Adapt existing sources to provide opaque pointers
   [2008-09-17 Wed]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The source code of the several modules in the base layer should be modified to provide "opaque pointers" to the user (also known as the "pimpl idiom").
** DONE Document the usage of opaque pointers in the hackers guide
   [2008-09-17 Wed]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

Document the usage of "opaque pointers" in the hackers guide.
** DONE Unit tests for the hash-helper
   [2008-09-22 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

Some unit tests for the hash-helper functionality should be documented in gnupdf-tsd.texi and implemented in torture/unit/base/hash/


** DONE JBIG2 filters implementation
   [2008-09-28 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The JBIG2 filters should be implemented. We will use the jbig2 decoding library by Artifex (it is now distributed under the GPLv2+, so we can use it). There are some patents-related problems for the encoding. These problems will be discussed in the mailing list.


** DONE Encryption filters implementation
   [2008-10-03 Fri]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: davazp
   :PercentComplete: 100
   :END:

The encryption filters in the stream module should be written. The filters implementation should make use of the routines implemented in the pdf-crypt module.
** NEXT JPX Filters Implementation
   [2008-10-05 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

Filters for JPEG2000 encoding and decoding should be written. 

We can use the http://www.openjpeg.org/ library to implement the filters. The jasper library is also an option.


** STARTED DCT Filters Implementation
   [2008-10-05 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 40
   :END:

Filters for JPEG encoding/decoding should be written.

We can use the libjpeg library to implement the filters. http://www.ijg.org/
** DONE Integration of the funtions code in pdf-fp
   [2008-11-02 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The implementation of pdf functions from hardy falk (attached to this task) should be integrated in the pdf-fp module. 

Note that the pdf_func_t is going to be a base layer defined type.

Please notify to the mailing list before to take this task.

** DONE Add unit tests for pdf_hash with numeric keys
   [2008-11-15 Sat]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

We are lacking unit tests for pdf_hash variables using numeric indexes.
Look at http://www.gnupdf.org/prmgt/coverage/src/base/pdf-hash.c.gcov.html for detailed information about the code that is not executed with the current tests.
** NEXT Set up a mingw autobuild in gnupdf.org
   [2008-11-26 Wed]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

This task is about the set up of a mingw based daily build in gnupdf.org, including the execution of the library test suite using wine.

If you take this task you will need an account on the chapters.gnu.org machine. Please ask pdf-maintainer@gnu.org.


** STARTED Document the filter parameters in the reference manual
   [2008-11-26 Wed]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 20
   :END:

The parameters used by the filter implementations (via a hash table) should be documented in the Reference Manual. If you take this task please send an email to pdf-devel@ in order to discuss the details.

** DONE Make the text module tests to work with opaque pointers
   [2008-11-29 Sat]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

Some unit tests of the text module (in torture/unit/base/text/) are dereferencing pdf_text_t pointers. It is no longer working since the pdf-text module now publish "opaque pointers" in the public header file pdf.h.

There are two possible solutions for this problem:

  1) To change the design of the tests to not have to use the internals of pdf_text_t
  2) To introduce a "testing" API in pdf_text providing access to the internal fields.

This issue should be discussed in pdf-devel@, so if you want to take this task please send an email there.

To get the compilation errors just compile the unit tests with -DDEACTIVATED.


** DONE make check-api-doc-consistency.pl works with array arguments
   [2008-12-27 Sat]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

The prmgt/check-api-doc-consistency.pl script is not working properly with function prototypes containing array parameters such as:

pdf_status_t pdf_fp_func_0_new (pdf_u32_t m,
                                pdf_u32_t n,
                                const pdf_real_t domain[],
                                const pdf_real_t range[],
                                pdf_u32_t size[],
                                pdf_u32_t bps,
                                pdf_u32_t order,
                                const pdf_real_t encode[],
                                const pdf_real_t decode[],
                                pdf_char_t *samples,
                                pdf_size_t samples_size,
                                pdf_fp_func_t *function);


** NEXT write unit tests filtering wrong data
   [2008-12-27 Sat]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

We need to test the behavior of the stream filters when filtering wrong input data. The test cases for the existing filters are missing that kind of negative tests.


** DONE Describe the crypt module operations in the architecture page
   [2009-01-04 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The architecture page for the crypt module in http://www.gnupdf.org/Lib:Architecture/Base_Layer/Crypt_Module lacks a brief description of the operations provided by the module. The corresponding section is marked with TBD.

** STARTED Complete unit tests for type 4 functions
   [2009-01-08 Thu]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 60
   :END:

The unit tests in torture/unit/base/fp/pdf-fp-func-eval.c concerning type 4 (postscript) functions are not covering all the implemented operators in src/base/pdf-fp-function.[ch].

This task includes the following steps:

  1. Determine the postscript operators needing testing.
  2. Design unit tests for these operators in doc/gnupdf-tsd.texi
  3. Implement the unit tests in torture/unit/base/fp/pdf-fp-func-eval.c

Notes:

The coverage report at http://www.gnupdf.org/prmgt/coverage may be useful to determine which postscript functions are not covered by tests.

Please use the same general mechanism used in the existing type 4 functions tests.

Don't use floating point function from glibc directly! Use the wrappers in src/base/pdf-fp.h instead. If you need to introduce a new wrapper, please do it. Note that the pdf_real_t data type is encapsulating a single precision floating point number, and thus the code in src/base/pdf-fp.c should be using the single-precision version of the libc functions.

Please run the tests in both 32 and 64 bits machines.
 
** DONE Error management in type 4 functions
   [2009-01-19 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: davazp
   :PercentComplete: 100
   :END:

From the ISO PDF reference, section 7.10.5.2, "Errors in Type 4 Functions":

   "The part of a conforming reader that reads a type 4 function (analogous to the PostScript scanner) shall detect and report syntax errors. Any rerror detected by the conforming reader shall be errors in the PDF file and shall be handled like other errors in the file.

    The part of a conforming reader that executes a type 4 function (analogous to the PostScript interpreter) shall detect and report errors. This specification does not define a representation for the errors; those details shall be provided by the conforming reader that processes the PDF file. The following types of errors can occur (among others):
   
     - Stack overflow.
     - Stack underflow.
     - A type error (for example, applying 'not' to a real number).
     - A range error (for example, applying 'sqrt' to a negative number).
     - An undefined result (for example, dividing by 0)"

This task involves the following steps:

1) Determine a way for the 'pdf_fp_func_4_new' function to communicate syntax errors to the caller (an extra out parameter to the function seems to be a sensible way to achieve this).

2) Determine a list of syntax errors that will be managed and reported by 'pdf_fp_func_4_new'.

3) Determine a way for the 'pdf_fp_func_eval' function to communicate type 4 interpretation errors to the caller. Note that 'pdf_fp_func_eval' is used to evaluate type 0, type 2 and type 3 functions, so the solution should be quite generic (we may find useful to report errors in a detailed way from the evaluation of the other types of functions).

4) Determine a list of interpretation errors for type 4 functions that will be managed and reported by 'pdf_fp_func_eval'.

5) Implement the actual detection and reporting of errors.

6) Adapt the existing type 4 function unit tests to use the new API and write down negative unit tests to test the reporting of any defined syntax or interpretation error.

Please make sure to report to pdf-devel@ the results of 1), 2), 3) and 4) before to proceed with the actual implementation: we may want to brainstorm it.

** DONE Use the disk filesystem in pdf-filter
   [2009-01-19 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The pdf-filter utility (implementation in utils/pdf-filter.[ch]) is currently using memory-based streams in both read and write mode (by default it uses write mode. The use of --readmode makes it to use read mode). Would be good to have the option to use the filesystem backend of the streams as well.

This task involves the following steps:

1) Implement two new command line options for pdf-filter:

   --input-file, -i
       Use a given file as the input.

   --output-file, -o
       Use a given file as the output. If the file already exists it is truncated.

2) Make pdf-filter to use filesystem files (as implemented in the Filesystem Module) for both reading and writing data if -i and/or -o are specified in the command line.


** NEXT Dependencies detection in configuration time
   [2009-01-25 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

The configure script should fail if some dependency is missing (such as a library).

The user configuring the sources then will have the possibility to explicitly disable (if it is possible) the library facilities using the missing dependency.


** DONE Tokeniser Module API design
   [2009-01-25 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: mgold
   :PercentComplete: 100
   :END:

The API of the tokeniser module should be designed and documented in the Reference Manual (doc/gnupdf.texi).


** NEXT Tokeniser Module Architecture Description
   [2009-01-25 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

A brief description of the tokeniser module should be added to the architecture guide (doc/gnupdf-arch.texi).

The contents about the Base Layer should be updated in order to include the new module (diagrams, etc).


** NEXT Unit tests for the Tokeniser Module
   [2009-01-25 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

A set of unit tests should be designed and implemented in torture/unit/base/tokeniser/


** STARTED Implementation of the Tokeniser Module
   [2009-01-25 Sun]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

Implementation of the tokeniser module in src/base/pdf-tokeniser-*.[ch]


** DONE pdf-filter should emit a warning when a filter fail
   [2009-01-26 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The pdf-filter utility (implemented in utils/pdf-filter.[ch]) is silently exiting when after the failure of some filter.

If at some moment the application of a filter fails, the utility should:

1) Emit an informative message in the standard error descriptor.
2) Return an error code to the operating system.


** DONE Add unit tests for pdf_stm_flush
   [2009-01-27 Tue]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: jemarch
   :PercentComplete: 100
   :END:

The 'pdf_stm_flush' function in the Stream module is lacking unit tests in
torture/unit/base/stm/

Both positive and negative tests shall be written, testing any possible
return value.


** DONE Add cplusplus guards in the generated pdf.h header file
   [2009-04-06 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

The file src/Makefile.am should be modified to include a cplusplus guard in the generated pdf.h file, like in:

#ifdef _cplusplus
extern "C" {
#endif

... contents of pdf.h...

#ifdef _cplusplus
} // extern "C"
#endif

** DONE Add unit tests for streams operating files
   [2009-04-17 Fri]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: gerel
   :PercentComplete: 100
   :END:

The unit tests for the stream module shall be expanded to cover the use of file-based streams.

In particular, tests for pdf_stm_file_new shall be added. All the reading/writing/seek/filtering capabilities shall be tested when operating a fsys file.


** DONE c99 inline semantics are not working properly
   [2009-05-13 Wed]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: davazp
   :PercentComplete: 100
   :END:

The PDF_INLINE mechanism implemented in src/base/pdf-types.h and used in some modules is not working properly.

When compiling with gcc 4.3 (that is using c99 inline semantics by default) we get warning messages about using static inline functions in non-static inline functions:

   In file included from ./base/pdf-hash.h:30,
                    from ./base/pdf-stm.h:54,
                    from base/pdf-stm.c:31:
   ./base/pdf-list.h: In function 'pdf_list_new':
   ./base/pdf-list.h:198: warning: 'gl_list_create_empty_inline' is static but used in inline function 'pdf_list_new' which is not static


** NEXT JBIG2 encoder filter implementation
   [2009-05-14 Thu]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

A JBIG2 encoder filter should be implemented in src/base/pdf-stm-f-jbig2.[ch] (the decoding filter is already in place).

The filter implementation can use the jbig2enc library, available in http://linux.softpedia.com/get/Multimedia/Graphics/jbig2enc-12473.shtml

** STARTED Type checking in type 4 functions
   [2010-01-09 Sat]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 90
   :END:

The type 4 functions implementation in pdf-fp-func.[ch] uses a stack of
real values.  Specific real values are used to represent TRUE, FALSE and the integer values.

Several problems with that approach have been identified:

- Some of the functions implemented (such as mod) requires operands of a specific types,
  while others (such as and,or,xor,not) have a different behavior depending on the type
  of the arguments.

- The resulting values in the stack left by the PDF function evaluation shall be
  real values (maybe coerced from integer values), and not booleans.  The latter shall be 
  considered an error, and reported by pdf_fp_eval as such.

To fix those problems we need to tag the elements of the stack with a explicit type.

See http://lists.gnu.org/archive/html/pdf-devel/2010-01/msg00016.html for more information.


** NEXT http filesystem implementation
   [2009-05-18 Mon]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

A read-only http filesystem implementation for the filesystem module shall be developed.

- The implementation shall be implemented using the 'pdf-fsys-html-' prefix.

- The implementation shall implement the interface documented in http://gnupdf.org/manuals/gnupdf-manual/html_node/The-Filesystem-Implementation-Interface.html#The-Filesystem-Implementation-Interface In particular it should implement the read-in-advance capabilities.

- The http filesytem implementation shall be documented in the reference manual (doc/gnupdf.texi) as a section of the "The Filesystem Module" chapter.

- The architectural and internal design of the implementation shall be documented in the GNU PDF Library Architecture Guide (doc/gnupdf-arch.texi).

- It is suggested to use the libcurl (http://curl.haxx.se/libcurl) library in order to implement the access to http.


** NEXT Possible memory overflow in the bignums implementation
   [2009-06-13 Sat]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

Brad Hards reported the following:

Start with types. It appears to have one issue:
base/types/pdf-i64-div.c:168:E:pdf_i64_div:pdf_i64_div_005:0: (after this point) Received signal 11 (Segmentation fault)

I'm pretty confident that there is a buffer overflow, but I have no ideas
what the fix is.

I added an assert that triggers on the problem, but don't have a real
fix.
--- src/base/pdf-types.c        2009-03-03 22:26:28 +0000
+++ src/base/pdf-types.c        2009-06-13 08:27:12 +0000
@@ -26,6 +26,7 @@
 #include <pdf-types.h>
 #include <pdf-alloc.h>

+#include <assert.h>

 #ifndef PDF_USE_BUILTIN_64BIT_SUPPORT

@@ -766,6 +767,7 @@
           pdf_i64_subtraction(&temp, temp, v_pdf, p_status);

           /*We finally put q_bar in the results array*/
+          assert (j < (sizeof(q)/sizeof(q[0])));
           q[j] = q_bar;
           /*If the remainder is less than zero then we re-add the divisor and subtract one from q
             Step D6*/

Anyone understand what is actually going wrong?

** NEXT Documentation of the pdf-filter utility in the Utilities Manual
   [2009-06-24 Wed]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

A chapter documenting the pdf-filter utility in utils/ shall be written and incorporated into the Utilities Manual (doc/gnupdf-utils.texi).

** NEXT Documentation of the pdf-tokeniser utility in the Utilities Manual
   [2009-06-24 Wed]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

A chapter documenting the pdf-tokeniser utility in utils/ shall be written and incorporated into the Utilities Manual (doc/gnupdf-utils.texi).

A description of the language used by the utility to print the sequence of tokens (basically a sequence of TOKEN_TYPE(TOKEN_VALUE) strings separated by newlines) shall be included.


** NEXT Deprecate nocheck in favour of CVS check
   [2009-08-06 Thu]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 0
   :END:

Currently we are using a simple 'check' replacement named 'nocheck' to run the unit tests in mingw32 with wine.

nocheck does not provide support for fixtures nor other advanced capabilities of 'check'.  Fortunately, it seems that the CVS version of 'check' (available on http://check.sf.net) is supporting mingw32 in no-fork mode.

The steps of this task are:

1. Try the CVS version of check and determine if it is able to run our unit tests in mingw32 using wine.
2. Communicate the results of the investigation to pdf-devel@

At that point we will decide what to do with nocheck: to keep it in the sources tree for future uses, or to completely remove it.


** DONE Make dist and distcheck targets to work
   [2010-02-18 Thu]
   :PROPERTIES:
   :OpenedBy: jemarch
   :ClosedBy: aleksander
   :PercentComplete: 100
   :END:

The targets:

    make dist
    make distcheck

are not working.


** NEXT Fix probable problem with array subscript in ASCII85 decoder
   [2010-02-20 Sat]
   :PROPERTIES:
   :OpenedBy: jemarch
   :PercentComplete: 100
   :END:

We are getting the following warnings while compiling the library.  It may indicate a possible buffer overflow. The declaration of 'pdf_stm_f_a85_write_outbuff' shall be deleted if it won't be used at all.

/bin/bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.  -I../lib -I../build-aux -I./base -I./object -I./document  -Wall -fno-strict-aliasing -I/usr/local/include  -g -O2 -MT pdf-stm-f-a85.lo -MD -MP -MF .deps/pdf-stm-f-a85.Tpo -c -o pdf-stm-f-a85.lo `test -f 'base/pdf-stm-f-a85.c' || echo './'`base/pdf-stm-f-a85.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../lib -I../build-aux -I./base -I./object -I./document -Wall -fno-strict-aliasing -I/usr/local/include -g -O2 -MT pdf-stm-f-a85.lo -MD -MP -MF .deps/pdf-stm-f-a85.Tpo -c base/pdf-stm-f-a85.c  -fPIC -DPIC -o .libs/pdf-stm-f-a85.o
base/pdf-stm-f-a85.c:50: warning: 'pdf_stm_f_a85_write_outbuff' declared 'static' but never defined
base/pdf-stm-f-a85.c: In function 'pdf_stm_f_a85dec_apply':
base/pdf-stm-f-a85.c:775: warning: array subscript is above array bounds


* PDF Knowledge Database
* GNU Juggler
* Epilog

#+SEQ_TODO: |