1 Reply Latest reply on Jul 23, 2012 11:05 PM by steve_ssh

    FM 11 on Mac OS X: Scripting FM-command "Save as PDF" - workaround


      Hi everybody,


      I got in trouble when trying to save a record as PDF out of a script: The currency-sign for "Euro" € (generated by FileMaker itself while "currency" was checked as an attribute for the corresponding field in the relevant layout) was lost: Only a blank square appeared on its place. Generating a PDF using the "Save as PDF"-Option of the Mac OS X-printing dialog works fine. The used font is a TrueType-font – a got lost, because I only found workarounds for problems using OpenType- or PostScript-fonts. The workarounds for those problems were: Use TrueType-fonts, instead :-/


      Finally, I found a way to use the OS-side PDF-generating routine for my script using AppleScript and its shell-command "do shell script". Perhaps, this might be helpful for someone else:


      First, I store the path for the target location in a global field called "var_filepathPDF" of a table called "init". The path starts and ends with a slash and spaces must not been escaped. The target might be a shared folder, for instance:


      var_filepathPDF = "/Volumes/<name of share>/<folder level 1>/<folder level 2>/<target folder>/"


      The first step in the script is to generate an individual filename for the final PDF:


      Set Variable [ $filenamePDF; Value:<calculate an individual filename using field contents, time & date etc.> & ".pdf" ]


      Now using the "Print" command with "No dialog" for let Mac OS X SAVE – and NOT print – the print-job to a PDF-file with a temporary filename "FM_PDF_tmp.pdf" in a suitable temporary location (I use "/Users/Shared/") - write a comment into your script, for there won't be any hint, what's really going on here - this script step looks like a normal printing command - though it's a saving command, in fact:


      Print [ Current record; All Pages; Orientation: Portrait; Paper size: 8,26" x 11,69" ] [ Restore: <name of printing queue>; No dialog ]


      Now FileMaker invokes AppleScript which then invokes a shell command with parameters calculated by FileMaker and converted by AppleScript. This step moves (not copies) the temporary file to the target location AND gives it its final naming. Important: Don't miss a double quote or backslash:


      Perform AppleScript [ Calculated AppleScript: "do shell script "mv /Users/Shared/FM_PDF_tmp.pdf " & quoted form of "" & init::var_filepathPDF & $filenamePDF & """ ]

      That's it.


      Regards from Hamburg


        • 1. Re: FM 11 on Mac OS X: Scripting FM-command "Save as PDF" - workaround

          Hello Olaf,


          Thank you very much for taking the time to share the details of your workaround.


          Some years ago, I was using the same technique within a FMP version 7 solution, i.e. 'printing'  a PDF to a fixed file name, and then renaming the file via the shell.  I hope you don't mind if I toss an extra thought in your direction regarding this approach.


          Very kind regards,







          I became concerned that printing to the same file path and then renaming was too vulnerable with respect to data integrity.  I wanted to take into account a possible scenario whereby an old version of the "FM_PDF_tmp.pdf" file remained, and my script did not detect the error.  Presumably one could always perform enough start-up checks and error trapping to catch this sort of scenario, but it still nagged at me too much, since the consequence of an uncaught failure could mean that I'd be emailing a report with the data for person A to person B -- it would be a tremendous privacy issue.


          What I did:


          I added a new field to the print layout which I updated to contain a unique string which I could associate with a particular person's report.  I set the text color of this field to match the background color of the report (white on white).  Ostensibly, the field was not visible on the PDF printout, yet it still existed within the PDF file's data.


          I then utilized a free PDF reading library to scan "FM_PDF_tmp.pdf" to look for the expected unique string.  If it found the expected string, I could rest assured that I was about to rename/relocate the proper file.  If the expected string could not be found within the PDF content, I branched the script into an error mode, where it saved the suspect file elsewhere, and logged an error.


          In my case I used a Java library for reading the PDF, as that was the easiest route for me to take:  I wrote a small class that could be invoked from the command line with arguments of the target file path, and the desired search string.  The code would output a result/status code to standard out, and then exit.  This was something I could call via the "do shell script" AppleScript command which you are already using.


          Adding this extra step really gave me the peace of mind that I needed.  I realize that you may have already tightened down your scripting to catch all possible failures, and therefore this may seem like an unnecessary measure  -- nonetheless, I think it's worth mentioning.




          Once we were out of version 7, this workaround was one of the first things to be pulled out of the solution.





          If one were to go down the path I mention:  scan the "FM_PDF_tmp.pdf" file with a PDF reading library, it might be worth asking the question of whether or not the PDF library could be used to fix the original issue, i.e. the mal-rendered Euro character that happens when using the Save Records As PDF script step.  Perhaps someone else can chime in about that possibility.