Windows, Sliding Fields, Many Fonts, Clipped Text

[ori_wel]

I have a layout with thirty single-line text fields on top and a large half-page text field for a comment beneath. The upper text fields slide/collapse if empty. The comment field rises up accordingly. The layout extends over a page and a half, but with sliding prints without exception on a single page.

The default font on the comment field is Times New Roman 11. Users have pasted in comments in numerous sizes and fonts.

When printing from a Windows machine (running FMP 5.5v2) to a networked printer, the comment field which contain non-default fonts get cut off on the bottom. Initially it happened only with an HP 4200. Now it is happening on other networked printers as well.

I cannot use a calculation field (i.e. Comment_c = Comment) b/c record-specific user formatting would be lost. I explored printer drivers. It's not the FMP updater.

I would appreciate any good suggestions, 'cause I'm out of ideas and faced with a neddlesome problem I've got to solve. Thanks in advance!

[Angela10]

In the past, after I've tried all the recommended fixes for weird printing problems, the only thing that has worked is to recreate the layout from scratch. Don't even copy and paste objects from the funky layout onto the new one, just start from New Layout/Blank Page.

The problem I most recently had was a square of blank space showing up on the printed page, like a ghost drop down was associated with a field and was being displayed on the printout (didn't display on the print preview) This was happening with all printers on the network. I tried all sorts of things and just had to bite the bullet and redo the layout.

I'm sure people will have other suggestions, but thought I'd throw in my two. Good luck, I understand how frustrating it can b.

A

[Barbecue]

I have had lots of font issues when printing to HP 4000/8000 series printers from Windows, so I feel your pain.

Have you tried placing the comments field in as a merge field in a text box instead of as a data field?

Check how the fonts are being handled by the printer driver. You could be getting automatic substitution of the printer's internal fonts for the ones in the database, which can cause unexpected results. You can control this in the driver settings.

Try changing how fonts are sent to the printer (i.e. as Outlines, as Bitmaps, or as Type 42.)

You said you've explored the drivers, but have you tried installing replacing new drivers with older ones? Some of HP's drivers are pretty dreadful.

General rules to avoid font printing troubles...

Make sure every machine has all the same fonts available.

Make sure every FM installation has the same fonts showing in the "configure/more fonts" menu.

Make sure every user is using the exact same printer driver, configured exactly the same way.

Another thing that can cause weird problems is if you are using a script to set the printer settings. If the name of the default printer does not exactly match the name of the printer that was used when the script was defined, you can get strange results.

The fact that you need to keep the user formatting means you'll never be able to eliminate all possible problems. If someone pastes some 72 point text using the Willie's Wiggleworms font, who knows what might happen. Bad/weird fonts can also crash FileMaker.

[ori_wel]

Thank you both for your careful and informative responses.

Barbeque (Dev7), can you comment about how FMP7 handles text formatting? I believe I read that you can preserve user formatting in a calculation.

Say I have a field called NOTES into which a user has pasted Willie's Wiggleworms size 12, with the exception of the first sentence which is W'sW bold size 24.

If I were to create a calculation field called NOTES_c = NOTES and set the print font to be TimesNewRoman size 11, would this NOTES_c change the font to TNR but preserve the bold in the first sentence? How would it handle the size changes?

Thanks for any further assistance you can offer!

[Barbecue]

You're right, FM7 doesn't strip away text formatting the way earlier versions did.

In your example, the calculated result should preserve all the formatting, including the font, style, size. The exception would be if you applied formatting to text that matched the default formatting for the input field, in which case FM would see that piece of text as unformatted, and would then apply the default formatting of the calculated field.

Exception: If you paste formatted text into a field taken from a text box in layout mode, the formatting does not get overridden the same way it would if you applied the formatting to the contents of the input field directly in the field itself.

This is hard to explain, I've attached a simple demo FM7 file that shows what I'm talking about. I've also put a screen shot on the end of this message in case you don't have access to FM7.

The best way to get a feel for this is to spend some time experimenting with it. Copy and paste, cut, reformat, drag-and-drop, and see how it works.

Overall this change is an improvement, but it does take some getting used to, and when you've got users who try to format their data to match their Sponge Bob Squarepants desktop theme, it can lead to some surprising results.

FormattingDemo.zip

[ori_wel]

You are very generous with your response. Sorry for the delay in getting back - I stepped away for a bit for other matters...Thank you very much for your good advice and these useful tools!

DSW