I have a solution that creates healthcare provider directories. The directories are made up of several subsummary reports using data from 6 related files. Each subsummary report is for different sections of the directory. The sections are Medical Groups, Hospitals, PCP's and Specialists. Also, a index is made for each section. So as an example, the specialist index lists all of the specialists with the page number they appear on. This is where my problem comes in. The specialist listing has 107 pages in preview mode and when printed it has 104 pages. Then the index is created on the 107 pages in preview mode, not the 104 pages that print. I need to have the number of pages printed equal to the number of pages in preview mode.

This solution runs on a Win 98 PC using postscript fonts throughout. The reports print to PDFwriter to create PDF's.

I have tried it on a PC with NT4, same result. I have tried using the Adobe PS printer driver to create a postscript file, same result. I tried substituting the postscript fonts with truetype fonts, this was worse. I tried PPDs for our Ricoh and Docutechs, same result. I tested this on a MAC in our pre-press department and it worked correctly. So, I know that running this on a MAC will solve this problem, but create another. I do not have access to a MAC for the time required to run this solution. I need to try and resolve this for the PC. Is there anything else that I could try? Or, do I need to push my boss for a new G4?

Thanks

Push your boss for the G4.

That's the quick answer. The slightly longer answer is that Windows ain't WYSIWYG -- especially in FMP. What I find odd is that, in my experience at least, the printed version is always longer than the preview version. Go figure. Macs, on the other hand, are completely WYSIWYG, so you'd have no problem there.

The final answer is actually a question -- are you creating the index separately or within the database? If the latter, then yes, get a G4. But if it's the former, maybe you could try having the DB create the index; perhaps that will fix the problem (being a Mac person without a PC in sight, I don't know, I'm just saying perhaps).

Dan, you keep saying its Windows, but I stongly believe its Filemaker's implementation...its pretty buggy and real wierd. Loads of other programs don't have viewing and printing problems like FM, e.g. Corel Draw, Adobe Illustrator, Pagemaker.

danjacoby, the index is created by the DB. I agree with steveinvegas that other programs do not have this kind of problem. We use the programs he mentioned plus Quark, Framemaker, Acrobat, inDesign, etc. This could be a problem with Filemaker and Windows.

"This solution runs on a Win 98 PC using postscript fonts throughout."

Ok. Was the solution developed on a Win 98 PC or other pc? Or was it developed on a Mac?

I am aware that solutions developed on Mac, even if they are developed with the idea of being run on a pc so they have all the suffixes and other necessaries, do not necessarily print the same. This is compounded by postscript fonts I believe (though I could be wrong on this point).

Keith:

Its got absolutely nothing to do with the original platform. I've only developed on Win 98 and there was always an alignment problem with fields when printing.

It was developed on NT4, then moved to the Win 98 PC. I get the same results on either machine.

I called FM tech support today. I was told they have had issues with sliding and Windows. At their suggestion I created a new DB to see if I could recreate the problem. I was able to recreate it. It appears that the following will cause this in Windows; a layout with a subsummary part, fields sliding up and reduce the size of the enclosing part. I have sent my test file to FM tech support who is sending it to engineering. If and when I get a resolution from FM, I will post it here.

Thanks,

Steve

Are you using Fixed Page Margins in the layout setup? I recommend using page margins smaller than the printable area of the target printer. For distributed solutions, I use .5 all around. This will affect sliding and summary parts of your report. It provides a little better predictability of the page layouts.

I think it just might resolve your issue.

I do have fixed page margins selected in the layout set up. When I spoke with FM, that was the first thing they wanted me to check. In a copy of the DB, I changed the margins as they suggested. The problem still occured. When I made a test DB, I did not select fixed page margins in the layout set up and the problem still occured. I will run some more tests with the margins as you suggest.

Thanks

I tried resetting the page margins to .5 all around, I still get the same result. Thanks anyway dykstrl.

I have also recreated my 5.0v3 test DB in 4.1v3. Guess what, it prints correctly. You have to set fixed page margins or more pages print than previewed.

We have a copy of 5.5 that I will test on. If it doesn't work there, then I will probably need to redo this solution in 4.1v3 or get a MAC.

quote:

---

Originally posted by slstrother:

I have sent my test file to FM tech support who is sending it to engineering. If and when I get a resolution from FM, I will post it here.

Thanks,

Steve

---

Can't wait for the result. I was just at a (Windows-based) client's office today -- they have one layout setup just for printing. It looks one way in Browse mode, another way in Preview mode (no sliding, mind you), and still a third way when printed. I don't mind doing all the work to get the printouts right, but I have this aversion to wasting so much paper.

If, as many of you are saying, FM is just behind the times in dealing with Windows and WYSIWYG, I'd like to see it resolved ASAP.

I wonder, however, if this is really true. The apps you are mentioning are all graphics or page layout apps; has anyone tested this with a long Word document -- or for that matter, a Quark Xpress document with a large text block? I know there are problems printing from Macromedia Director, which wasn't really designed to print anyway.

All is about drivers. Mac has consistent set and even when people are not printing through Postscript, the output is very close and QuickDraw is doing good job.

PC on the other hand has not perfect Postscript drivers and then there are GDI drivers and zillions of various printer specific drivers.

Although I do work on Windows and I slightly prefer them, Mac is far superior in this department.

IMHO, FM is just between the mess in Windows.