Jan, welcome to the Forum.
First some basics 'just in case' we overlook the obvious.
The trap for the footer template is, presumably, something that appears, or at least concludes, after the trap for the detail template?
The Template is set to be a footer template?
The resulting text output from the PDF conversion looks OK with no odd things of note?
Can you be a little bit more specific about the "Floating Footer trap to the Detail trap". For example is this a 'floating trap' in the horizontal floating sense of the tick box in the template definition? Or is it a 'vertically floating' means of getting the field which is preceded by the text string "TOTAL FOR" at some point past the currently defined trap location?
I fear it might be to easy to make wrong assumptions about what you need to do here, hence the questions.
Thank you for the welcome and for the response, Grant. To answer your questions:
1.The trap for the footer template appears at the end of a section of detail lines. Each detail section will contain at least one line, but in most instances, there are multiple lines of details. (See sample below)
2.The template is set to be a footer template.
3.All data in the table window is exactly what would be expected for all fields except the footer.
4.Because the data in PDFs when opened in Monarch can “float” across the page, this is a ‘floating trap’ in the horizontal floating sense.
The result I'm getting is that where I would expect to see "End Office" in the table view, I'm getting "Carrier Common Line". And where I would expect "Local Transport", I'm seeing "End Office".
We have come across the same issue in another PDF from a different source and with different data.
Thanks for your assistance.
From Apr 21 07 thru Apr 24 07 133 .0434 5.77
From Apr 25 07 thru May 20 07 865 .04758 41.16
TOTAL FOR Carrier Common Line: 47.45
Intercept Originating Minutes (per 100 mou) 67 .0085 0.01
Intercept Terminating Minutes (per 100 mou) 998 .0085 0.08
Local Switching LS-1 Originating Minutes
From Apr 21 07 thru Apr 24 07 8 .009 0.07
From Apr 25 07 thru May 20 07 59 .00984 0.58
Local Switching LS-1 Terminating Minutes
From Apr 21 07 thru Apr 24 07 133 .009 1.20
From Apr 25 07 thru May 20 07 865 .00984 8.51
TOTAL FOR End Office: 10.45
Local Transport - Originating MOU
From Apr 21 07 thru Apr 24 07 8 .0117 0.09
From Apr 25 07 thru May 20 07 59 .01281 0.76
TOTAL FOR Local Transport: 0.85 /font[/quote]
We are currently on 8.01. We work extensively with PDFs and have been doing so with this format for awhile now. As we have used footers in PDFs before, this appears to be a relatively recent problem and we are wondering if it might be in the way that Monarch is translating these particular PDF files.
It sounds like you plenty of experience with PDFs and Monarch in general so, since this does seem odd and you have likely looked at all the usual tings and a few others besides I doubt any more random suggestions would help.
2 ideas though.
Firstly I have on very rare occasions (about twice so far in 10 years) seen instances of model files which have become 'corrupt' in some way yet still work to a large extent. Such events are not unknown in any piece of software. You could just try recreating the model from scratch, if you have ot already done so, just to see if it makes a difference.
Secondly I would be happy to take a look at a sample pdf file with your model to see if a pair of fresh eyes can spot anything odd. Sometimes it can help.
If that option is open to you (presumably dependent on the data content and privacy issues) let me know via a PM and I will provide an email address to which the file can be sent.
I have seen at least one model become corrupt during its creation. It's a question of glitches writing back to disk either when still in 'memory' or during a save.
In theory the pdf conversion is simply creating a text file and Monarch is doing its usual thing with the text file.
So you could try doing the pdf conversion in Monarch and then selecting every line as a single field and exporting the results to a new text file. Then run Monarch against that new file.
You could also use the Acrobat reader text conversion for the same purpose and see what it makes of the pdf and then what Monarch makes of Acrobat Reader's results.
If you have Adobe Acrobat you could try editing the pdf and 're-writing' it - it may be different afterwards. Likewise any other pdf editor/writer combination you may have to write a new version and see what changes.
If none of that changes anything I note your profile indicates using 8.01. Is that still the case? If so it would be interesting to know if anything changes with 8.02 installed.
Sorry for the delay in responding. We tried a rewrite of the newer model and it produced the same issue. As for the text conversion, we receive hundreds of these pdfs each month from several sources and manage them through an automated process. Having to bypass the automation to manually convert each file to text prior to processing would be counter productive from a resource aspect.
We are migrating to 9.0 when Data Pump is ready. I am hopeful that this issue will be resolved then.
Thanks for all your assistance.
As for the text conversion, we receive hundreds of these pdfs each month from several sources and manage them through an automated process. Having to bypass the automation to manually convert each file to text prior to processing would be counter productive from a resource aspect.
/b[/quote]I agree entirely but it would be interesting to try a few sample files manually to see if there is any difference as a way to try to identify the cause.
The potential for PDF variability (compared to application produced 'greenbar' reports) from the input stage all the way through to what you eventually receive (which could be a process with changes along the way) is certainly a challenge to keep people busy for the foreseeable future.
Hopefully V9 will help you move forward.