Hi, sscotti. I'd like to help here, but I think you have already found the unfortunate answer: inconsistent browser support for a non-standard plug-in. Couple of ideas that may be useful...
1. Try it in Opera. If it works there, you might want to recommend that browser to your clients for this particular form. Opera is very rigid about standards-compliant processing. If it doesn't work there, you might want to look for another design for this application. Not because Opera is so popular (it's not) but because any dependency on non-standard interfaces puts you at risk for future failure. We call this a "brittle" design pattern, and it is to be avoided.
2. Forget about Safari. Apple and Adobe seem to be having a spat over the use of Flash on the iPhone. Apple is having none of it (a position I completely understand given the fact that Flash content has to be served from the internet, and internet data requires about 1,000x the battery power of data already stored in the phone). Since Flash sites will deplete the batteries on iPhones, Apple does not want that, and Adobe is upset about it. Net-net: Don't build your app in a way that requires two other companies to cooperate on advanced non-standardized browser plug-in features.
3. A possible solution might be to use a plain old HTML form to collect the data you need. Submit that form to an action script to accomplish the validation. Once validated, the action script can use FPDF to write the PDF file, and can present the finished PDF to the client. Almost any browser can display a PDF correctly. It may not sound sexy, but it lets you use JavaScript (if you like that sort of thing) as a client-side data inspector, and it doesn't depend on any arcane technologies. The FPDF class is very flexible, fast and easily extensible.
HTH, ~Ray
