Post without Account — your post will be reviewed, and if appropriate, posted under Anonymous. You can also use this link to report any problems registering or logging in.

PDF::API2 Version

  • 2 Replies
  • 2023 Views
*

Offline sciurius

  • Jr. Member
  • **
  • 67
    • View Profile
    • Website
PDF::API2 Version
« February 10, 2017, 08:14:00 AM »
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?

*

Offline Phil

  • Global Moderator
  • Sr. Member
  • *****
  • 430
    • View Profile
Re: PDF::API2 Version
« Reply #1: February 10, 2017, 09:21:59 AM »
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.
« Last Edit: February 10, 2017, 11:52:59 AM by Phil »

*

Offline Phil

  • Global Moderator
  • Sr. Member
  • *****
  • 430
    • View Profile
Re: PDF::API2 Version
« Reply #2: February 10, 2017, 12:03:17 PM »
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]
« Last Edit: May 09, 2017, 11:05:19 AM by Phil »