Misalignment of fields when printing

[tking]

I am having issues printing when I mix text and data fields. I've had this with versions through 8.5. When I preview the page it looks fine but when I print, the data fields I have put in front of the text will often print 3 or 4 lines lower compared to the text beneath. I am trying to create a text form with entry fields. The text form may have a very specific space for the fill-in data and when it prints 3 or 4 text lines lower it creates a problem. I have to end up guessing where to put the data fields by raising them in browse mode printing the form to see where they fall and then adjusting again. The same thing occurs if I put a line over text. I may want it to fall between 2 sentences and then when it prints it is in the wrong place. I have searched through the forums and I am shocked this hasn't been discussed unless I just failed to find the thread.

[bcooney]

If you're mixing layout text and field data, why not create a layout specific for printing that uses merge fields? I would like this would solve your alignment problems.

[tking]

Thanks for the reponse. I tried that but I found it created a different set of problems. If you change fonts to distinguish the merged data fields, you then have trouble selecting and editing the text or merge fields. For instance, if you highlight just the merge field and change the font the next time you do an insert to correct a typo in your text, you find that your insert point causes you to edit a character that is 5 or 6 characters from where you thought you did the insert. I even tried changing the zoom in case that would allow me to view it the way it is printing but it didn't help.

[bcooney]

Is this the behavior that you're seeing? KnowlegeBase Article 4986

This is an old version issue, but maybe it'll give you some clues.

[tking]

Not really. It doesn't jump when I click the field. It jumps when it has been sent to the printer. As I said before, if you put a field on top of an existing text field (use the arrange function to bring the field to the front), the field may print much lower on the sheet than it appears on the screen. If I use a merge field to make sure it is on the same line as the text, it prevents me from changing the font in the merge field because I then can't edit the surrounding text. This is frustrating because I understand this isn't a Microsoft Word document but this is the biggest issue I encounter with Filemaker and I've been using it a long time.

I fix the problem by printing, then moving the data field up a little, printing again, moving up again etc. until it prints correct. Obviously I'm burning trees and time. It would just be so nice if it was WYSIWYG.

[comment]

You should have 2 layouts: one for data entry and editing (where the placement is not important), and one for printing (using merged fields).

However, you shouldn't be seeing a difference between preview and print, so that's not a solution to the real problem here. Do you see the same difference between preview and print to PDF?

[tking]

I do have it set up for a seperate data entry and print. That's a good question on the PDF. As you probably know, when you change zoom levels you normally see a difference in line breaks on text. I have never tried to print to PDF but I just did and it definitely is what I see coming from my printer but not what is on my screen.

[comment]

Why don't you post your file (or a simplified version of)?

[tking]

Attached is one page of a Real Estate Contract I am putting together. When you open it in Layout mode, you will see the data fields moved to accomodate the printing problem instead of aligned where they should be on the layou. I get the same problem if I am using a JPEG scan of the document and laying data fields on top, that is why I took the time to convert the document to text using OCR software, hoping it would eliminate the issue. Unfortunately it won't let me attach an fp6 ext so I converted it to a PDF and changed the data fields to red text to make it easy to distinguish. If I have an email address, I can send you the actual file. Thanks

Copy_of_Property_File.pdf

[comment]

Zip your Filemaker file.

[tking]

Got it, thanks for the pointer

Copy_of_Property_File.fp5.zip

[comment]

This is what your file looks like upon opening (attached), and it prints the same.

My guess is you have two different versions of the Arial font; one is used for on-screen rendering and the other for printing.

If you merge your fields into the boiler-plate text, the fields will be aligned correctly. You will still see a difference between preview and print, but I don't think it should matter.

[LaRetta]

What appears to be happening (to me anyway) is that the page is too wide for the printer selected. When I decrease the large text block (the entire contract document) to 514 px and move it into the center (which decreases about 20 px on each side) THEN align the red text where it should, it stays put.

What is happening is that the text shifts when allowing for the margins required. If you look at The Undersigned Buyer agrees line at the far right end, you will see the words broker referred to. But when printing, it must bring the margins in. And the last word becomes referred. This is only one example as you work down through the document.

These changes in the margins will change where the field 'lines' belong, sometimes dropping the lines to the next row and thus shifting the entire document downwards. As you'll notice, each place the fields exist, they drop further and further upwards by one line. Again look at the third paragraph first row in 1.2 Lender Pre-Approval. A pdf ends the line in Broker, but the preview ends with Broker within.

I probably didn't explain it very well. But I've done this same thing and that's why I believe I recongize it.

[tking]

I would agree with the last posts but 1. the text is being highlighted and then the font applied within filemaker. 2. As far as margins go, This will happen when I set the margins to .5 which any printer will accept. It also happens when I put the data fields over top of a scanned JPG of the same document and then lock it to the layout

[LaRetta]

PS - I don't have vs. 5 or 6 on this box or I'd attach my result back here. I converted it to vs. 9 to move it around. But after I decrease the width, it all lines up no matter whether I print to printer or print to pdf.

[LaRetta]

Makes no diff to me. But I'm on windows system as well and, prior to shifting the size of the text block, I get the results you do. And after I decrease the text block as I've indicated, I get this:

[comment]

I don't know: if I have text (or anything) that goes outside the print margins, it's just cut off - nothing gets shifted.

[comment]

I would agree with the last posts but 1. the text is being highlighted and then the font applied within filemaker.

I don't see what bearing this has on the issue.

[LaRetta]

You are missing my point, I think. I didn't say the PRINTER shifts it. Previewing shifts it to match the current printer; maybe not on Macs but this is surely the behavior I deal with daily on Windows.

I suggest trying the attached (I'm sorry I can't give you fp5 but maybe someone can duplicate the width and placement in fp5) or ...

Set the full text block to 514 px wide and place the left edge at 48 px and top at 48 px. See if it stays for you. The text stays put for me - matches up in Browse; matches up in Preview; matches up when printed and matches up when printed to pdf. Maybe I'm just lucky. :wink2:

Copy_of_Property_Filerev.zip

[tking]

I tried reducing the width of the text box as you suggested. I even reduced my layout margins to .25 and set my text box up to be at least a 1/4" inside those margins. I'm still getting the alignment problem whether I print or create PDF. Now I'm really puzzled. I had hopes your method would work. Like you said I'm running XP so I can't imagine what the difference is. What is your layout margins and what width did you set the text box to be? See my attached PDF.

Copy_of_Property_File.pdf

[comment]

It doesn't match up when I open your file, so I'll stick to my font theory.

[LaRetta]

And I, unfortunately cannot test vs. 6 right now. I will test it at home tonight. I don't recall ever printing to pdf on vs. 6.

But again, if you look at where the red text is, it decreases by one line as it moves down ... the date is one row down; the tax parcel is two rows down (as is the address because there is no adjustment in widths from the prior row to that one). And then the price is 3 rows down and so forth.

I shall try to test tonight and give you further input on it. BTW, are you on 6.0v3?

[tking]

It is actually 6.0 v4

[comment]

Even with a fresh new file, if I carefully align a field within a "hole" in a block of text, it breaks up completely if I zoom in (not always, but with some font/sizes combinations).

The point is that the position of the holes depends on the rendering, and rendering for screen is not the same as the one for print. I suspect you may see a more stable result with Arial 12 or Verdana, but that's not the point. The real solution is to merge the fields into the text, so that the data sticks to its place regardless of any variations in character/line spacing.

[tking]

Is there a way to set the space occupied by the merge field to a specific size? I ask this since I am re-creating legal forms that have a specific look. If I can't specify the width of the merge field, then I can't be sure how the text will break on each line if the data in the merge field is say 5 characters one time and then 20 characters the next?

[comment]

To some extent, it could be controlled using tabs - but I don't think it should be. Does it really matter how a particular paragraph is broken into lines? After all, what's the purpose of doing this on a computer, if not to have this kind of flexibility?

I have made a little sketch of how it could look (the second layout in the file).

Property_FileM.fp5.zip

[LaRetta]

Well all I can tell you, Michael, is that in vs. 6, I had many forms which needed this type functionality, ie, fields placed on forms. Some forms were scans with the fields placed on top. Some were text blocks as is this case. They were always handled on Windows and I never had an issue (printing to several different printers).

And if the block is straight text, then it MUST be the same font - Windows does not have two types of fonts as you suggest. What you see in browse is the same font spacing you will see in preview or print. If the text doesn't change, how can it move? What WILL change is the printer-defined margin. And if the form is a scan, it CANNOT change so I would question that it too shifted differently than the fields. Again - the only thing that can SHIFT is print or preview against a specific printer driver.

The reason I bring it up again, instead of just letting merge solve the issue, is that he said it has happened many times through many versions and that is NOT consistent with my experience using many versions and many different printers; printing to many forms. If the reason isn't resolved here, it will never be resolved and an opportunity will be missed because it is NOT standard behavior here. I too think the answer is merge but that is not ALWAYS the answer. So understanding this is important!

tking, do you specify your printer in Print Setup first? Do you have the latest printer driver for your printer? Much depends upon an individual printer's gutter size and font capabilities. BTW, I have vs. 6.0v4 here at home. I align in browse, it previews the same, it prints the same ... lined up perfectly. I too stick by my theory. :wink2:

Edited August 15, 2008 by Guest
Added sentence

[comment]

Windows does not have two types of fonts as you suggest.

A specific Windows SYSTEM can easily have multiple versions of the same font. Quite often an application will install "extra" fonts, and its Arial comes from another foundry. Or the printer may have built-in/downloaded fonts. I have seen this more than once.

Even without multiple font versions, it's easy to get this "effect". As I mentioned earlier, zooming in with Arial 11 breaks it up (on my system). I think I know the reason, but I don't want to get too deep into technical details. All I wanted to say is that you cannot rely on the rendering being the same whether it's done by Filemaker, the printer driver or the PDF engine. The fact that it doesn't happen on your system proves only that it doesn't happen on your system.

[LaRetta]

The fact that it doesn't happen on your system proves only that it doesn't happen on your system.

No. It doesn't happen on many, many different systems I have used and on many, many different FM solutions with at least 20 different printer combinations. I would not base my statements on one single system nor on such a limited experience. And I certainly wouldn't be strong about my stance based upon limited experience. You should know me better than that.

Well I'm done with this thread. I have said what I felt I needed to say. I agree merge is the way to go in this case because it is cleaner to have the inserted text merge together instead of looking like it is printed on a form. But when one NEEDS to have it look like it's printed on a form, please re-consider some of my comments.

[comment]

Just because I disagree with you, it doesn't mean I belittle your experience. I don't think it's fair of you to suggest that I do.

If you have access to both inkjet and laser (PostScript) printers, you can perform a simple test. Put some text on a layout, align it to the left, and draw a few vertical graphic lines to indicate the precise position of selected line breaks. Make the page margins fixed and extra wide to take this aspect out of the equation. Arial 11 and Verdana 11 would be a good choice for this, I think.

A belated addendum:

And if the form is a scan, it CANNOT change so I would question that it too shifted differently than the fields.

That point had me puzzled too.

[LaRetta]

See the quote of yours I quoted above.

Just because I disagree with you, it doesn't mean I belittle your experience. I don't think it's fair of you to suggest that I do.

I suggest nothing. You said it was based upon system (singular). I was merely saying it was not based upon one system but rather many.

[comment]

Well, it felt like I was not allowed to disagree with your conclusion, because it's based on your experience.

[LaRetta]

I am totally fine with your disagreeing with me, Michael; heck, you should know I even enjoy it.

Since printing onto existing forms (that I've created in FM) is something I have done through every version since 5.5 and onto many different printers ... and since I have NEVER had the issue described, I thought it worth considering seriously.

There also have been no posts about this problem that I recall on four different FM forums. And I can assure you that this functionality is needed and implemented in offices all the time. So I question whether there is something simple which is being missed! AND, because the issue also appeared when printing onto scanned form, I look for horses and not zebras.

From home, I took the form and printed to pdf and printer. Both are fine and match the browse mode alignment. And here at work, I am bringing it up in versions 7, 8, 8.5 and 9 on my three different systems and I am printing to 6 different printers. So far, every printout and pdf comes out perfectly. I will also try the test you suggest. I want to understand the truth beneath all of this too.

[tking]

I do specify the printer. I am using a Dell P1500 and/or P1600 and I got the same results on both. If you look at the file I'm attaching, it has page margins wider than the text block and the overlay data fields are lined up where they should be on the form. I have printed this on both the printers listed above as well as printing to a PDF. Ihn all cases it comes out the same. Date is 1 line low, Couty and tax ID are 2 lines low, etc. I am really surprised you are printing fine with this file.

[tking]

Sorry, forgot to attach

sample_file.zip