[sciurius]

First of all, I applaud Phil's initiative to bring PDF::API into the 21st century. I do regret, however, that this seemed only possible via a fork.

I understand the reasoning to stick to PDF::API2 and increase the version to 3.x. But I do foresee some critical problems with this.

For most of my software, customers rely on CPAN to install dependent modules. Eventually, the new PDF::API2 must be submitted to CPAN. This will just not work, unless Steve Simms, the current owner of PDF::API2, effectively passes ownership to Phil.
Also, there is nothing witholding Steve to bump the version of his PDF::API2 to 3.x or higher, causing much more confusion.

The best suggestion I can make is to go for a new name. Since PDF::API2 is object oriented, the name is used only very few times: in the "use" and when creating the document. So the required changes will be minimal. Maybe Phil can ask Otto Hirr to transfer the namespace of his pre-alpha and very obsolete PDF::API3? Or maybe a totally different name?

[Phil]

To be honest, having to do a fork was very unpleasant for me, too. I tried coöperating with Steve Simms and submitted updates to him. He accepted some, but my major rewrite of Content.pm he simply threw away without even telling me (when I asked what had happened, he said it was "too big for him"). It was impossible to re-order Content and massively update the POD (as well as substantial code improvements) while providing the changes to him in only bite-sized chunks.

It's not just a few places in the code where "API2" is used. The whole world refers to the library as "PDF::API2", not "PDF::API, version 2". I was concerned that calling it API3 or API4 would mean it would get lost in the shuffle, so to speak — no one would recognize it for what it is.

Otto's API3 has some code changes in it. Someone reported that the bar code routines worked much better than API2's, so evidently something has changed. I'm reluctant to overwrite all his work and lose it (of course, it could be archived off to the side, I suppose).

I'm open to suggestions on all these issues, before v3.xxx gets enough momentum to make it difficult to change course.

Add: By the way, one thing I considered doing was to offer just a "delta" library of my changed routines, leaving it to PDF::API2 users to merge it into their copy of the official PDF::API2 (v2.xxx) in some manner. I decided not to do it this way because most users would probably regard it as too much work to bother with, just to get some module updates. I felt I needed to have a full distribution in one place.

[Phil]

Speaking of PDF::API2 being "object oriented", one thing I'd like to do is clear up the whole OO structure of this thing (hopefully without breaking properly written existing code). A glance through the sub-libraries (modules) showed what seemed to be a lot of duplication (and worse, near-duplication) of existing code, rather than true inheritance of methods.

We also need to see how Perl objects map to PDF internals. For example, if I instantiate multiple "graphics" objects, are they all acting on the same PDF internals? If I make a setting change (e.g., miter limit) in one graphics object, is it automatically reflected in other graphics objects, or ignored by them (and what is the PDF reader going to do)? If there is just one global pool of PDF settings, changes to one graphics object might be used by all others, but they may think they're still working with the old settings! This needs to be investigated and settled before going much further. [edit: see CTS7 feature request]