Jump to content

Creating PDFs


cbntor

This topic is 6828 days old. Please don't post here. Open a new topic instead.

Recommended Posts

You need to have the Full Adobe Acrobat Software, or one of the Shareware utilities with the ability to print to PDF.

If you have this now, you will first need to do a manual print to PDF, once you have it the way you want, then create a script that uses the Script Step of Print. After that, attach your script to a Button in the Layout Mode.

HTH

Lee

cool.gif

Link to comment
Share on other sites

  • 3 months later...

If one is using OSX (10.3) and FMP7, is there a way to script the automatic creation of PDF's from FMP7? That is, can one completely automate the process of:

1. Choosing "Print..." from the File menu;

2. Selecting the "Save as PDF..." button;

3. Naming the PDF file with the desired file name; and

4. Navigating to the desired folder (or after saving, moving the file to the desired folder);

so that one can click on a button in FMP7 (or otherwise invoke a script) and have a PDF automatically created for the currently displayed record(s) using the current layout in the location and with the filename specified in the FMP7 database?

I've found a way to do it with a combination of QuicKeys 3 and FMP7-generated AppleScripts, but not using purely FMP7-generated AppleScripts (which is my preference). I currently use QuicKeys 3 for steps 1-3. If you know of a way to make FMP7, via AppleScripts only, automatically perform steps 1-3, please advise. Thanks!

Link to comment
Share on other sites

Thanks Fenton. You are correct, and your posts did help me find a way to accomplish my goal.

Despite Fenton's laudable and much-appreciated help, for one who has not scripted much in the past few years (but man did I have fun in '87 when Apple introduced HyperTalk -- since renamed AppleScript), I did find developing the desired AppleScripts to be incredibly difficult and frustrating. Thus, I deeply hope Apple gives its overly neglected step-child some much needed TLC in the very near future (perhaps a la Tiger's Automator?), so that it again becomes the programming language "for the rest of us".

In any event, so that my pain and loss of precious time is not repeated by everyone with a similar FMP7 objective, here are a few minor clarifications/tips for those like myself who are somewhat scripting-challenged:

1. In FMP7, to automatically save the current set of records using the current layout as a PDF file:

a. Create an FMP7 ScriptMaker script containing the "Print" step.

b. For that script step, place a check mark in the check box for "Specify Print Options".

c. Click on the "Save as PDF..." button.

d. For the local drive, navigate to the "Desktop" folder. If the script will be used on multi-user FMP7 databases, instead navigate to the "Users" folder and then to the "Shared" folder.

e. Click the "Save" button.

f. Click the "OK" button to save the script.

g. Go to the Desktop (or Users:Shared) folder and locate the saved PDF file. It will likely have a name of either the name of the database or "Edit Script" followed by ".pdf".

h. Make note the name of that file and delete it. Note: for this first invocation of the script, that particular PDF file might not be openable by Preview or Acrobat.

2. If you want to automatically rename the PDF file, you can do so via an AppleScript.

a. A very simple version of the "Rename this file" script can read:

tell application "Finder"

set name of file "Your Disk:Users:Roxanne:Desktop:foo.pdf" to "test.pdf"

end tell

b. To generate a similar AppleScript from FMP7, using a dynamically-generated origin path, origin filename, and destination filename (specified in FMP7), you can create the following calculated AppleScript in FMP7's ScriptMaker:

"tell application " & Quote("Finder") &

Link to comment
Share on other sites

Good explanation. I'm afraid I don't usually have the patience to explain it in that detail. I've answered this question several times, in various forms, so I tend to explain briefly, post an example file, and hope they can figure it out. Though I must admit, it took me a while, through trial, error and suggestions of others (BruceR) to get it working.

I'd like to point out that there are two different ways to do the actual writing of AppleScripts for FileMaker. Haynes has mixed the two styles in his explanation. There are pros and cons to each way.

The first is when you create a FileMaker calculation to contain the AppleScript. His example:

"tell application " & Quote("Finder") &

Link to comment
Share on other sites

Great insights, Fenton. Thank you. I plan to implement them in my current FMP7 project.

To summarize, one can generate AppleScript from FMP7 aimed at, e.g., the Finder, via either "calculated" AppleScripts or via "native" AppleScripts. For static values (e.g., origin filename, origin path, destination path, etc.) and simple scripts, either way will probably work well. For more complex scripts that use FMP7 fields for variables, I much prefer Fenton's approach of "setting" each of the FMP7 fields to AppleScript variables using "native" AppleScript rather than "calculated" AppleScript, which is indeed a pain to write.

Also, I particularly appreciate the "path to 'sdat' as string" suggestion. Very helpful. Thanks again.

Link to comment
Share on other sites

> If the script will be used on multi-user FMP7 databases, instead navigate to

> the "Users" folder and then to the "Shared" folder.... But the shared folder

> is likely (but not guaranteed) to be:

> "Macintosh HD:Users:Shared:"

> So that's your best hope, as you must hard-code this into the FileMaker.

Fenton, for multi-user FMP7 databases, there appears to be a slight variation on your suggested approach, as well as a more significant variation, that in some situations might work better.

For the slight variation, after navigating to the [localdrivename]:Users:Shared folder when creating the script, change any AppleScripts to refer only to "Users:Shared" and not mention the local drive's name. This seems to be helpful when not all local drives of the users have the same name, i.e., "Macintosh HD".

For the more significant variation, if a shared volume (e.g., an AppleShare volume) is accessible and/or mounted by each of the users of the multi-user ("shared") database, FMP7 can consistently save the PDF file for each user to a location on that shared volume, so long as the path (including the volume name) to that location does not change. I am not certain, but this might be helpful in a mixed (OSX + other OS's) environment.

Thus, step 1 of my suggested procedure above should be revised to read:

1. In FMP7, to automatically save the current set of records using the current layout as a PDF file:

a. Create an FMP7 ScriptMaker script containing the "Print" step.

b. For that script step, place a check mark in the check box for "Specify Print Options".

c. Click on the "Save as PDF..." button.

d. For a single-user database, navigate to the "Desktop" folder of the local drive.

e For multi-user databases, instead navigate to either:

1) if a shared volume is available, a commonly-accessible, fixed-named location on that shared volume;

2) if a shared volume is unavailable, a commonly- and fixed-named location on each user's drive, assuming each drive has the same name;

3) if a shared volume is unavailable and there is variation in the names of the users' drives, to a location that is commonly- and and fixed-named (other than the drive name), such as [localdrivename]:Users:Shared folder. (Note: modify the remaining AppleScript instructions of this procedure to refer only to "Users:Shared" and not mention the local drive's name.)

e. Click the "Save" button.

f. Click the "OK" button to save the script.

g. Go to the selected location and find the saved PDF file. It will likely have a name of either the name of the database or "Edit Script" followed by ".pdf".

h. Make note the name of that file and delete it. Note: for this first invocation of the script, that particular PDF file might not be openable by Preview or Acrobat.

I look forward to any questions, corrections, or alternative approaches. Thanks.

Link to comment
Share on other sites

Well, I agree that if there is a fixed location on another mounted volume, then you could use that as well.

The problem with users having different hard drive names is not really an AppleScript problem, it's a FileMaker problem. It's FileMaker that needs a fixed path to export or print to pdf.

For AppleScript, path to "sdat" as string will return the "hard drive name:Users:Shared:" folder.

But that doesn't do you any good if FileMaker hasn't saved the file to that location; and it won't if the drive names are different (at least I don't think it will), because the FileMaker script has a fixed file reference in its Print to pdf script; which you cannot modify on the fly.

There is another alternative, which BruceR has posted.

http://www.fmforums.com/threads/showflat...true#Post116760

Which is to use the "PDF Services". This is a folder which may or may not exist in the user's Library folder. If it does, you can put AppleScripts in there, with an "on open" handler. They can be targetted by the Print dialog, and the script will run.

This is the crucial post. The rest of the thread is mostly about me having a problem, so it's not much use :-|

Link to comment
Share on other sites

This questions comes up from time to time.

Do a search of "All Forums" using the Keywords as shown and a blank in the weeks:

+print +PDF +Windows

Be sure to use the plus with the words. I did this just now and got 88 hits.

HTH

Lee cool.gif

Link to comment
Share on other sites

  • 2 weeks later...
  • 7 months later...
  • 3 weeks later...

This topic is 6828 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.