“It is a riddle wrapped in a mystery inside an enigma but perhaps there is a key. The key is how you get the PDF into the container field, and which platform and FM version you use to accomplish this.”
Winston Churchill, BBC radio address, 1939
(Just kidding about the second sentence.)
If you work with digital images, you’ve probably noticed the trend towards using PDFs as an image file format. I doubt many of use could have foreseen this happening when the PDF format was introduced in 1993, but in many organizations PDF has become the standard file format for images.
The good news is that the GetThumbnail function now works with PDFs in container fields in FileMaker 14, and in this article I’m going to suggest a couple reasons why you might find this useful, and explore some nuances between how PDFs in container fields behave on the Mac vs. on the PC.
Today’s demo file, pdf thumbnails, is a 45Mb download, consisting of 32 PDF images (average size 160K, average dimensions 1160×880) as well as six stored PNG thumbnails of varying dimensions for each PDF.
Preliminary Details
Before we go any further, let’s introduce a couple of terms:
- Passive thumbnail = the image that FileMaker automatically displays in a container field (under specific circumstances) to represent the binary data stored therein
- Active thumbnail = an image with maximum dimensions specified that the developer proactively generates via the GetThumbnail function
We’ll have more to say about both types of thumbnails below, but the crux of the matter is that GetThumbnail requires a passive thumbnail to create an active one. Without the former to use as a source, GetThumbnail cannot generate the latter.
Also note that in this demo all container fields have been optimized for image display, like so.
Seeing Is Believing
Feel free to open the demo in FileMaker 12, 13 or 14, and on either the Macintosh or the Windows platform. The thumbnails have already been created so it doesn’t matter which version/platform you use (unless you want to edit container data — more on this below).
I promised a moment ago to offer two reasons why you might care about this; here’s the first reason…
- Start with the demo file closed (we don’t want caching to skew the results).
- Open the demo.
- Click the Active Thumbnails button, and note that a new window opens and displays almost instantaneously.
- Return to the main demo window, click Passive Thumbnails, and note that this window takes longer to display — a tiny bit longer if you’re working locally, but noticeably longer if you’re accessing the file via LAN or WAN.
So reason #1 is speed. And depending on your hosting setup, connection speed, thumbnail size and number of records in your found set, the difference between the two approaches can be dramatic.
Update 4 June 2015: as Daniel Wood tactfully points out in his comment at the end of the article, my speed argument is only valid because I neglected to permanently store thumbnails via Manage Containers in the demo. So it turns out there’s no reason to manually generate active thumbnails if your only goal is to boost performance. On the other hand, if you’re already generating active thumbnails (for reason #2 below) then you might want to stick with temporary storage in Manage Containers to avoid redundantly storing image data.
To see the second reason…
- Click the Active Thumbnails button, and then click “Save As PDF” in the tool bar at the top of the window, and name the file “active thumbnails.pdf”.
- Next go back to the main window of the demo, click Passive Thumbnails, do a “Save As PDF” and this time name the file “passive thumbnails.pdf”
- Now compare the file sizes.
On my computer the former is 574 KB and the latter is 8.5 MB, a whopping 1400% difference.
More About The Demo
As you have probably surmised, the difference in performance and output file size is determined by whether we render the original container (i.e., a passive thumbnail scaled down to 100×100), or the correspondingly sized active thumbnail.
The two layouts are identical except for the choice of field.
The storage table consists of these fields…
…with PDFs stored in the “container” field. And all the “thumb” fields are defined to use this auto-enter calc:
Note that the syntax is identical for all six “thumb” fields, and that the number at the end of the field name determines the dimensions. Of course I could have instead simply defined the AE calc for each “thumb” field individually, e.g.,
GetThumbnail ( container ; 300 ; 300 )
GetThumbnail ( container ; 200 ; 200 )
GetThumbnail ( container ; 100 ; 100 )
etc.
Why Not Use Unstored Calcs?
Why not use unstored calculation fields instead of auto-enter calcs populating standard container fields? If your primary concern is output document file size that would be fine. But if you are displaying thumbnails on-screen, and especially if you are displaying a lot of them at once in a hosted environment, your screens will render faster using the method in this demo. Also, if you use unstored calcs, the “thumb” fields will not render in FM 13.
So What Changed in FM 14?
The GetThumbnail function did not work with PDFs in container fields in FM 13, but it does in FM 14. Actually it worked in 12, was deprecated in 13 and reinstated in 14.
Does GetThumbnail work with PDFs on both Mac and PC?
Short answer: yes, as long as you have a valid passive thumbnail to use as a starting point (except, as I just mentioned, it does not work in FM 13).
Longer and more helpful answer: to the best of my knowledge it is not possible to generate the prerequisite passive thumbnail on the Windows platform so from a practical standpoint, you are much more likely use GetThumbnail to generate PDF thumbnails on the Macintosh than on the PC.
However, if you use a Macintosh to initially create passive PDF thumbnails, then there’s nothing stopping you from using GetThumbnail on a PC to generate the active equivalents (again, provided you are in FM 12 or FM 14).
For example, having previously populated this demo via the Macintosh, I’ve now opened it in FM 14 for Windows, created a new record, and begun the process of dragging and dropping from the container in the above row to the container in the new record.
Now I’ve released the mouse button and committed the record, and not only has the PDF been copied into the new record (along with its passive thumbnail), but the GetThumbnail function has performed its magic as well.
How Do You Generate A Passive Thumbnail?
In FM 12 or FM 14 for Macintosh, insert the PDFs into the “container” field via…
- Insert picture
- Import folder (that’s how I got the 32 PDFs into the demo)
- Drag and drop into the container
- Copy and paste the file into the container
- Insert PDF (this option is only available if your container is optimized for interactive content, i.e…)
Note that Insert File is specifically excluded from the above set of choices. All that gets you is an icon like the one shown in the next section, except in FM 14 for Macintosh if you script the operation, you can choose “Display: Content of file (when possible)” and it actually will work on the Mac (but not on Windows).
What Happens When You Try On A PC?
On the PC in FM 14, using any of the above methods, you end up with the icon for the file, rather than the passive thumbnail.
If you then open the file on the Mac in FM 14, at first it appears the operation was a success…
…but note that GetThumbnail has not worked (all the thumbnails are the same size—in fact, rather than images, the thumb fields contain identical copies of the source PDF). And while the image in the container field certainly looks like a passive thumbnail, it does not behave like one… e.g., you cannot copy and paste (or drag and drop) it into the container field in a new record and end up with valid active thumbnails.
What Happens When GetThumbnail Doesn’t Work?
In the above example we’re primarily talking about the inability to generate a valid passive thumbnail on the Windows platform. But what happens if we insert a PDF into the container field on a Mac in FileMaker 13?
The passive thumbnail has been created but the active thumbnails have not. If we then open the file in FileMaker 14 we see the same thing (because the botched thumbnails are stored)…
…but if in FM 14 we duplicate the record, or cut/paste the container back onto itself, then the active thumbnails will properly generate.
Incidentally, if you’re wondering about the image — it’s my cat Rascal doing yoga. We call this pose “purrfection”. (Isn’t he adorable? Eighteen pounds of furry feline splendor.)
Closing Thoughts
I would love to be wrong about my contention that it is not possible to generate a passive PDF thumbnail in FileMaker for Windows, but so far my attempts at tricking FileMaker into doing so have been unsuccessful, including various experiments with the Base64Encode and Base64Decode functions. If you know of or discover a way to do this on the Windows platform, I’d appreciate you letting me know.
Kevin
I am aware of your desire to do this all natively and at the moment its not possible, but this is easily accomplished on Windows with a plug-in and bit of lateral thinking just did this for a client who wanted to turn the first (up to) 20 pages of an inserted PDF into separate single image files
Let me know if you want more details…
Yes please.
Hi Kevin
Very useful indeed.
How would you capture (via script to field or $var) the filepath (where thumbnail is stored) for each repetition
rl
In the demo the thumbnails are not stored externally, so there is no filepath.
Hi Kevin
But if they were, how would you do it?
Set Variable [ $filePath ; GetValue ( pdfstorage::container ; 2 ) ]Actually that would return the full file *spec* (including file name).
P.S. You’re welcome.
Hi Kevin, great article again! We’ve had similar issues with saving PDF’s but rather than thumbnails of a PDF, saving just a typical layout that has for example a scaled down 3mb image on it – the PDF is huge compared with when we generate a thumbnail for that image and save that on the PDF, I guess it’s storing the full size image with the PDF.
Anyways, in looking at your article I noted that your file has temporary thumbnail storage turned on instead of permanent, is this a conscious decision to illustrate the point? under File -> Manage -> Containers – > Thumbnails, if you set this to Permanent, allow them to cache, and then close/reopen the file, the main screen and the passive popup open just as fast as the active layout, so this is the same as storing “active” thumbnails without the need for the fields of various sizes.
Thanks Daniel — I was unaware of the temporary vs. permanent setting in Manage Containers, and will amend the article accordingly.
To be clear — the different thumbnail sizes are in the demo as a proof of concept. As you noticed, I only actually used thumb_100.
P.S. Rascal sends his warm regards.
Kevin,
These tests appear to be with PDFs with raster data. Have you experimented with PDFs with vector data? A couple of things we have found…
The image will look nice and sharp with a local file on the Mac, but if you host that same file on a Windows FMS, you will see a horribly low resolution version of the graphic. FileMaker knows about this issue.
The other thing is that GetThumbnail in an auto-enter or calculated field will make a rasterized .png thumbnail for some files, but for others it will make a duplicate of the vector .pdf file. We haven’t found what the difference is in the files.
Our plan was to store the original graphic as a .pdf and have FileMaker generate a raster file and use that to get around the display issue when hosted on Windows FMS. But with these files, we are just getting a duplicate vector PDF. If you happen to know what is controlling this behavior, I’d love to hear it. If you are interested, I can send you some test files privately.
Thanks for all of the great articles!
-Shawn
Hi Shawn,
Thanks for taking the time to comment. I don’t have anything intelligent to add re: raster vs. vector. With regards to the issue where you get copies of your PDF in the thumbnail fields, in my experience that’s what happens on the Windows platform unfortunately.
Regards,
Kevin
But even having the file open locally on a Mac, I get different results, depending on the PDF file. It’s really strange.
Is this in FM 13 by chance? What if you try in 12 or 14 — same issue?