Core APIs

I am now kind of finalizing the v1 of the APIs for the PDF library or the core of the PDF reader library. Here are the initial benefits of the library.

• It will allow you to read through a PDF file and create objects which can be used for further access to the document.
• It will also provide you the details of the content in every page and create a tree like data structure of PDF page contents which can be used know what is there in the PDF document.
• The library has been tested with about 800+ text based files (12000+ pages) so fairly robust in text objects. And the parser is fairly robust and a bit non-tolerant as a standards based file is given higher emphasis.

However, next steps to extend the library requires specific domain where it will be used. For example, in the text extraction itself here are some standard challenges:

• PDF texts do not have reading order aligned to character appearance. So text may appear as "aliuJ" with each character location in such a way printed such that the visual output is "Julia".
• Text and graphics directives can be interspersed. So you may get 5 different text objects as each character.
• Since, fonts can be sub-setted "Julia" may be printed as (uvwxy) with gyph code of embedded font-51. One needs to query these judiciously with several logical smart reasoning to get the actual text.
• Every such reasoning is subjective to the needs and interpretation of the developer/user and can be challenged with an alternate viewpoint. Hence, it's important to keep the low level APIs simple and minimal such that any advanced development can be carried out on top of the minimal API set.

After some thoughts I realized I will rather keep the base APIs simple and minimal. Thus providing more flexibility to developers to develop more advanced solutions they need.

Of course there are a few areas in the basic APIs that are missing currently:

• Enhancing the documentation of the library.
• Support for encrypted PDF
• Support for image filters. This has been knowingly avoided as most people may be using a third party API to render the final graphics. They could send the encrypted image in JPEG or JPX or LZW (TIFF, PNG, GIF) formats than decompressing and sending raw image to the rendering API.
• Standardize the tree iterator with AbstractTrees APIs.
• Develop what is needed as the adoption of APIs increase than following another API available in the market.

If you are all in agreement with my approach, I will register the PDFIO to Julia Package so that it's available for general usage and testing.

Looking to hear from you soon.

regards,

Sambit