I'm struggling with a compound PDF that keeps crashing our agents for some inputs. It results in a crash-dump in a directory EDATEMP/ts that, among other files, contains the parts that make up the compound PDF.

I've tried opening these partial PDF files (ibit001.pdf, ibit002.pdf, etc), but none of my PDF readers can read them.

I looked at the parts with a text editor, but most of the PDF content is binary.

It seems impossible to find what might be going wrong here. Is there a trick to making these files readable, so that I can diagnose what's causing the problem?

I've already tried not adding all components to the compound PDF, but all of the separate parts - still as compound PDF's - cause no issues. Nothing jumps out, not even the usual crash-causes like columns wrapping past the page margin, etc.

I intend to open a case, but creating a reproduction of the problem is not easy in this case. The code is _very_ dynamic.

This message has been edited. Last edited by: FP Mod Chuck,

Hi A,

sounds very familiar...

My first guess was the column wrapping, but you've covered that.

Some ( other ) stuff you can try:
[ in case you haven't tried it ]

Set all fonts to size : 4
Just to check for page overflows.

Start with only the first PDF.
no compound.

Then the first and the second.
etc.etc.

Also we found : Runnning a compound from dev.studio or MRE doesn't care about warnings.
Running the same from the schedules doesn't work.

Do you partials contain images? ( for including in header or footer ). Do they have unique names? If not, that sometimes causes problems.

Good luck.

Did you try Foxit reader?

If compression is not turned on, just open in a text editor, and look for column titles, headings etc to see which reports are there

Wep

Since the agent crashed those pdf files are corrupted and that is why you can't open them. Best to open a case with techsupport and determine why the agent is crashing.

Backup Plan:

Start commenting out code till it works, then you will know the offending command.

@Frans: I tried Foxit, SumatraPDF and I think even Adobe Acroread. None of them consider those partial PDF's valid.

@Chuck: The thing is, I'm pretty sure that the partial that causes the agent to crash is the only one that could potentially cause issues for readers. My conclusion is that the format of the partial PDF's is an internal IBI format that needs some processing to become proper PDF. I was hoping anyone knew how.

@Waz: I hadn't realised compression is on. I'll give that a try tomorrow, that should at least result in better readable partials... I'm hoping to glean something useful from those.

The problem is; The compound PDF generates okay for most input selections. This is a document that lists specifications for components in our products and for most components it works fine - great even.
There are a few that don't however, and the most likely cause is a problem fitting the layout on the page. In that case, the problem is caused by the combination of data and report layout - rather hard to put a finger on!

I think I had a case open for a very similar occurrence of this problem and the solution was to upgrade to 8202... *chuckles maniacally*

Looking at the partial PDF's in more detail, it turns out that the last one in the set is a 0 Bytes file. That's obviously where the agent crashed. Now to determine which section that might be... Being able to read the preceding section's partial PDF would help a lot!

Looking at the uncompressed partials, it appears there are some placeholder tags in the file that WF fills in when combining them.

In the partial, I see:

%PDF-1.4
#OBJ# 0 obj
<<
/Length #LENOBJ# 0 R
>>
stream
(...binary data...)endstream
endobj
#OBJ# 0 obj
#STREAMLEN#
endobj
#END-OF-PAGE#

While in a successfully created PDF (from the same report), I see:

%PDF-1.4
6 0 obj
<<
/Length 7 0 R
>>
stream
(...binary data...)endstream
endobj
7 0 obj
2398
endobj
8 0 obj
<<
/Length 9 0 R
>>
stream
...etc

From the looks of it, #OBJ# is a simple incrementing object identifier number.
The meaning of #LENOBJ is a bit mysterious, but it seems to contain a number 1 higher than the #OBJ# number.
#END-OF-PAGE# looks like a no-op instruction.
The tricky bit will be calculating the #STREAMLEN#, but it appears to be just the number of bytes in the stream section (including 1 for the first newline).

Unfortunately, the successful PDF document contains a bunch of stuff at the end for which it is not so obvious how to reproduce that... Looks like I'll have to dive into PDF internals a bit - or perhaps FORMAT PS will give some insights.

EDIT: Alas, Document Composer Syntax does not support FORMAT PS, it seems. I do get output, but the PAGELAYOUT does not get applied - no paper orientation, no master page, no page numbers, each table on a separate page, etc. Ah well, at least it doesn't crash!

This message has been edited. Last edited by: Wep5622,

I would suggest going to the Backup Plan...

quote:

Backup Plan:

Start commenting out code till it works, then you will know the offending command.

I recall, that normally, there's an seemingly blank IE page that opens prior to the PDF being displayed, or not being displayed. If that is still the case here, I'd view source on the blank IE page to find any "(FOC#####" errors which may lead to the source of the issue. Of course that requires sett ECHO to ALL.

I hope this helps, Doug