I know the feeling :/ Generally speaking, PDF::API2 is powerful but old and of poor quality, while CAM::PDF is clean but slow and lacks features. Specifically, CAM::PDF eagerly loads the whole file in memory before anything else, while more advanced libraries like PDF::API2 take a lazy and more efficient approach.
The truth is, the PDF specification is 1300+ pages and growing. I don't think any of these packages is ever going to implement it fully and correctly, while still providing additional abstraction layers and tests (workload x2) and a comprehensive documentation (workload x3).
PDF::API2 is on the right path as far as code structure goes, but has no tests (assume it's broken ;-) and its meager documentation requires that you know the PDF specs already. On the other hand, the CAM::API2 code is of much higher quality (tests, docs) while less advanced, and the library as a whole is begging for a redesign (106 methods in the one public class, yuck). Volunteers, anyone? :-)
In reply to Re^3: PDF::API2 importpage problem
by waba
in thread PDF::API2 importpage problem
by leocharre
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |