I’ve written one before (for similar needs), and I can say this: Have fun. It’s quite a complex task. The PDF specification is large and unwieldy. There are several methods of storing text inside of it. And the kicker is that each PDF generator is different in how it works. So while something like TFPDF or DOMPDF creates REALLY easy to read PDFs (from a machine standpoint), Acrobat makes some really hellish documents.
The reason is how it writes the text. Most DOM based renderers –that I’ve used– write the entire line as one string, and position it once (which is really easy to read). Acrobat tries to be more efficient (and it is) by writing only one or maybe a few characters at a time, and positioning them independently. While this REALLY simplifies rendering, it makes reading MUCH more difficult.
The up side here, is that the PDF format in itself is really simple. You have “objects” that follow a regular syntax. Then you can link them together to generate the content. The specification does a good job at describing the file format. But real world reading is going to take a bit of brain power…
Some helpful pieces of advice that I had to learn the hard way if you’re going to write it yourself:
- Adobe likes to re-map fonts. So character
65will likely not beA… You need to find a map object and deduce what it’s doing based upon what characters are in there. And it is efficient since if a character doesn’t appear in the document for that font, it doesn’t include it (which makes life difficult if you try to programmatically edit a PDF)… - Write it as abstract as possible. Write classes for each object type, and each native type (strings, numbers, etc). Let those classes parse for you. There will be a fair bit of repetition in there, but you’ll save yourself in the end when you realize that you need to tweak something for only one specific type)…
- Write for a specific version or two of the PDF spec, and enforce it. Check the version number, and if it’s higher than you expect, bail… And don’t try to “make it work”. If you want to support newer versions, break out the specification and upgrade the parser from there. Don’t try to trial and error your way up (it’s not fun)…
- Good luck with compressed streams. I’ve found that typically you can’t trust the length arguments to verify what you are uncompressing. Sometimes (for some generators) it works well… Others it’s off by one or more bytes. I just attempt to deflate it if the filter matches, and then force the length…
- When testing lengths, don’t use
strlen. Usemb_strlen($string, '8bit')since it will compensate for different character sets (and allow potentially invalid characters in other charsets).
Otherwise, best of luck…