[Phil]

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

<formatting cleanup - Mod.>

[Phil]

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

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.

--
*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

<formatting cleanup - Mod.>

[Phil]

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?

--
*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

<formatting cleanup - Mod.>

[Phil]

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

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.)

[Phil]

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?

--
*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

#
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

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.

--
*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

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

<formatting cleanup - Mod.>

[Phil]

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.

--
*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

<formatting cleanup - Mod.>

[Phil]

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:

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'

[Phil]

 PhilterPaper commented Dec 29

James (or anyone else working on this) -- this PDF was not created from scratch from PDF::API2 (or Builder), but involved reading in and combining existing PDFs? The original PDFs are OK? What if you leave out the bar code -- does the problem go away? If not, I would suspect that something is corrupting the PDFs being read in. If it does go away, I will have to look in the bar code routines to see if either they're corrupting something, or data that they've created is being corrupted at some point. It really would be nice to have a consistently reproducible test case, if you can scare one up with some fake data.

The bar code "working better" on PDF::API3 needs more specific information on what's wrong with the current version. Is it a performance issue, or are PDF::API2 (and PDF::Builder?) actually putting out bad PDFs? It's even possible that this is somehow related to the XObject Form problem.

[Phil]

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.

Date: | Sat, 2 Jun 2018 18:28:30 -0600
From: | James Harper <james.harper [...] rrd.com>

Thank you.

[Phil]

Since nothing has arisen in 7 months, I think it's safe to assume that either the problem was fixed in PDF::API2 2.031 (quite a while ago now), or the input PDF(s) were > version 1.4, and that was causing problems. Since there's no way to reproduce it, I am going to reject this ticket for the time being. If someone can come up with a consistently reproducible way of seeing this bug, I'll reopen it.