Archive for the 'GNU PDF' Category

PDF standards comparison: PDF/A vs PDF 1.4

3 Comments

The PDF file format, far from being a unique language definition, gathers an extensive family of sublanguages (which we friendly call dialects) and specifications. These specifications make the format richer, and allow a better fitting between the language restrictions and requirements of real scenarios. On the other hand, the library has to consider all these sublanguages and specifications to correctly read and write PDF files.

Thus, these specifications must be studied, compared and formalised, in order to allow the GNU PDF Library provide an API capable of processing syntax and semantics accordingly.

This study is contained in the GNU PDF Knowledge base, available here. Until now, only the comparison between PDF/A and PDF 1.4 is available, but more sublanguages of the PDF family are coming in the near future. Stay tunned!

1,000 visitors, thank you!

2 Comments

In its very first 5 months of life, Portable Document Features has reached 1,000 visitors. Most of you have been coming from gnupdf.org or planet.gnu.org, but some others have reached the blog googling around about how to install the GNU PDF Library on your systems, how to start up with hacking the lib or just engaging some discussion on the lib issues. The goal for the next months, as I will be finishing my FDP, is to continue reporting library hacks and log a more low-level trace of what I’m exactly hacking :)

Thank you very much for you support!

Dealing with errors in the GNU PDF Library

3 Comments

The most effective debugging tool is still careful thought, coupled with judiciously placed print statements (Brian Kernighan)

The GNU PDF project takes testing very seriously. Despite this, while programming functionalities that rely on uderlying modules, a returning value reporting if something went wrong in a call has a very high value. So, in this post I am going to explain how to output typical errors in the stderr stream when we are calling almost any functionality in the pdf.h interface.

The key data type here is pdf_status_t. As you can see in the reference manual, almost any function returns a pdf_status_t. For instance, supose that we are creating a new token reader (or tokeniser) for a given stream; the header is

pdf_status_t pdf_token_reader_new (pdf_stm_t stm, pdf_token_reader_t *reader)

The return value can be compared typically with a PDF status value like PDF_OK or PDF_ERROR this way

  1. if (pdf_token_reader_new (stream, &reader) != PDF_OK)

in order to treat error flows. But sometimes we want to know what kind of error happened, instead of knowing if some did occur. To achieve this, we need a function that outputs the corresponding error message to stderr:

void pdf_perror (const pdf_status_t status, const char *str)

Calling it, we get a description of the status contents for a given pdf_status_t data type. So, in our example, this code

  1. pdf_status_t token_stat;
  2. pdf_token_reader_t reader;
  3.  
  4. token_stat = pdf_token_reader_new (stream, &reader);
  5.  
  6. if (token_stat != PDF_OK)
  7.   {
  8.     printf("ERROR creating tokeniser\n");
  9.     pdf_perror(token_stat, NULL);
  10.   }

easily helps us to know what happened if something went wrong. Note that the pdf_perror function gets a desired string to concatenate to the error message as the second parameter.

IMPORTANT UPDATE: Please read Aleksander’s comments here, containing very useful and updated information about new error reporting / printing procedures.