FMDiff™   

This site is W3C compliant:
Valid XHTML - Valid CSS
Last modified February 24 2016, 21:20:46 CET.

Problems with printing from a FileMaker file

FileMaker Pro 7 and up: Old Filename in Print Dialog
FileMaker Pro 6, partially 7 and up: Platform Related Issues | Behind Print Settings | Print on Windows

Old Filename in Print Dialog and other problems

This new phenomena applies to the Macintosh platform since FileMaker® Pro 7. It had happened that a FileMaker solution was sold to different customers and some files were bearing the customer name. The files were properly renamed for the next customer, but when previewing or saving as PDF or looking at the printer queue while printing, the name of their competition showed up - not a good recommendation, is it?

So why is that old name showing up?

Whenever a new file is created the printer definition for the currently selected printer (some 5 to 13kb, depending on printer and platform) is saved within that file - and lives there forever... well, at least for now. Within that printer definition on a Macintosh the original file name is stored, like

...
<key>com.apple.print.JobInfo.PMJobName</key>
<dict>
	<key>com.apple.print.ticket.creator</key>
	<string>com.apple.printingmanager</string>
	<key>com.apple.print.ticket.itemArray</key>
	<array>
		<dict>
			<key>com.apple.print.JobInfo.PMJobName</key>
			<string>OriginalFileName</string>
			<key>com.apple.print.ticket.client</key>
			<string>com.apple.printingmanager</string>
			<key>com.apple.print.ticket.modDate</key>
			<date>2003-10-01T20:54:26Z</date>
			<key>com.apple.print.ticket.stateFlag</key>
			<integer>0</integer>
		</dict>
	</array>
</dict>
...

So whenever FileMaker performs a Print command it uses these settings stored within the file and shows the original file name!

Only FileMaker Inc. knows why that stuff is within the file. If needed for a job it just could be generated at any time (will be proved later). This and related problems are only partially improved with FileMaker Pro 10 as the printer definition is no longer stored within the file but still within the Print and Print Setup script steps. So redefining the Print Setup and Print script steps in FileMaker Pro 10 will remove the old printer information, including the original file name.

How to get rid of that original file name?

You should not fiddle on the file with an editor, this destroys the file. Not even a HexEditor is recommended, since it is dangerous and you would have to use a name of the same or a lesser length, filled with blanks or zeros up to the original size.

The best thing would be to remove these definitions all together. But how?

There is an easy way to do just that: Move the file to the Windows platform and perform a Print (to any driver - don't waste any paper). This will remove the Macintosh settings and replace them with the Windows ones. Then move the files back to the Mac and the next print will restore the settings for the currently selected default printer with the correct file name. There is no reason to keep those settings in the file! Quod erat demonstrandum (which was to be demonstrated).

That same procedure may also cure problems after installing a new printer

For obviously the same reason there could be problems when changing the printer. The old settings won't fit for the new one. So in case moving between platforms does not help (possibly with scripted prints) you will have to redefine the print scripts on the new platform with the new driver selected as default. Here it comes handy if you have just a few separate scripts for printing which you call as SubScripts. There is only one place to go!

Note: For scripted prints, after returning the file to the Macintosh platform, the script steps Page Format and Print have to be redefined, since the same information is stored within the script step. Here it really pays to have a subscript for printing - instead of print commands all over the place - since there is only one place to modify.

 

 

Platform related issues - valid mostly for FileMaker 6 and below

A FileMaker file prints fine on one platform, but not on the other.

Keep in mind there are three platforms and the FileMaker internal settings that have to work together to make printing possible:

• Mac OS 9 (for FileMaker up to version 6)
• Mac OS X
• Windows (all flavors)
• FileMaker specific platform and printer independent settings

While the first three derive their information from the system and the printer driver, the last item is a collection of data used internally, like page margins, single or browsed records to print, and page orientation. It thus becomes obvious that the internal and system and printer specific settings have to be synchronized.

So moving a file from one platform to another, or changing the printer type from Ink-jet to PostScript will end in a mess if the relevant information is missing.

What is behind the Print Settings? - valid for FileMaker 6 and up

Whenever a FileMaker file is created (or recovered) it inherits the platform specific printer settings of the currently selected printer. These settings are in turn used as defaults when defining scripts with Print Setup or Print commands. These settings are then stored with the appropriate script. That means a script originally created on a Macintosh under OS 9 knows nothing about printing under OS X or under Windows - and vice versa.

If a file is moved from one Platform to another it has to learn about the new platform's print settings. This is usually not a problem as long as you issue the Print Setup and Print commands manually. By doing so, the FileMaker file learns about the new platform and stores that information permanently and additionally to the already existing other platform settings.

The problem lays with the Scripts

Scripts store Print Setup and Print settings independently from the file's settings. In fact they store settings for multiple platforms - if available. If a file prints well manually, that does not at all mean that printing with scripts would work as well. The only solution to the problem is to teach the scripts about the new platform.

Understanding what exactly happens helps to do it right.

With FileMaker 6 and earlier, when a script with a Print Setup or Print command was created (or changed with the option to save the current settings), it stored the setting that were most recently used with that file, i. e. actually done, not just pretended. It is important to do both, the Print Setup and a Print to get the settings right, even if your script only uses a Print command.

FileMaker 7 and up provide the settings definition with the script step. But this only works if you display a dialog. Otherwise you need to include a Print Setup step prior to the Print step to have these settings used.

An elegant workaround - and a future design suggestion

Create yourself a FileMaker file called PrintSettings.fp7. No fields, just one record, one Layout (maybe with a description about what the file is good for), and a number of scripts as follows (see A4 example):

Print Letter portrait current record

Print Letter portrait records being browsed

Print Letter landscape current record

Print Letter landscape records being browsed

Print Legal portrait current record

Print Legal portrait records being browsed

Print Legal landscape current record

Print Legal landscape records being browsed

Print A4 portrait current record

Print A4 portrait records being browsed
Print Setup [ Orientation: Portrait; Paper size: 8,26" x 11,69" ] 
	[ Restore; No dialog ]
Print [ Current record; All Pages; Orientation: Portrait; Paper size: 8,26" x 11,69" ] 
	[ Restore; No dialog ]

Print A4 landscape current record

Print A4 landscape records being browsed

where each script just contains a Print Setup and a Print command.

This is valid for FileMaker Pro 6:

Make all the definitions on one platform, then move the file to the other and repeat the same definitions again. This should be done with the same script - no branching for platform needed. The settings for each platform are accumulated within the same script. I recommend to actually do the Print manually with the desired settings before (re-)defining the concerned script. This not only makes sure that it really works, but also offers the right settings as default for the script definition.

This is valid for FileMaker Pro 7 and up:

FileMaker 7 and up store the Print Setup and Print Command just once. This may cause malfunctions when changing platforms when using some printers.
 

When the scripts are properly defined - you just have to do this once in your life - import these scripts into any other file that needs printing. The Page and Print settings are carried with the scripts. In your new file you have to go through all scripts that use a Print Setup or a Print command and replace these commands with a call to the appropriate imported subscript.

This way there is only one place in your file where you have to fiddle with those settings, whenever a change should become necessary. This is especially useful if you convert legacy .fp5 solutions. Remember that FMChecker™ shows the Page and Print settings of those scripts in .fp3 and .fp5 files so you know what that script should do. The only other way to find out is to run the script and see what is printed - hopefully with a printer that still works with the old files.

Tip: Let your customer provide the correct settings

You may send your customer such a file and have her/him store the settings with the script and send you back the file where you can add the definitions to a solution.

Note: the following described method only works up to FileMaker Pro 9. FileMaker Pro 10 does not store the print settings in the file generally, just in scripts.

If this is asked too much, simply have him do the Print command manually with the desired settings (select right printer, make the Print Setup, Print the current record). When you get the file back, and without trying anything related to printing, create a script named accordingly and include one step Print. This should (so the theory) store the Print setting last used with the file into the script. Then you may add other platform settings to the same script by repeating the Print command manually and open and close the Print script step. (Obviously you can only get ONE print definition that way, namely the last used with the file.)

Printer related issues on Windows - valid for FileMaker 6 and below

Changing the Windows default printer is completely ignored by FileMaker.

After connecting a different printer there may be problems.

The source of all evil is the Windows Registry which is set by the FileMaker installer. Note: this is not related to solution files but to the installation of FileMaker Pro - and every version keeps its own settings.

When the FileMaker Pro software is installed it stores the currently selected default printer and stores its name under - for example FileMaker Pro 6.0v4 - and henceforth uses exactly this printer as its default. If you change the Windows default printer later, FileMaker does not care about that fact, it still uses the old printer.

The problem escalates if you connect a new printer and FileMaker still uses the old printer driver that may not support all the new possibilities, or even worse, is not compatible with it.

How to get rid of the old printer?

(Not yet tested, just theory) Select the new Windows default printer and re-install FileMaker. This may not be a very elegant solution, but should work. Not viable if you have to change printers frequently.

A Windows savvy user might use RegEdit and remove the default printer from the FileMaker settings in the Registry.

Use a printer plug-in which does the job for you.

Use a VB-Script that replaces the FileMaker default printer with the current Windows default printer. In FileMaker Pro 8 you can create the VB-Script text on the fly and execute it.

(Sorry for being rather vague here, since this is not my preferred platform. I will elaborate on that and come up with an example file when time allows.)

Don't forget to redefine your Page and Print scripts

It may be necessary (you find out immediately if it doesn't work) to re-define the scripts as described above. If you've followed my suggestion and have only a few scripts that do the printing, this is done very quickly.

Suggestions, opinions, experience reports and other hints are welcome via our Contacts page.