Bug #119962 for PDF-API2: Found a bug when creating a new XObject Form

Tue Jan 24 14:26:00 2017 james.harper [...] rrd.com - Ticket created

Subject:	Found a bug when creating a new XObject Form
Date:	Tue, 24 Jan 2017 12:25:46 -0700
To:	bug-PDF-API2 [...] rt.cpan.org
From:	James Harper <james.harper [...] rrd.com>

The problem is in FormType. Randomly we get a value other then a 1. Then the XObject doesn't display in the pdf. If I go into the generated PDF and alter the FormType back to 1, then it displays. I am not sure why this is happening. But it would be great if you could fix that. Thank you. -- *James L. Harper* | *Software Engineer IV (Supervisor)* | *RR Donnelley* 630 W 1000 N | Logan, UT 84321 | Voice: 435-755-4455 | Cell: 435-770-3289 | Fax: 435-753-7002 Email: james.harper@rrd.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Thu Jan 26 10:02:40 2017 steve [...] deefs.net - Correspondence added

On Tue Jan 24 14:26:00 2017, james.harper@rrd.com wrote: Show quoted text

> The problem is in FormType. Randomly we get a value other then a 1. Then > the XObject doesn't display in the pdf. > > If I go into the generated PDF and alter the FormType back to 1, then it > displays. I am not sure why this is happening. But it would be great if > you could fix that.

Can you provide a sample script that reproduces this problem? What other values have you seen? At a glance, I don't see why the FormType would ever be set to something other than 1. There's only one reference to FormType in the PDF::API2 code, in Resource/XObject/Form.pm: $self->{'FormType'} = PDFNum(1);

Thu Jan 26 10:02:41 2017 The RT System itself - Status changed from 'new' to 'open'

Thu Jan 26 10:02:46 2017 steve [...] deefs.net - Status changed from 'open' to 'stalled'

Thu Jan 26 10:19:00 2017 james.harper [...] rrd.com - Correspondence added

Subject:	Re: [rt.cpan.org #119962] Found a bug when creating a new XObject Form
Date:	Thu, 26 Jan 2017 08:18:43 -0700
To:	bug-PDF-API2 [...] rt.cpan.org
From:	James Harper <james.harper [...] rrd.com>

I did see that code and I was confused as to how it could be anything other then a 1 also. But I have seen FormType 500 and FormType 1000 On some XObjects. It is intermittent 99+ percent of them are just fine. I could not see anything about those objects that would break it. Like I said I can go into the raw pdf after and alter those numbers, keeping the spacing for the xref entry, and they work just fine after that. As for getting you an example, I can't because it is private data. I can tell you the process that I am using is importintoform and we are taking two pages and putting them into one. Are are also adding a barcode. It is the barcode form that is the one that is broken. It just won't appear in the output PDF, and shows an error in Adobe. Sorry. that is about all I have. On Thu, Jan 26, 2017 at 8:02 AM, Steve Simms via RT < bug-PDF-API2@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=119962 > > > On Tue Jan 24 14:26:00 2017, james.harper@rrd.com wrote:

> > The problem is in FormType. Randomly we get a value other then a 1.

> Then

> > the XObject doesn't display in the pdf. > > > > If I go into the generated PDF and alter the FormType back to 1, then it > > displays. I am not sure why this is happening. But it would be great if > > you could fix that.

> > Can you provide a sample script that reproduces this problem? What other > values have you seen? > > At a glance, I don't see why the FormType would ever be set to something > other than 1. There's only one reference to FormType in the PDF::API2 > code, in Resource/XObject/Form.pm: > > $self->{'FormType'} = PDFNum(1); >

-- *James L. Harper* | *Software Engineer IV (Supervisor)* | *RR Donnelley* 630 W 1000 N | Logan, UT 84321 | Voice: 435-755-4455 | Cell: 435-770-3289 | Fax: 435-753-7002 Email: james.harper@rrd.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Thu Jan 26 10:19:00 2017 The RT System itself - Status changed from 'stalled' to 'open'

Fri Jan 27 13:22:22 2017 james.harper [...] rrd.com - Correspondence added

Subject:	Re: [rt.cpan.org #119962] Found a bug when creating a new XObject Form
Date:	Fri, 27 Jan 2017 11:21:55 -0700
To:	bug-PDF-API2 [...] rt.cpan.org
From:	James Harper <james.harper [...] rrd.com>

I noticed that you use PDFNum(1) to place the one. Do you have to run a function PDFNum() to place the literal. Or can you just hard code the value "1". Just asking? On Thu, Jan 26, 2017 at 8:02 AM, Steve Simms via RT < bug-PDF-API2@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=119962 > > > On Tue Jan 24 14:26:00 2017, james.harper@rrd.com wrote:

> > The problem is in FormType. Randomly we get a value other then a 1.

> Then

> > the XObject doesn't display in the pdf. > > > > If I go into the generated PDF and alter the FormType back to 1, then it > > displays. I am not sure why this is happening. But it would be great if > > you could fix that.

> > Can you provide a sample script that reproduces this problem? What other > values have you seen? > > At a glance, I don't see why the FormType would ever be set to something > other than 1. There's only one reference to FormType in the PDF::API2 > code, in Resource/XObject/Form.pm: > > $self->{'FormType'} = PDFNum(1); >

-- *James L. Harper* | *Software Engineer IV (Supervisor)* | *RR Donnelley* 630 W 1000 N | Logan, UT 84321 | Voice: 435-755-4455 | Cell: 435-770-3289 | Fax: 435-753-7002 Email: james.harper@rrd.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Mon Jan 30 23:02:03 2017 steve [...] deefs.net - Correspondence added

On Thu Jan 26 10:19:00 2017, james.harper@rrd.com wrote: Show quoted text

> I did see that code and I was confused as to how it could be anything > other > then a 1 also. But I have seen FormType 500 and FormType 1000 > On some XObjects. It is intermittent 99+ percent of them are just > fine. I > could not see anything about those objects that would break it.

Ok, here are a couple of things to try: 1) I just released PDF::API2 version 2.031. It has some fixes that could potentially impact this bug. 2) Is the problem reproducible on a given PDF? In other words, on the 1% or so that fail, do they keep failing if you re-run the script? Given that you're seeing the numbers 500 and 1000 show up, I'm going to guess that the problem *is* reproducible on a given file, and that the affected PDFs have object streams in them, based on a bug I tracked down and fixed for a previous release. That's still relatively new code (added in 2.026), so there are probably still some edge cases that aren't working, which would explain why you're only seeing the problem occasionally. If you can reproduce the problem on a given PDF that you can send to me privately for the sole purpose of troubleshooting this bug, I should be able to get a fix released. -- Steve PS: In regard to your other note, yes, the PDFNum wrapper function does need to be called so that the serializer knows what kind of value to write to the file (e.g. a literal number vs. a name, boolean, string, etc.)

Mon Jan 30 23:02:14 2017 steve [...] deefs.net - Status changed from 'open' to 'stalled'

Wed Feb 08 19:33:12 2017 james.harper [...] rrd.com - Correspondence added

Subject:	Re: [rt.cpan.org #119962] Found a bug when creating a new XObject Form
Date:	Wed, 8 Feb 2017 17:32:54 -0700
To:	bug-PDF-API2 [...] rt.cpan.org
From:	James Harper <james.harper [...] rrd.com>

I am testing now. But I had a follow up question for you. I noticed there is a version PDF::API3. Should I be using that? Do it have all the latest code from the API2 version? On Mon, Jan 30, 2017 at 9:02 PM, Steve Simms via RT < bug-PDF-API2@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=119962 > > > On Thu Jan 26 10:19:00 2017, james.harper@rrd.com wrote:

> > I did see that code and I was confused as to how it could be anything > > other > > then a 1 also. But I have seen FormType 500 and FormType 1000 > > On some XObjects. It is intermittent 99+ percent of them are just > > fine. I > > could not see anything about those objects that would break it.

> > Ok, here are a couple of things to try: > > 1) I just released PDF::API2 version 2.031. It has some fixes that could > potentially impact this bug. > > 2) Is the problem reproducible on a given PDF? In other words, on the 1% > or so that fail, do they keep failing if you re-run the script? > > Given that you're seeing the numbers 500 and 1000 show up, I'm going to > guess that the problem *is* reproducible on a given file, and that the > affected PDFs have object streams in them, based on a bug I tracked down > and fixed for a previous release. That's still relatively new code (added > in 2.026), so there are probably still some edge cases that aren't working, > which would explain why you're only seeing the problem occasionally. > > If you can reproduce the problem on a given PDF that you can send to me > privately for the sole purpose of troubleshooting this bug, I should be > able to get a fix released. > > -- Steve > > PS: In regard to your other note, yes, the PDFNum wrapper function does > need to be called so that the serializer knows what kind of value to write > to the file (e.g. a literal number vs. a name, boolean, string, etc.) >

-- *James L. Harper* | *Software Engineer IV (Supervisor)* | *RR Donnelley* 630 W 1000 N | Logan, UT 84321 | Voice: 435-755-4455 | Cell: 435-770-3289 | Fax: 435-753-7002 Email: james.harper@rrd.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Wed Feb 08 19:33:13 2017 The RT System itself - Status changed from 'stalled' to 'open'

Wed Feb 08 19:46:13 2017 steve [...] deefs.net - Correspondence added

On Wed Feb 08 19:33:12 2017, james.harper@rrd.com wrote: Show quoted text

> I am testing now. But I had a follow up question for you. I noticed > there is a version PDF::API3. > > Should I be using that? Do it have all the latest code from the API2 > version?

No, PDF::API3 was a fork that got created roughly around the same time I took over maintenance of PDF::API2, after the previous maintainer stopped supporting it. We both had the same goal, but the other developer ended up moving on to other projects before making any changes. -- Steve

Wed Feb 08 19:46:19 2017 steve [...] deefs.net - Status changed from 'open' to 'stalled'

Wed Feb 08 19:49:35 2017 james.harper [...] rrd.com - Correspondence added

Subject:	Re: [rt.cpan.org #119962] Found a bug when creating a new XObject Form
Date:	Wed, 8 Feb 2017 17:49:21 -0700
To:	bug-PDF-API2 [...] rt.cpan.org
From:	James Harper <james.harper [...] rrd.com>

I ask because I know the 2of5int barcode seems to work better in the API3 version. So using PDF::API3::Compt::API2 Is not the answer. On Wed, Feb 8, 2017 at 5:46 PM, Steve Simms via RT <bug-PDF-API2@rt.cpan.org Show quoted text

> wrote:

Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=119962 > > > On Wed Feb 08 19:33:12 2017, james.harper@rrd.com wrote:

> > I am testing now. But I had a follow up question for you. I noticed > > there is a version PDF::API3. > > > > Should I be using that? Do it have all the latest code from the API2 > > version?

> > No, PDF::API3 was a fork that got created roughly around the same time I > took over maintenance of PDF::API2, after the previous maintainer stopped > supporting it. We both had the same goal, but the other developer ended up > moving on to other projects before making any changes. > > -- Steve >

-- *James L. Harper* | *Software Engineer IV (Supervisor)* | *RR Donnelley* 630 W 1000 N | Logan, UT 84321 | Voice: 435-755-4455 | Cell: 435-770-3289 | Fax: 435-753-7002 Email: james.harper@rrd.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Wed Feb 08 19:49:35 2017 The RT System itself - Status changed from 'stalled' to 'open'

Thu Feb 09 11:21:48 2017 james.harper [...] rrd.com - Correspondence added

Subject:	Re: [rt.cpan.org #119962] Found a bug when creating a new XObject Form
Date:	Thu, 9 Feb 2017 09:21:22 -0700
To:	bug-PDF-API2 [...] rt.cpan.org
From:	James Harper <james.harper [...] rrd.com>

So I guess I just wanted to know. Do you plan on updating PDF::API2 to use the barcode stuff from PDF::API3::Compat::API2. Like I said. At least the 2o5int barcode works better with that code? Thank you. On Wed, Feb 8, 2017 at 5:49 PM, James Harper <james.harper@rrd.com> wrote: Show quoted text

> I ask because I know the 2of5int barcode seems to work better in the API3 > version. > > So using PDF::API3::Compt::API2 > > Is not the answer. > > On Wed, Feb 8, 2017 at 5:46 PM, Steve Simms via RT < > bug-PDF-API2@rt.cpan.org> wrote: >

>> <URL: https://rt.cpan.org/Ticket/Display.html?id=119962 > >> >> On Wed Feb 08 19:33:12 2017, james.harper@rrd.com wrote:

>> > I am testing now. But I had a follow up question for you. I noticed >> > there is a version PDF::API3. >> > >> > Should I be using that? Do it have all the latest code from the API2 >> > version?

>> >> No, PDF::API3 was a fork that got created roughly around the same time I >> took over maintenance of PDF::API2, after the previous maintainer stopped >> supporting it. We both had the same goal, but the other developer ended up >> moving on to other projects before making any changes. >> >> -- Steve >>

> > > > -- > *James L. Harper* | *Software Engineer IV (Supervisor)* | *RR > Donnelley* > 630 W 1000 N | Logan, UT 84321 | Voice: 435-755-4455 <(435)%20755-4455> > | Cell: 435-770-3289 <(435)%20770-3289> | Fax: 435-753-7002 > <(435)%20753-7002> > Email: james.harper@rrd.com > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > Any unauthorized review, use, disclosure or distribution is prohibited. If > you are not the intended recipient, please contact the sender by reply > e-mail and destroy all copies of the original message. > >

-- *James L. Harper* | *Software Engineer IV (Supervisor)* | *RR Donnelley* 630 W 1000 N | Logan, UT 84321 | Voice: 435-755-4455 | Cell: 435-770-3289 | Fax: 435-753-7002 Email: james.harper@rrd.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Sun Jul 02 18:08:10 2017 steve [...] deefs.net - Correspondence added

On Wed Feb 08 19:49:35 2017, james.harper@rrd.com wrote: Show quoted text

> I ask because I know the 2of5int barcode seems to work better in the > API3 version.

That's interesting. PDF::API3 is equivalent to PDF::API2 version 0.73 (released eight years ago), so if you're not seeing the problem there, it means it got broken after that, and should be reproducible. If you can provide a test case, I should be able to track it down. Otherwise, I suggest starting at version 2.020 to see when the problem got introduced. Version 2.022 is probably the most likely candidate, since it included changes to 2of5 barcodes.

Sun Jul 02 18:08:16 2017 steve [...] deefs.net - Status changed from 'open' to 'stalled'

Sat Jun 02 17:59:34 2018 steve [...] deefs.net - Correspondence added

I'm still interested in looking into this if you can provide a test case, but am going to resolve it for now as not reproducible.

Sat Jun 02 17:59:35 2018 The RT System itself - Status changed from 'stalled' to 'open'

Sat Jun 02 17:59:35 2018 steve [...] deefs.net - Status changed from 'open' to 'resolved'

Sat Jun 02 20:51:55 2018 james.harper [...] rrd.com - Correspondence added

Subject:	Re: [rt.cpan.org #119962] Found a bug when creating a new XObject Form
Date:	Sat, 2 Jun 2018 18:28:30 -0600
To:	bug-PDF-API2 [...] rt.cpan.org
From:	James Harper <james.harper [...] rrd.com>

Thank you. On Mon, Jan 30, 2017, 9:02 PM Steve Simms via RT <bug-PDF-API2@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=119962 > > > On Thu Jan 26 10:19:00 2017, james.harper@rrd.com wrote:

> > I did see that code and I was confused as to how it could be anything > > other > > then a 1 also. But I have seen FormType 500 and FormType 1000 > > On some XObjects. It is intermittent 99+ percent of them are just > > fine. I > > could not see anything about those objects that would break it.

> > Ok, here are a couple of things to try: > > 1) I just released PDF::API2 version 2.031. It has some fixes that could > potentially impact this bug. > > 2) Is the problem reproducible on a given PDF? In other words, on the 1% > or so that fail, do they keep failing if you re-run the script? > > Given that you're seeing the numbers 500 and 1000 show up, I'm going to > guess that the problem *is* reproducible on a given file, and that the > affected PDFs have object streams in them, based on a bug I tracked down > and fixed for a previous release. That's still relatively new code (added > in 2.026), so there are probably still some edge cases that aren't working, > which would explain why you're only seeing the problem occasionally. > > If you can reproduce the problem on a given PDF that you can send to me > privately for the sole purpose of troubleshooting this bug, I should be > able to get a fix released. > > -- Steve > > PS: In regard to your other note, yes, the PDFNum wrapper function does > need to be called so that the serializer knows what kind of value to write > to the file (e.g. a literal number vs. a name, boolean, string, etc.) >