Thank you for your post.
On my Macintosh, running OS X 10.5.6, I selected a field using Helvetica and changed it to Bold. If I launch Apple Pages and Microsoft Word, use Helvetica and change it to Bold, the information display appears to look the same in FileMaker Pro, and even when I zoom in to 200%.
Let me know what font you are using, and I will try to duplicate it here.
Thanks for the reply. This happens on any font I use whatsoever, however, try the Helvetica that comes with the Mac OS (it's a .dfont).
And you've got me wondering if the programs you've named do the same "stylizing" thing rather than using the correct font on the fly. Maybe you could send me a screen shot of how it looks at your end of things??
I question the statement "most software programs will bother to look for the correct font". Perhaps you could list some programs that do this?
It seems to me that most office type applications simply apply styles to text in same manner as Filemaker.
If you use True Type fonts, this would seem to be a non-issue completely wouldn't it?
Well, maybe I am a bit jaded as a designer. Both Quark and InDesign look for the real font (in fact, InDesign refuses to "style" a font at all!). My word processor (Mariner Write) does this as well, as does Illustrator.
But it does seem like it wouldn't be a horribly difficult thing for FileMaker to check for linked styles in a font -- and it would make my FileMaker layouts so much better looking. Can't your programmers work on this?
I don't have a web server to post my screen shot, so I have forwarded the information to our Technical Support liaison, and he will be sending you the screen shots. If you haven't received them in the next few hours, let me know, and I'll make sure it gets to you.
Thanks very much for your continued help with this. I have submitted a feature request, but fear that the one-size-fits-all form won't really convey what we've been through with all our back-and-forth about this issue!
I'm crossing my fingers that the development team will listen to this, but if there's anything else I can do at my end of things, please let me know -- or if you're able to jog them a little bit at your end, I would much appreciate it.
It's difficult to say how well it will be received. I think the main concern is if one system doesn't have the second font. Using your/our example, if I only have Helvetica, your system has Helvetica and Helvetica Bold, your have a Helvetica field that you make bold, so it switches to Helvetica Bold, and then you give that file to me, what is going to be the result? Will I get "Font not found"? Or, should FileMaker keep track of all the Font ID's and determine the proper substitution? If that can be answered easily, then there is a chance.
Please don't get me wrong! I like the idea. I'm just trying to give you some insight and reality on the implementation.
I'm keeping my fingers crossed . . . !
Regarding the graphics font issues with FMPro ...
On the Mac, the problem is that FM (9&10) will not show the individual fonts from the font 'suitcase'. I worked around this issue by bursting the font into its component fonts - in my case, I have only been using Verdana, so it was relatively non-painful - I dread to think what a 'proper' graphics designer would have to do :-).
Remove the original Verdana font from the fonts folder (check your users AND the system font folders BTW - Verdana was installed in both of them - this can cause other non FM-related problems :-), pull the component fonts from the suitcase and install those into your fonts folder. The font Verdana now shows as 'Verdana','Verdana Bold', 'Verdana Italic' and Verdana Bold Italic' in the fonts menu. I actually used individual 'PC' fonts (they were opentype fonts) rather than bursting them from the suitcase, but it is the same thing. Now you can use the individual fonts correctly (not applying having to apply 'bastardised' attributes) - they now display and print correctly. I'm pretty certain that FM won't work correctly with postscript fonts, but I may be incorrect - you could suck it and see and report back.
On the PC, FM Pro has a WORSE issue with its font system - if you do as described above, it only uses the first font in the list - take Verdana for instance - because Verdana Regular is the first in the list alphabetically, that's what it uses - you don't get to use the bold/italic/bold italic versions so you have $hit out !!!!!! I can find NO WAY around this :-( This is a VERY SERIOUS issue that needs fixing. At least on the mac platform, you can burst the font family into its components and be able to use them individually.
I hope that someone from FM is actually monitoring this (and the crashing issues with snow leopard when serving - just thought I'd add that LOL :-)
Thank you for your post.
Yes, someone from FileMaker, Inc. is monitoring... :-)
I have forwarded your concerns about fonts under Windows OS to our Development and Software Quality Assurance (Testing) for review.
I'd like to contribute to this discussion because I have also been frustrated by Filemaker's font handling. (I'm using Filemaker Pro Advanced 11 on OS X 10.6.3, so I can only speak to Mac Filemaker.) Actually in drafting this post I discovered that Filemaker's font handling is not completely broken, it's just inconsistent. It works "correctly" with some fonts but strangely with others. I have also found that this strange font behavior creates problems in Instant Web Publishing where the appropriate fonts don't display in the web browser. I've taken screenshots of the problems so we can have something definite to discuss.
There seem to be three related problems with fonts in Filemaker: 1) it often doesn't group font families together, and 2) it tries to apply "faux" bold and/or italics to fonts that aren't grouped, which looks bad and is typographically incorrect, and finally 3) in font families that aren't correctly grouped, using any but the "regular" version of the font will not display properly in Instant Web Publishing.
Problem 1: Grouping of font families
As far as I can tell the problem revolves around the notion of font "families". On Mac OS X, In MS Word, Adobe Creative Suite, even down to lowly TextEdit, when you look at a list of fonts you see them grouped as families. Let's take the example of the built-in font Hoefler Text. Within the Hoefler Text family there are several versions the typeface: Ornaments, Regular, Italic, Black, and Black Italic. Yet these are all variations on the same theme. When I want an italic Hoefler Text, I want the application to choose the "Hoefler Text Italic" font. I definitely don't want the application to take the Hoefler Text Regular font and slant it 45 degrees. Yet in some cases that's what Filemaker seems to do.
At first, like the original poster I thought that FMP completely ignored font families. When looking at the list of available fonts, say in Layout mode, I see Arial, Arial Black, Arial Bold, Arial Bold Italic, Arial Italic, and so on, when what I would like to see is just "Arial", representing the entire Arial family. However in writing this post I discovered that some fonts are indeed grouped as families, even though the majority are not. Taking the example of Hoefler Text, in Filemaker's drop down font menu I only see "Hoefler Text" and "Hoefler Text Ornaments". When I have some text set in Hoefler Text and I click the I button in Filemaker, it automatically uses the "Hoefler Text Italic" font. This is what I (and the OP I suspect) would deem the "correct" behavior.
However some fonts don't behave that way. Take the Microsoft font Georgia, also included with OS X. The Georgia family includes Regular, Italic, Bold, and Bold Italic weights. But unlike Hoefler Text, Filemaker doesn't just offer the Georgia family as one option in the font menu, it shows Georgia, Georgia Italic, Georgia Bold, and Georgia Bold Italic as four separate font choices.
This is a problem of consistency: why does Hoefler Text show up as a family but the Georgia family shows up as four separate fonts? Is it because the fonts are packaged in different file formats? Other OS X programs, such as TextEdit or Word, show both Georgia and Hoefler Text as families, there shouldn't be any reason why Filemaker would work differently. And there definitely shouldn't be any reason why Filemaker is internally inconsistent with itself. But this problem I suspect is the root of the other, more serious font problems.
Problem 2: Faux bold and italics
Comparing again Hoefler Text and Georgia, Hoefler Text displays italics correctly and Georgia does not. By "correctly" I mean that when I have text set in Hoefler Text, and I click the I button, the text is italicized by using the Hoefler Text Italic font. With Georgia, when I have text set in Georgia, and I click the I button, the text is italicized by applying two conflicting methods: switching to the Georgia Italic font, and by trying to do a faux italic effect by slanting the text. Slanting text to produce a faux italic effect is bad enough, but slanting an already italic font looks awful. This bug was already reported here but I believe not diagnosed correctly. It was also reported here in the case of applying faux bold on top of an already bold font, but there was no reply to this report.
On the other hand, since Georgia is not grouped as a family but displayed in the menu as Georgia, Georgia Italic, etc., I can directly choose the font "Georgia Italic", without pressing the I button, and it displays correctly as italic Georgia, no faux italics.
Here is a screenshot which illustrates this problem very clearly. Note the difference between Georgia Italic and Georgia + the I button. The italic f in the word "of" is a giveaway that Filemaker is both using Georgia Italic and applying faux italics. (Click to see full-size.)
Even if this were the extent of the issue, it would still be a minor inconvenience, but livable. One could just learn to directly specify the Italic variant of the font directly, and only use the I button if the font were grouped as one family and the Italic variant couldn't be directly chosen. However, the problem that elevates this from just annoying quirk to notable bug, in my opinion, is the fact that if you take that approach, Instant Web Publishing won't show the right font at all.
Problem 3: Fonts in Instant Web Publishing
Instant Web Publishing displays italic Georgia only when the Georgia font is used and the I button is pressed. IWP will not display italic Georgia if you choose the "Georgia Italic" font directly. Instead it falls back to the default browser font, which is typically Times New Roman. This is because the correct way to specific italic Georgia on a web page is using this CSS code: font-family: Georgia; font-style: italic; while specifying font-family: Georgia Italic; does not work at all in CSS. (CSS is the styling language used on web sites.) The former is the code that IWP generates when using the I button in Filemaker, while the latter is what IWP uses when specifying the "Georgia Italic" font in Filemaker.
In other words, what looks bad in Filemaker Pro looks good in Instant Web Publishing, and what looks good in Filemaker Pro looks completely wrong in IWP, because the browser ends up using the wrong font altogether (Times New Roman). Below is a screenshot of that same Filemaker layout in IWP, with the source code of the page shown at the bottom that demonstrates the CSS code used in the two different italic Georgia paragraphs. (Click to see full size.)
To sum up, the font handling behavior in even the newest version of Filemaker Pro Advanced 11 is both inconsistent and somewhat broken. Sometimes, in the case of Hoefler Text and other OS X fonts such as Helvetica Neue, it correctly groups the Regular, Bold, Italic, and Bold Italic versions of fonts into a single family, and switches between them appropriately when using Filemaker's B and I buttons. However in other cases, such as Georgia and most other fonts on my system, the Regular, Bold, Italic, and Bold Italic versions of the font are not correctly grouped as families, and when using the B and I buttons Filemaker unexpectedly applies a faux style on top of the correct font for very strange looking results. Furthermore, the workarounds needed to make all fonts appear correctly within FMP on the desktop, cause fonts to break when accessing the database in Instant Web Publishing.
All fonts should be grouped into families, the way some fonts are now. If an italic version of a font exists, no faux italics should be applied on top. Faux italics may still be applied if the font does not have a native italic variant, I am indifferent on that point. Personally I would be happy if the faux italics function was removed altogether, as from a typographical point of view the results are always poor. Fixing the two above points should address the problem with IWP. There is no bug with IWP per se, it's just that FMP's strange font handling can cause a database designer to choose fonts in a way that's incompatible with the web.
Thank you for the detailed post.
I have forwarded the entire thread to the Product Manager. When I receive feedback, I will let you know.
In the mean time, be sure to enter this information into our Feature Requests web form at:
Although I could easily copy your post and paste it into the web form, there are additional questions asked that only you can answer.
A lot of filemaker users in my company are having that same problem (including myself) . They all have Apple computers from 10.4 to 10.6 and using filemaker 9 to 11.
I first thought it was a conflict with the fonts installed by office 2008, but the bug occurred as well on computers without office. installed.
Well, if you "format" a text with "bold", it seems, that FileMaker bolds it, but the OS has noticed, "Oh, it's a bolded text, so i switch the font with the bold-font".
And now, FileMaker bolds the bold-font.
This is clearer, if you use "italic". You can easy notice with the char "a", that not the original font will be double bolded, but the italic font get "italiced" again.
A "a" (like an Arial has a small "elliptic" something with a protuberance on the top.
A real italic "a" is like an "o" with a vertical line on the right side ...
An false italic is the same "a" like of the normal font, but falling on the right side like drinking too much.
So, it seems, it is the real italic which is electronically pushed more once more time on the right side.
For text in the fields, I don't know how to do.
For the labels near the fields, always use the real font, without formating.