I had missed this Community post regarding a demo file of a PDF viewer in a WebViewer, but I stumbled upon it today while reading this other one.
Regarding the demo-file post, and the sample file for viewing PDFs which it discusses:
While I did not write the terrific blog post on this topic, I am the one who worked out the initial technique, and wrapped it into the Proof-of-Concept file that became the original version of the demo file shared in the blog. It's really cool to see that it's been shared with the world -- certainly that's what I would have wished for, but didn't realize that wish had come true. While a bit late to the party, I'd like to offer a few comments/observations which I hope will clarify, and increase the possibility that people will be able to take advantage of this file, and that they may do so with fewer obstacles/frustrations, and greater success.
Some starter background:
2) The library worked great, and came with a very nicely featured reader app, straight out of the box, which I simply plunked into a WebViewer without any effort at all.
3) The "secret sauce", in this case, was getting around browser security errors that would occur if one tried to point the viewer app/library to a PDF file that lives on the local file system.
Regarding the exporting the various files that comprise this technique:
1) The PDF viewer library is not a single file, but rather it is a collection of files within a specific directory structure.
2) In order to easily reproduce this structure of files in the temp directory, I chose to create a .zip archive of the top-level folder, and first start by exporting that zip file to the temp directory.
3) At this point, the next step is to unzip the exported archive, so that it will reproduce the entire structure of files. I had the option of doing this by using the option to "Automatically Open" a file when exporting using the Export Field Contents script step. I really liked this option, because it required nothing external -- no plug-ins, no AppleScript, no bash scripts, etc.. -- It just worked. The problem, however, was that opening the .zip archive in this way was a bit slow, and it also resulted in a gratuitous Finder window opening.
4) Not liking the downsides of using the "Automatically Open" option, I decided that I would use AppleScript and a bash script to extract the zip archive, and just include some notes about this only working for MacOS. This worked fine, though I still somewhat lamented not having something that would be more portable. To reiterate what some have observed, no plug-in, (SmartPill or otherwise) was used to unzip the archive -- it was AppleScript plus a bash command.
Here's where I think that things get a little interesting from the context of v.17 of FMPA:
1) Prior to v.17, we could export contents to allowed locations where the target directory already existed, but we could not export contents to a directory that did not yet exist. This is really the crux of the matter for why I needed some sort of "trick" (in my case, choosing to use a .zip archive) to create a rich directory structure of files from an export.
2) Now that we have, in v.17, with the ability to create folders as we export contents, this obstacle has been removed. I am really pleased with FMI for slipping in this particular feature -- for reasons just such as this task at hand. In essence, we are now able to create the rich file structure of the PDF reading library in the temp directory without having to go outside of FileMaker scripting even in the least. Certainly more effort is involved, but the resulting code will be more portable, and presumably more understandable to a wider audience.
3) With this in mind, it should be possible to rewrite the sample file to not require any of the following: Plug-in, AppleScript, bash command, etc.. I understand from jrenfrew's comment that, even so, the code will not properly run in a Windows Environment (sincere thanks to you, John -- I appreciate knowing this, and wouldn't have known without your help). As such, portability may not seem so important at this point, but, in anticipation of the day where WebViewers on both MacOS and Windows function at a high and contemporary level, it still really delights me that the FileMaker scripting could already be at a point where it is relatively (if not completely) platform-agnostic. That sits well with me.
Regarding the integration errors that I've seen mentioned in this Community thread:
1) Certainly it's possible that there is some bug in my code causing these -- I'd never rule that out.
2) From what I see, however, the error messages are citing snippets of calculation as though they are literal text intended to be a file name. As such, I am inclined to think that in the first case, a missing custom function wound up being commented out, and then later on interpreted as literal text instead of a function reference. In other words, I agree with the diagnosis of the missing custom functions being the culprit, and I would caution making sure that, upon adding the missing custom functions to the solution, that one be careful to make sure that all previous references to said custom functions have been corrected, and are no longer commented out.
3) This leaves the other error message, regarding $_fmp_path_for_viewer_template_export, and hbrendel has already given some great advice there, though I would add that my earlier advice still applies here, too, i.e. make sure that there is not still some residual broken custom function reference which needs to be addressed. Simply adding the missing custom functions is not apt to be a sufficient fix -- revisiting sections of any script which references the missing functions is also likely to be required.
Regarding the custom functions used in the sample file:
1) Both of these are functions that I wrote simply because I knew that I would repeatedly need these functions in other development work.
2) In neither case is it essential that the custom functions be used -- the calculations that they provide could justifiably be included at the script level, without too much redundancy. And, in fact, if one were to re-write things to leverage the v.17 folder creation, I might possibly advocate doing away with these functions, just to keep the integration steps fewer.
If anyone still has any interest with trying to integrate this into a solution (presumably MacOS), feel free to reach out with questions, and I'll do my best to help out. It's not super-complex stuff -- mostly just making sure that content is exported as and where expected.
Many thanks to Beezwax for sharing the file, and also taking the material to the next level in terms of optimization, etc.. @Christopher_Edwards, if you see this, many thanks to you for writing such a great post and expanding upon everything as you did with your signature excellence.