Not really WYSIWYG

[The Mad Jammer]

I have a form with lots of input fields on it. When I print the form every thing lines up perfectly except for a few fields, curiously enough all on the same line. The leftmost field lines up OK but all of the rest of the fields on the line are sliding to the left. The fields are laid over the top of a free form text object.

It's important that the fields stay where they are because part of the free form text are underscores, which is where the fields are supposed to be positioned. In Browse Mode they look perfectly aligned, but when I print the form the above mentioned fields slide left. All the rest of the fields on the form, and there are plenty of them, line up fine. I thought it had something to do with a numeric field on the line, so I put in a calculated field as a NumToText(num) and that didn't help.

Any ideas what might be causing this?

The Mad Jammer

[Ender]

mmm...perhaps the fields in question have Sliding turned on.

[The Mad Jammer]

I thought that might be true as well but I checked it out and none of them have sliding turned on.

Jammer

[-Queue-]

Fields and graphics (or text) don't play well together, at least not on Windows. You have to experiment (trial and error, blah) to determine how they should be overlapped or how ridiculously far apart they should be for the report to print correctly. I would suggest printing to PDF over and over again, making small tweaks, until you achieve a suitable result. If you want to preview it, you'll probably want to use another layout. It's usually easiest to have separate layouts for previewing and printing when creating forms or reports such as this, since it is in no way WYSIWYG.

[Dermot]

Hi There,

When I get fields printing over the top of something else the first thing I look at is the alignment of the field - Check if the fields that are printing funny have the same alignment (e.g. left aligned) as the fields that are printing OK !

Sounds simple but you can get caught out by it !

Dermot

[The Mad Jammer]

Dermot,

I've looked at the alignment of the fields and all of them are left aligned which they should be. As I said, the fields look fine on the layout in Browse mode, but the actual printout is something entirely different. I experimented with changing the alignment jsut for kicks but that didn't help much. I'm afraid -Queue-'s take on it may be correct, this is a Windows app and the fields are ridiculously far apart. It wouldn't be so bad to use merge fields embededd in text but since this is an official form, everything must line up perfectly and have the underscores in the right place and for the correct length and all that jazz. That PDF idea isn't so bad so maybe I'll pursue that. Or perhap's I'll iwn the lottery tonight and none of this will matter to me anymore.

Thanks all.

The Mad Jammer

[stanley]

Browse mode has nothing to do with printing; what matters is what does it look like in Preview mode? If everything is in the right place in Preview mode, then you'll have to follow Queue's advice, and tweak it until it works. I deal with preprinted forms alot in solutions for Windows, and this is what I always end up having to do, too.

-Stanley

[The Mad Jammer]

Stanley,

Let me explain about the Browse Mode statement.

The form I'm printing is a copied layout of the Browse Mode input layout because the client insists that the input layout they are seeing should be exactly what they are going to print. They don't yet understand that inputting data has nothing to do with formatting how it is printed. So for them, as long as the form looks like right in Browse Mode it should be right in its printed variation as well.

I once tried to reformat the input layout to be more user friendly and eliminate extranous stuff and the user went ballistic. Still the printed items must line up correcly and right now they are not lining up with relation to other objects on the form. So we adjust their positions to be as close as we can make them to correct, but they are just not WYSIWYG in Windows. Perhaps MAC's behave better with this issue.

The Mad Jammer

[brimfulof]

We have the same problem. It doesn't seem to be a Mac or Windows issue, we found a discrepancy with both, but it is GREATLY exagerated in Windows. It's not actually just a display problem either. If you change the size of the object to exactly what you want it to be using the Object Size dialogue, it prints to a different size. Looking at it in Preview mode doesn't help because FM thinks the text box (for instance) is bigger than the paper it is printing onto, but when it's printed it all fits on the page (although a blank page is often printed as well).

The PDF trial and error method is the only thing we've managed. Any other suggestions would be greatly appreciated.

[justcosmic]

Just reading the above, as i am having frustrations trying to resize objects to what i want.....and not being able to "fine tune" to exact measurements......as if there is some kind of quantization going on; but reading what you are all finding with printing, makes one want to give up entirely....what's the use of all those hours of programing if filemaker cant even print accurately!....surely thats not too much to ask of such a sophisticated program...!

[FMDuck]

What comes to mind is the font scaling differences between Win and Mac. It may be that the field is anchoring to the font position within the text object? Have you tried inserting a period or something to see if the movement is directly proportunate to the font position? Can you place the field under the text? Did you try locking the object on the layout? Or maybe making the field one pixel higher and positioning it one pixel above the text?

Good luck.

[justcosmic]

thanks Jeff for the response....I am mainly concerned with some repeating fields,which are to be printed out as labels. The exact size has to match a physical object. Perhaps i will try changing the font selected for that field to see if that works?

thanks again.

However, it does seem to print fairly accurate to the size stated....

....for now I have resorted to printing to PDF, then using a PDF editor to manipulate the dimensions more accurately. That seems to work, but it seems very poor if filemaker cant do this kind of thing...!