Richard Rönnbäck

I have worked in the print publishing business, where this is one of the most asked questions, for 20 years. So to spare you some time here is what is boils down to: 1) There is no real solution 2) If you design for accurate size when printing you use traditional measurement units such as inches, centimetres etc. 3) If you design for accurate AMOUNT OF INFORMATION when viewed on screen you can use points, which are the closet equivalent to pixels. You then target a certain amount of pixels/point, for example 1024x768 The problem with screens is that there is no way of knowing what physical size the end user's screen is or what resolution (pixel density) they are using. Web designers deal with this problem all the time, and their "solution" is usually to design for a certain resolution and let the user deal with the fact that it will display smaller or bigger than on some other computers screend. What they do know however is that the same amount of information will be displayed

You must have internet sharing turned on, as all PHP connections goes through the http/https protocol(s), which is the same as all internet traffic is using. That does however not mean that your system is available to everyone on the internet. Presumably your mini-server is behind your firewall on a private sub-net (it should be), which means that only members of the sub-net can access, not outsiders.

What about the ODBC driver from Actual Technologies. Would that be a possibility? http://www.actualtechnologies.com/product_access.php

This might be relevant http://support.microsoft.com/kb/278061/en-us

Together with two other developers I have spent a good deal of the last two years building a system with a similar purpose and functionality and here are some of my thoughts First of all, get FileMaker Server Advanced. Sharing through FM Pro is a nice feature for the smallest workgroup, but it really is limited for doing what you are after. Secondly, in order for IWP users to access the images through the filesystem you do need them to mount a share, similar, or identical to how your inhouse users are doing it. You do not say if IWP users are inside or outside of your firewall. You will probably have trouble convincing the IT department that it is a good idea to open up filesharing to external users. If that is not an option you will have to serve the images in some other way, either by embedding them in a database, or, by using some other means. In our case we are using PHP and web viewer controls. Third, with FM Server Advanced you can tie your FM databases to an Active directory / Open directory server through LDAP, which will bring true authentication. You should probably also study FileMakers security model, and custom access rights etc. If all you need is to share the database with a few inhouse co-workers, then keep it simple and adjust your expectations to what can reasonably be achieved

In Windows you can print to a "Microsoft Office Document Image Writer" which will give you plain ol tif file. I wonder if that is what they mean? I know that it was not uncommon for software developers to rely on that capability, a decade or so ago

Could you post a sample Word document?

You would definitely see a substantial improvment. I doubt however that the problems will just go away. What you are describing seems to be a database design problem - it is simply not designed with performance in mind. There could however also be other issues, such as corrupt databases etc, a system running out of diskspace etc. The only way you will know is to study the users carefully and see exactly what causes the slowness.

It certainly seems to be the unstored calcs that cause the problems then. Try to do an export of only the fields that are stored and see if the speed is normal then, and then add in the other fields until you find the culprits. Would it be possible to replace any of the calculations with Auto Enter data?

Assuming it's not a corrupt file the only thing I can think of is if you have a lot of unstored calculation fields. Depending on the complexity of the calculations that certainly adds a lot to the export time

No matter which set of tools you choose you will face limitations. But you should be very careful not to throw out the baby with the bath water. No doubt that SQL-driven platforms offer benefits, but I doubt they are important enough to change platform. The reason your boss prefer FM is probably not only because he is familiar with it, but because it has proven to be a valuable business tool to the company. What I would think your boss is concerned about is that assuming you go SQL/Java and then decide to quit, or for any other reason becomes unavailable, they would be left in a very nasty situation. I can not count the number of customers I have been called in to try to figure out someone else's howe-brewed mess (which may be immensly clever, but still almost inpenetrable to an outsider) Worse still is that such a solution is likely to be very hard for your company to integrate their existing FileMaker solutions into. So, I guess what I am saying is that before you decide you should systematically evaluate the options. In today's world, with FileMaker's / FileMaker server Advanced's possibilities to interact with SQL-DB it's not really an either-or situation, you can continue to use FileMaker, but go SQL if you have to

Are they using Safari? IWP does not, for some bizarre reason, support displaying PDF's in Safari. Have you looked it from a Windows client using IE (with the Adobe reader installed)

Perhaps you could place a web viewer object on the layout, that calls a php script on the server, and then parse the code from the web viewer? the php code to display the visitors IP address is [color:brown]<?php echo $_SERVER['REMOTE_ADDR']; ?>

Sure, what you should do is to use the open URL script step and set the URL to http://yourserver.dom/somefolder/yourpdffile.pdf The URL will then open in Safari/Internet explorer, and provided they have Acrobat (or some other PDF viewer) installed in their browser the PDF will open and display inside their browser window.

There are somethings one needs to know before answering your question. 1) Is it something that will have to be fully automatic/run server side? 2) Do you want to export the values of a current record, so that the PDF form is already populated with whatever is already in FM, or do you just want an empty PDF to use as an off-line form from where you can extract the field values? To the best of my knowledge there is no FileMaker plugin that can create PDF forms in one go, but there are several server-side applications that let you do it with more or less programming. If you only need it occasionally you can do a lot using Adobe Acrobat Professional. The exact steps depends on what you want to achieve. If you do not need to export (editable) field values from FM you can use Acrobat's ability to import a new background (think of forms elements as a layer on top of the graphical background) That way you create the forms element once, store them in a file, and replace the background with the PDF file you export from FM If on the other hand you need to export the field values you can either export the record as a tab/comma-delimited file and import it into your pre-designed PDF form. To get it working reliably you need to be careful when setting up your PDF form. You can also have a look at the FDF-file format, which is Acrobat's way of storing form data in what's basically a plain text file. FDF files are very easy to import/export from/to PDF forms. Before sending a PDF form to your client you will probably want to enable clients using the free Adobe Reader to save the form as well, so you must enable Reader rights in the PDF. Once you get your forms back you can easily export forms data to a text field, which can the be imported into FM.