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.

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.

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.

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.

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.

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?

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.

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

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

Zip your Filemaker file.

Got it, thanks for the pointer

Copy_of_Property_File.fp5.zip

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.

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.

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

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.

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:

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

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.

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

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

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

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?

It is actually 6.0 v4

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.

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?

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

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, 200817 yr by Guest
Added sentence

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.

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.

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.

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.

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

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.

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.

Sorry, forgot to attach

sample_file.zip

I have seen this. Not in Filemaker specifically, but the same principle. Granted, the differences won't be as dramatic when only the printer driver is different as they will be with two versions of the same font. But I'd be surprised to see a Postscript printer put the text EXACTLY in the same space as an inkjet.

I may be skewing my experience because I have always created the document and printed on the same machines. Testing here, all of our printers are laser (Xerox workcenter 5655, Xerox workcenter pro C3545, HP 4600 dn and HP 4250n; the other two are duplicates of these). All print the same. I am not sure inkjet would be required for testing because both the Dell P1500 and P1600 are also lasers but I am not discounting this portion of my tests at all. Simply, I have no inkjets to test right now. I have no idea what my home system is - it is multifunction scanner, fax, copier etc; fairly cheap color thingy. But it too displayed (on my home Dell) and printed properly and matched my results with these lasers.

When I open this last file, the fields are way off (when viewing in browse). I move them to align them (in browse) and they are fine - preview, print and pdf to each of our printers and from all three of my boxes. I would ask, tking, when you select the large text box and then select font, what does it show? If a font isn't installed, I believe that FM chooses the closest font it can. Arial is standard in Windows systems. I only have one Arial installed in FM.

Michael, I created a test layout as you've suggested and it prints fine but they are all lasers. I am unsure what other tests I can perform. I wish other people with windows systems would jump in and help us here. This is something I think is important to understand thoroughly because I do not want to ever create a solution based upon something which would break if it was used on a different system. The only time I have had things not line up is: 1) when viewed on a Mac or 2) when the font the text is based upon isn't in the other system and FM has to substitute. But I am using a brand new computer. And even on my laptop and Interfaces box, it shows that text block is Arial.

I'm not done. I simply won't give up until I understand it. Good grief ... now I'm off on tangent studying fonts; differences between Type1 and Type 3 and the history of Adobe keeping Type1 to itself and ... YAY! Bottom line - I have no answers right now and nothing else I can share. If I discover something interesting I will post it.

Edited August 15, 200817 yr by Guest

OK, maybe we are getting somewhere. The text was created and or pasted into Filemaker but I needed to use an 11 point font which is not in the menu selection. I therefore used the font size up/down button to select 10 point and then moved it up one notch to get 11. Maybe the size not showing up is what is causing a rendering problem. I am surprised that you open the file I sent and see the fields misaligned. My system shows them in perfect alignment,. This leads me to believe there could be a screen font issue. Iven checked my screen settings. It is set for True Color 1024 X 768 but I don't think that matters.

No good there either. I just selected all text, changed to a menu size of 12 point, realigned fields and printed. Screwed up as ever!

I think that true type fonts can adjust easily up or down by a point so I'm not sure that makes a difference (I've always been able to specify custom and 11 point and it's always worked fine for me). And I too tried changing my resolution to 800x(something). But the fields still lined up perfectly with the text.

What happens if you select all of the text and re-specify it to Arial 11 point?

To help us figure this out, I need for you to specifically answer questions asked. Do you have Arial in your fonts list and is that what it shows when you select the text block?

We are overlapping in posts. I'll slow down a bit. :blush2:

Sorry, our internet was just down for about 3 hours. To answer your questions, I do have Arial in my list and I have selected all text to specify font and size.

I would suggest making this simple test:

Open the attached file.

Go to layout mode.

Select US letter as the page size.

Align the lines precisely with the "_" and "|" characters in the text (as shown in the picture).

Print the file (perhaps select US letter again).

Archive.zip

I did the printout just as you asked. Aligned both the horizontal and vertical line on both samples. Selected letter from the print set up before aligning and from the properties tab once I went to print mode.

Top sample:

Vertical line printed a hair to the right like your sample.

Horizontal line printed about 1/4" too low.

Bottom sample:

Vertical line printed about 1/4" to the right

Horizontal line printed slightly above where it was lined up (1/64"?)

Surely it's the other way round? The lines stayed put, but the text took up more/less space? If you're not sure, put a 1" grid of lines behind the text.

That was very interesting! You are right, the text changed. Using a 1" grid this is what I found.

Top text box:

Top of the text is where it should be. The las line of text has shrunk upward.

The left edge of text is where it should be but the right edge has shrunk up and isn't quite as far right as it should be.

Bottom Text box.

Top and left side s of text where they should be bottom has shrunk actually grown slightly larger than it should be and the right edge has shrunk more than the text in the upper box.

OK, then. If anyone can explain this other than the font used for printing being different from the font used for on-screen rendering, I'd be interested in hearing the explanation.

BTW, you should repeat the same test in another application, say Word, to confirm it's a system-wide issue.

I think you make a good point. furthermore, I ran another test using a JPG and putting a few fields over top of it. They held their postion just fine. Unfortunately, if you have to create a JPG out of your text fields in order to keep evrything aligned in a document, you have created a much larger file.

Well, the real solution is to merge the fields in the block of boiler-plate text, as mentioned before.

BTW, JPG is not the best format for pictures of text - PNG or GIF should work much better, and if you reduce the colors to a few shades of grey, they won't be that large either.