PDFs failing in old Adobe Reader versions

[abackstrom]

We create PDF invoices to send to customers after an order has been placed. Recently, customers have been calling back saying that they are unable to open the files. I am able to open them on Adobe Reader 7 on my machine, but I have tried Adobe Reader 6, Acrobat Reader 4, and ghostview, all of which claim the file cannot be open. Ghostview error reads as such:

   **** Warning:  An error occurred while reading an XREF table.
   **** The file has been damaged.  This may have been caused
   **** by a problem while converting or transfering the file.
   **** Ghostscript will attempt to recover the data.

I'm just starting to look into this now, putting out this thread as a first step. Has anyone else experienced this problem? Has the PDF creation feature changed recently?

We are using Alpha Five V6 (Build 2057) in house.

[abackstrom]

Quick bump for this thread. I've made no progress with this on my end, still hoping for some outside suggestions.

I'll do some additional tests shortly: verify that other report PDFs show up in older versions of the Reader, delete fields until the PDF displays, etc.

[Lenny Forziati]

I use acrobat reader 5 and it has no problem opening PDFs I am generating from A5v6.

The PDF creation functionality was not changed in v6.

Quick bump for this thread. I've made no progress with this on my end, still hoping for some outside suggestions.

I'll do some additional tests shortly: verify that other report PDFs show up in older versions of the Reader, delete fields until the PDF displays, etc.

[CALocklin]

One of my customers is experiencing the same or similar problem. He has found that the PDF works every time on their internal system but when the same e-mail is also sent to an address outside of his system - like to his personal e-mail address at home - the PDF is sometimes unreadable. E-mails sent to his house seem to have the same incidence of error as his customers are seeing.

This is not a problem that seems to be customer specific. The problem is sporadic and occurs with most customers. (Can't say "all" for sure but it's at least a lot of them.)

They are reporting about a 10% error rate.

No, we haven't found a solution yet. I'm planning to see if we can get the functionality we need by using a full version of Adobe.

[abackstrom]

Solved, sort of

We're finding that PDFs created via the normal "view" button work fine on all machines. When using this button, there are no problems.

Pressing the "E-mail as PDF" button will automatically attach the PDF to a new Outlook Express message in our environment. Saving this attached file to the workstation yields an identical file to the first case.

E-mailing this file out will produce a corrupt PDF. Viewing the two PDFs side by side in a hex editor shows that two bytes have been deleted near the beginning of the file. I haven't yet done the full gamut of testing, but for now we're having our people save the PDFs and attach them to e-mails manually. I believe that's turned out to be a suitable workaround.

[CALocklin]

Interesting. Is it always the same bytes? I guess that should be, "Do the missing bytes always have the same value? If so, we could probably find a way to test for them and replace them if necessary.

[abackstrom]

Interesting. Is it always the same bytes? I guess that should be, "Do the missing bytes always have the same value? If so, we could probably find a way to test for them and replace them if necessary.

Yes, it does seem to be the same bytes. The header, before e-mailing:

0000000: 2550 4446 2d31 2e33 0[b]d0[/b]a 25ff ffff ff0[b]d[/b]  %PDF-1.3..%.....
0000010: [b]0[/b]a36 2030 206f 626a 0d3c 3c20 2f4c 656e  .6 0 obj.<< /Len
0000020: 6774 6820 3720 3020 5220 2f46 696c 7465  gth 7 0 R /Filte

After sending:

0000000: 2550 4446 2d31 2e33 0a25 ffff ffff 0a36  %PDF-1.3.%.....6
0000010: 2030 206f 626a 0d3c 3c20 2f4c 656e 6774   0 obj.<< /Lengt
0000020: 6820 3720 3020 5220 2f46 696c 7465 7220  h 7 0 R /Filter

0xd0 (bolded) has been stripped from two places in the file.

This is consistent, I've verified it with two seperate reports. This problem only shows up after the PDF is mailed. The more I explore this, the less it looks like an Alpha problem. I think it's either Outlook Express or our mail server at this point. We're upgrading to A5V7 this evening. I'll see if that changes anything.

[abackstrom]

We had some progress on this yesterday. I believe we have fixed the problem, but it will take time before we know for sure.

Microsoft Outlook Express is flawed (in my opinion) in the way it selects an encoding for message attachments. PDF files are binary data, but Outlook Express does not always treat it as such. While this knowledge base article is not 100% applicable to our situation, it does show that OE will happily encode some PDFs as quoted-printable instead of base64. This produces a corrupt file in our experience.

This is a known issue documented on the Amyuni forums. PDFs created by the Amyuni PDF creator are generally small files: our customer invoice reports were in the neighborhood of 12K. OE parses the short file and incorrectly interprets the data as text, causing corruption as the attachment is delivered.

The solution is to embed fonts into the PDF, thereby making the file more binary-heavy and forcing base64 encoding in OE. At this time we've erred on the side of caution and gone for heavy font embedding, bloating a 12K PDF to over 800K. It's a lot more data to push around, but it's better than customers being unable to read our quotes and invoices.

So, this problem was outside Alpha Five in the end.

[CALocklin]

So, how do you embed fonts when building a pdf of an Alpha report?

[abackstrom]

So, how do you embed fonts when building a pdf of an Alpha report?

Fair enough. =)

The embed options are buried in the system-wide "PDF Driver" virtual printer.



"Printing Preferences..." will get you to the Amyuni options.



Enable "Font embedding" on the "Advanced options" tab. Click "Embedding Options" for more granularity in the embedding.



"Embed standart fonts" will give you some pretty hefty PDFs.

[abackstrom]

Just for fun, here's a snippet of the truncated file from the e-mail source:

------=_NextPart_000_0005_01C6315E.59C494A0
Content-Type: application/pdf;
        name="OrderAck2002B6.pdf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
        filename="OrderAck2002B6.pdf"

%PDF-1.3=0A=
%=FF=FF=FF=FF=0A=
6 0 obj=0D<< /Length 7 0 R /Filter /FlateDecode >>=0Dstream=0Dx^=A5X=DDV=DB=

The trunated bytes were just before the first two linefeeds.