Printing PDF (external or container field) MacOS

[elipsett]

I'm running FMP 17 Adv on Catalina.

I have a folder containing the FileMaker file and a large number of PDFs. 
A script determines if there is a PDF for a particular client, and either sends an email with the PDF attached to that client, or prints out the email body and the PDF.
The PDF has a known filename, and can be input as an external file or via a container. The filename is available as a $$ variable; the path is the same as the Filemaker file itself.
The email part works fine.

The problem is in printing. The script prints out the body of the email perfectly, but I cannot get it to automatically print out the PDF.
I have Acrobat and Acrobat Reader both installed, although Preview should work as well since they are all PDFs.

Can anyone give me simple code to print $$Filename located at (same path as Filemaker file, or $$FilePath), specifically for a PDF file?

Suggestions welcome, but keep in mind that I am not very skilled at Filemaker, and know nothing about AppleScript.

 

Thanks for your time. 

[comment]

How many pages can such PDF have?

 

[elipsett]

Only a  single PDF, but with an indeterminate number of pages.
I don't need to open or even see it in FileMaker, only send it to the printer.

[comment]

AFAIK, the only way to send it to the printer is through AppleScript. 

This could be probably as simple as:

tell application "Preview"
   print file "filepath"
end tell

or even:

tell application "Finder"
   print file "filepath"
end tell

The difficult part is generating the file path for the given PDF dynamically based on the location of the Filemaker file. It would be much easier if you could you just hard-code the path to the folder. Anyway, I believe performing a calculated AppleScript like:

Let ( [
// PATH TO FM FILE
fm_path = Get ( FilePath ) ;
// REMOVE FM FILENAME AND "file:/" PREFIX 
pos = Position ( fm_path ; "/" ; Length ( fm_path ) ; - 1 ) ;
dir = Middle ( fm_path ; 7 ; pos - 6 ) ; 
// APPLESCRIPT PATH TO PDF
filepath = Substitute ( dir & $$fileName ; "/" ; ":" ) ;
// APPLESCRIPT
template = "
tell application \"Preview\" ¶
print file \"«filepath»\" ¶
end tell"
] ;
Substitute ( template ; "«filepath»" ; filepath )
)

should work for you. I cannot test it because I no longer have a printer, but it works for me if I try it with "open file" instead of "print file".

Edited April 14, 2020 by comment

[elipsett]

Thank you; let me play with this tomorrow. 

The name of the folder will not change; its location possibly could.
I like your text operations to get the current filepath!

I'll let you know what happens.

Thanks!

 

Actually, while it is possible that the path might change in the future, I would certainly KNOW when it changed, and could update the path easily enough. 
In which case, all I have to do is be sure to specify the path as a text string, correct? (in MacOS format, not FileMaker format)

 

[comment]

1 minute ago, elipsett said:

The name of the folder will not change; its location possibly could.

Consider placing the folder in a fixed location inside the Documents folder. Both Filemaker and AppleScript know how to get to the Documents folder - so all these complicated manipulations could be avoided.

 

[elipsett]

I might be able to figure that out after digging through Mac and FMP documentation, but if you've got it on the tip of your finger...
I would certainly save me a lot of time, and probably save you fro having to answer more questions about it tomorrow when I can't get it work.

I'd appreciate the assist if you can spare the time.

[comment]

Are you asking about accessing the Documents folder? It's: 

Get ( DocumentsPath )

in Filemaker, and: 

path to documents folder

in AppleScript.

 

[elipsett]

Sorry, as I expected, I can't get it to work... I simply don't understand enough about AppleScript (or MacOS itself) and how to use it from FMP.

I have a variable named $$AttachmentPath which correctly ends with the name of the folder and a final slash, and another variable named $$AttachedDocument. My code currently reads:

Sorry, I use the Japanese system...
this sets a variable named $$File2Print to identify the document type (PDF), and then sends the event to Preview.

When I run it, MacOS displays an error message saying
document "tell application "Preview" print file "filename" end tell
could not be opened to print.

In the Event settings, the called application is set to preview, event type is Other, Even class aevt, event id pdoc.

 

Edited April 15, 2020 by elipsett

[comment]

It looks like you're trying to use Send Event script step. You should be using the Perform AppleScript step instead.

It also looks like you're trying to use (Incorrectly) the GetContainerAttribute() function. Is the file you want to print inserted into a container field?

If you open a file created under an English system, do you see the script steps in Japanese?

 

[elipsett]

OK...
So first set variable $$File2Print to the complete path and filename, ending in ...PDF.
Then perform Applescript.

How can I pass $$File2Print to Applescript?

The actual script code is unchanged. Various app-generated words (like "Create Variable" above) are in Japanese; the actual code works fine on any system. This applies to AppleScript and FMP both. 
 

The file is in the same folder as the FMP file. 
My current program ALSO shows it in a container; this AppleScript can use whichever is simplest.

[elipsett]

I tried putting the following into the "calculated AppleScript" box:

"set xpath to " & Quote ( $$File2Print ) & ¶ & "tell application \"Preview\"¶" &    "print file xpath¶" & "end tell"
 
First it said that Preview wasn't active, so I launched Preview manually and tried again.
Then it said that it could not locate the specified file, citing the path/filename as beginning with

/MacintoshHD/ blahblah Documents/Finale/K1063.pdf

...which appears to be correct.  

Edited April 15, 2020 by elipsett

[comment]

8 minutes ago, elipsett said:

So first set variable $$File2Print to the complete path and filename, ending in ...PDF.
Then perform Applescript.

Uhm, no. 

The first step - actually the only step - is to figure out what is the OS path to the file you're trying to print. The OS path is not the same as Filemaker path. A Filemaker path can be converted to an OS path. The question here is where to begin.

If you have the file inserted (as reference only) into a container field, then it would be easier to begin there. In such case you only need to convert the path stored in the container (which is a Filemaker path) to an OS path and use it in your AppleScript. In such case it's also irrelevant that the PDF is in the same folder as the FMP file, since the container field stores (also) the absolute path to the PDF file.

Please confirm the above and I will try to help you with the code implementing this route. Although I must say this again: it would be much easier if you put all your PDFs in a known folder inside your Documents folder. Then all you need to know about the specific PDF you want to print is its filename. And BTW, if you know the filename, you can also use a calculated container to display the file from the known folder.

 

19 minutes ago, elipsett said:

How can I pass $$File2Print to Applescript?

There is no need to pass the variable, or even for the variable itself. You need to perform a calculated AppleScript, so all calculations can take place within this step. 

 

[elipsett]

The FMP file and all PDFs are now in a folder named Finale, which is located inside the Documents folder. 
I put them there this morning and have been experimenting with that setup all day. 

All the PDFs are present in that folder, and also referenced in a container.

Edited April 15, 2020 by elipsett

[comment]

OK, so just one more thing: is there a way to determine the PDF file's name from the data in the current record, other than getting it from the container field? For example, if you have a method for naming the PDFs using the client's name/s.

 

Edited April 15, 2020 by comment

[elipsett]

Yes.
There is a text item named IdNo.SendTo, containing a sequence of numerals and sometimes a decimal point.
There is a separate address list identifier which can be either K or I.

The file name is always (K or I) & IdNo.SendTo & ".pdf"

 

IdNo.SendTo is text because the ID number 123.1 and the ID number 123.10 both exist; if this was a numeric field it wouldn't work.

This  is the code I currently use, and it works:

Case ( Finale::ListSelect="K"; "K" & Finale::IdNo.SendTo & ".pdf"; Finale::ListSelect="I"; "I" & Finale::IdNo.SendTo & ".pdf"; Oops AttachedDocument.path" )

This is used to define what gets loaded into the container, too.  (It know it loads properly, because if I select the file inside the container and then export, the correct file is output. Unfortunately, it does not display in the container; it only shows the PDF icon and filename. I don't need it to display, though, only be emailed or printed...)

Edited April 15, 2020 by elipsett

[comment]

3 minutes ago, elipsett said:

There is a separate address list identifier which can be either K or I.

The file name is always (K or I) & IdNo.SendTo & ".pdf"

Then I believe you can make your calculated AppleScript =

Let ( [
filename = YourTable::address_list_identifier & YourTable::IdNo.SendTo & ".pdf" ;
template = "
tell application \"Finder\" ¶
set myFile to file \"«filename»\" of folder \"Finale\" of (path to documents folder) ¶
end tell ¶
tell application \"Preview\" ¶
activate ¶
open myFile ¶
end tell"
] ;
Substitute ( template ; "«filename»" ; filename )
)

You need to replace YourTable::address_list_identifier and  YourTable::IdNo.SendTo with your own table and field names.  

Currently this only opens the selected file in Preview. Once you have it working, change "open myFile" to "print myFile". As I mentioned earlier, it's possible that you can move the print command to the tell application "Finder" block and get rid of the tell application "Preview" block. I am afraid I have no way of testing that.

 

[elipsett]

Since the name of the file already has a variable assigned to it, I just used that. For this test, it does indeed hold the correct name of the PDF. 

Let ( [ filename = $$Attachment ; template = " tell application \"Finder\" ¶ set myFile to file \"«filename»\" of folder \"Finale\" of (path to documents folder) ¶ end tell ¶ tell application \"Preview\" ¶ activate ¶ open myFile ¶ end tell" ] ; Substitute ( template ; "«filename»" ; filename ) )

It opens the PDF in Acrobat Pro DC, which is my default PDF app.
Next is printing...
 

And it prints!
Vunderbar!

It opens the file in Acrobat, and opened the Print dialog.
When I press print, it does indeed print it out correctly.

So the basic script is working, but I need to tweak a few printer-related things. 
(1) I want it to print automatically. It would be nicest if I could use FMP to set the printer up (paper size, color, etc), but not essential.
(2) It currently prints the file at fill-the-page size, instead of 100%. It's possible this can be set in (1) above.  

Can I use the FMP printer setup command prior to AppleScript, or does printer setup have to go through AppleScript, too? (Just tried -- nope, the FMP command won't work...)

========
Apparently printer settings are pretty difficult to set from AppleScript. Or impossible.
Is there any way to have it print out automatically, and ignore item (2)?

Edited April 15, 2020 by elipsett

[comment]

10 minutes ago, elipsett said:

It opens the PDF in Acrobat Pro DC, which is my default PDF app.

Well, I think a command addressed to the Preview application should result in the file being opened in Preview. That's probably an Adobe shtick. 

The rest needs to be solved by making the AppleScript tell Acrobat to do those things. I am afraid I can't help you with that because I don't use Acrobat.

--
A side note: do not use global (prefixed with $$) variables unless you need them to persist after the script has run out. 

 

[elipsett]

Yeah, it looked to me like this was leaving the realm of FMP, too. 

I owe you a beer next time you're in town (or the poison of your choice).

Seriously, thank you very much for all your assistance. 
Even in a best-case scenario this would have taken me weeks to pin down, and worst-case (likely) would be never.
I appreciate all the time and trouble you spent.