Votes for Transparent API’s
**A brief word on the response to last week’s missive regarding ‘functional’ and ‘transparent’ API’s.**
After my last post, we received two serious inquiries from existing customers about whether (and when) PDFTextStream will provide a transparent PDF API. The general message of these inquiries is that, even though specific applications that are using PDFTextStream require and benefit from its decidedly functional API (focussed on content extraction), it’s occasionally useful or necessary to dig a little deeper into a PDF for other reasons.
Specifically, these customers have been using PDFBox or PJ in order to look at the guts of PDF documents in a way that PDFTextStream doesn’t currently provide for. These usages aren’t in production environments — in both cases, the transparent API’s are being used in a support or troubleshooting role, especially with poorly-formed PDF documents.
Nevertheless, it’s always better to provide a complete solution, as these two customers have pointed out. Ergo, it looks like we’ll be providing a transparent API ’some time soon’, and hopefully we’ll be able to navigate the technical difficulties likely to crop up when deploying transparent and functional API’s simultaneously. More as it happens, etc.