Skip Menu |
 

This queue is for tickets about the PDF-API2 CPAN distribution.

Report information
The Basics
Id: 119962
Status: resolved
Priority: 0/
Queue: PDF-API2

People
Owner: Nobody in particular
Requestors: james.harper [...] rrd.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



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>
Download (untitled) / with headers
text/plain 853b
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.
Download (untitled) / with headers
text/plain 662b
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);
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>
Download (untitled) / with headers
text/plain 2.1k
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.
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>
Download (untitled) / with headers
text/plain 1.5k
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.
Download (untitled) / with headers
text/plain 1.4k
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.)
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>
Download (untitled) / with headers
text/plain 2.3k
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.
Download (untitled) / with headers
text/plain 535b
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
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>
Download (untitled) / with headers
text/plain 1.3k
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.
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>
Download (untitled) / with headers
text/plain 2.3k
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.
Download (untitled) / with headers
text/plain 604b
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.
Download (untitled) / with headers
text/plain 129b
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.
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>
Download (untitled) / with headers
text/plain 1.6k
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.) >


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.