SMLastError is empty when error has occurred

[disco stu]

I'm doing some simple PDF page counting and concatenation using Matt Petrowsky's ScriptMaster/iText demo file. This worked pretty much flawlessly, until recently. Depending on the particular source PDF files, my page count and PDF merge functions are now failing, but SMLastError is empty, so I don't have anything to go on in troubleshooting. Is this a ScriptMaster bug? I've checked the source PDF's (not generated by me) and it doesn't look like there's any file protection that would be interfering. Even if that were the case, shouldn't a descriptive error be generated? I'm just not sure how to proceed.

Thanks in advance for any ideas!

-Stu

[john renfrew]

Stu

I can't remember Matt's code off by heart as I am now using my own with a later version of the library, but if the script does not specifically return an error for the use case then you will be getting the 'correct' result outputted to you even for an 'incorrect' function. So, for example, if one of the PDF's has a password which you fail to provide you can end up creating a 0kb 'new' pdf file but not throw an error related to that event, because the script thinks it has created the new file. Unless an 'ERROR' message is specifically thrown or a Java error has occurred then this might be correct behaviour.

Bit difficult to tell without sight of the PDF files which are causing the failure.

[bcooney]

John,

That's exactly what happened to me using Matt's catpdf. Watch out for locked PDFs! I wish there was a way to detect them.

[disco stu]

Thanks for your replies. The functions are both returning "ERROR" for certain PDF's, with SMLastError coming back empty. There doesn't appear to be anything different about these particular PDF's...no password or other protection. I can open them in Acrobat and combine them manually without any problem. Here's another strange phenomenon: I have the PDF's stored in a documents table in FileMaker. They are getting uploaded to FM primarily by a Windows user. I'm on a Mac, and if I manually export them to my machine, then re-upload them to FM, the errors no longer occur. However, doing this on Windows has no effect. So the process of saving them locally on the Mac (or uploading them from a Mac?) seems to be changing something about the PDF files.

-Stu

[john renfrew]

I am cross-platform bi-lingual here, never experienced anything like that.

Have you tried creating a file which JUST has the uploading and concat parts to test it is not aFM issue??

Are you able to add the original files using Acrobat before they are uploaded? Are you able to share any files that are causing the issue??

BC - put the new PdfReader bit inside a try {} catch(e) { if ( e.toString().contains('BadPassword')) { return 'PASSWORD ERROR'} }

[bcooney]

We've encountered problems with PDFs that rely on a specific font (often foreign characters) that is not installed on the workstation. Also, PDFs with graphic "letterheads."

[disco stu]

John,

Thanks for the suggestions. I haven't tried building a test db with just the affected features, but I've debugged the FM-specific pieces extensively and I don't believe there is anything on the FM side that would be causing the SM functions to fail. The two functions (page count and concatenate) just seem to be inexplicably failing for certain PDF's. I obtained a set of "problem" PDF's from the user, and am able to combine them manually in Acrobat before uploading to FM. The FM script works by exporting all the documents to the temp folder, then concatenating one by one using the SM functions (it inserts blank pages after documents with an odd number of pages, which is where the page counting comes in). If I interrupt the FM script after the files have been exported, I can manually combine those exported copies of the documents in Acrobat as well. Acrobat indicates that the source files are completely unprotected. I also tried adding the bad password code you suggested and am not getting a password error returned. If you're interested/willing to take a look at some of the problem PDF's, I'd be grateful! (I would need to provide them offline due to their content.)

Bcooney- Were you able to resolve the issues you ran into with those kinds of files? I don't think I'm dealing with any PDF's containing foreign characters, but definitely graphic content.

Thanks,

Stu

[bcooney]

@john, thanks.

@Stu, no, we actually scan the docs with the offending letterhead graphics/fonts and re-upload.