Font styles on Mac and Windows

[Buckie]

Maybe I'm missing something totally obvious here, but why do the fonts behave so differently in MacOS and Windows with regard to styles (bold, italic). On a Mac you'd choose a separate font face such as Arial Bold Italic for example which on Windows in the same database is going to be rendered as just plain Arial. On Windows you have to select the "i" and "b" buttons to achieve the same effect, however on a Mac this becomes plain Arial with artificial bold and italic effects applied (definitely not the same thing as a true Arial Bold Italic). This totally breaks any cross-platform font compatibility for me beyond using plain font versions. Why's that? Any way to get around it to make Windows and Mac display the same font face and also be able to edit on either platform without breaking it?

[Vaughan]

The font rendering engines are different on Macs and PCs and have been forever.

Summary: do the design on the Windows side. Fonts look bigger and take up more room in Windows than on Mac.

Do some tests of fonts at different sizes.

[LaRetta]

Hi Buckie,

Be sure the font you choose is standard on both platforms. Verdana is standard and looks (I think) the best on both as well. I haven't checked but, verdana comes in only one style even on Mac, right - and then you specify bold or italic?

Many (may I say most?) of the top Developers use verdana. When I was new to FM, I thought it was called 'veranda', LOL, which is a porch. Fonts look larger (height AND width) on Windows so, as Vaughan suggests, give fields extra space.

ADDED: The reason you want a font standard on both platforms is so that, in FM's attempt to render, it doesn't substitute. It looks horrible most times.

Edited January 26, 2012 by LaRetta

[2ninerniner2]

OMG! You mean it's NOT Veranda?!?! LOL ( I had always thought that too! )

Helvetica seems to play well on both, but as LaRetta says, Verdana is what most use, myself included. I also design on Windows, but one still has to check on the Mac, especially for descenders and overall width; looks fine and dandy on Windows, but can be cut off on the bottom and/or ends on the Mac.

[Buckie]

Hi fine folks! Well, the porch font isn't going to be a solution because it's rendered just exactly the same way as Arial - fake bold and italic on a Mac unless you select the proper one and just one name on Windows with those styling buttons. The problem here is that people want to print their text forms that for some reason have all been italicized throughout and do that both on a Mac and on Windows. And actually the small differences between platforms such as font width and height don't bother me that much, it's the crazy italics effect that the Macs do.

Wow! But there is a solution though (occurred to me while typing) - have two separate sets of forms for Windows and Macs?

[Buckie]

Another solution could probably be repackaging the existing fonts to make them separate families on Windows. Such as Arial 1 instead of Arial, Arial 2 instead of Arial Italic and so on. And then install those on Macs...

[2ninerniner2]

I guess I am not getting what the issue is that you are having. The reports and screen layouts that I design on Windows, look and print just fine on the Mac, bold, italics and all

One project I am working on now has a mix of Arial, Helvetica and Verdana; same thing; look and print fine on either platform. I am not clear on what you mean by "fake" bold and italic.

[jbante]

You may be able to get the optimized styling you want in both platforms with conditional formatting. Have one condition testing for Mac that specifies using the separate Bold/Italic font, and another condition testing for Windows that specifies adding a Bold/Italic style.

[Buckie]

Allow me to illustrate...

Conditional formatting is out of the question since it would mean breaking a large text field full of data into a lot of smaller chunks, that'd be a nightmare.

[comment]

Are you talking about styles applied by the users to portions of text in a text field?

[Rick Whitelaw]

It seems to me that to benefit from the advantages of each platform, it would be best to Get the system platform and direct to the appropriate layout. That way fonts and sizing are basically optimized. I know so little about Windows that I would force the solution to quit on a Windows platform. Luckily I am NOT A commercial developer! My point is nothing should be left to chance or uncertainty. Another example: when FM introduced layout based merge fields in version 11 I used the feature all over the place. It looks terrible on versions before 11, so in the one solution I developed, I don't allow it to run on lower than 11. I know there are other ways of dealing with this, but I see little point. If I had a client base with a huge number of FM 9 and 10 installations I'm certain I would feel otherwise.

RW.

[Vaughan]

When I was new to FM, I thought it was called 'veranda', LOL, which is a porch.

Many people refer to a font called "Ariel". Ariel is the Little Mermaid, the font is Arial.

[Buckie]

comment,

yes I'm talking about exactly that. The methods for styling text are different on different platforms which leads to cross-platform issues. Trying to think of ways to overcome this limitation somehow.

[comment]

Ariel is the Little Mermaid,

Yeah, right.

[comment]

The methods for styling text are different on different platforms

Ahm... that's not quite correct, IMHO. The methods for styling are - at least should be - the same; the results may differ according to the platform and - no less importantly - the application.

On both platforms, If you want a word to be bold, you should select 'Bold' as the style. If you select a bold variant of the font instead, the result is that the word is now marked with a font attribute at the data level. To see what I mean, place two instances of the field on the layout and set them to display in a different font each. Then set one word to 'Bold' and another to a bold variant of the font.

Ideally, applying a 'Bold' style should be rendered by applying a bold variant of the font, if one exists, or by 'faux bold' otherwise. The TextEdit application, for example, goes as far as to not allow bold or italic at all if the selected font doesn't have them. Unfortunately, Filemaker goes to the other extreme and applies 'faux bold' as the default.

In any case, it's worth remembering that Filemaker is not a page layout program. If you want high-quality output, sharpen your exporting skills...

[Vaughan]

comment,

yes I'm talking about exactly that. The methods for styling text are different on different platforms which leads to cross-platform issues. Trying to think of ways to overcome this limitation somehow.

I've been developing cross-platform databases with FMP for over a decade and as long as fonts and their cross-platform rendering differences are understood, it all just works.

Creating separate layouts for each platform is uneconomical, un-mintainable and unnecessary.

[Buckie]

Vaughan,

Great! So would you care to share the steps to be taken to alleviate the problem I described?

comment,

FileMaker is not a page layout program, that's a sound advice of course, because it's a fact. I don't think however that asking it to display font styles in a consistent manner is asking too much. If anything I fail to see the reason behind FileMaker's choices in this regard.

[Vaughan]

I did, in the second post.

[Buckie]

Vaughan,

but it doesn't matter what side I'm doing the design on! My problem is not that the fonts are bigger or wider or shorter, the problem is in the styles. Like I said, text blocks with "i" and "b" buttons applied to them in Windows render as faux italic and bold on the Mac side whilst on Windows they're rendered with proper separate typefaces. This is unacceptable for me since I need to print out those forms from both Mac and Windows and the differences are very noticeable. Much more so than if the fonts had a slightly different width or height which would simply break lines in different places, at worst. I'm not asking for pixel-perfect rendering, it's just that fake italic effect (and fake bold, to a lesser degree) is very ugly and apparent.

[comment]

Like I said, text blocks with "i" and "b" buttons applied to them in Windows render as faux italic and bold on the Mac side

I thought you said they were portions of a text field, not text blocks. Why would a form have "a large text field full of data" with some portion being bold or italic? You also didn't say this was about printing. Please pinpoint you issue, so a suitable solution can be found (and I assure you a solution will be found - though I am not willing to guarantee it will be an easy one).

[Buckie]

Sorry I wasn't specific enough. Yes this is for printing out and the layouts in question contain agreement forms - basically a lot of text with the occasional merge field here and there (could be anywhere in the text). It's several pages of text with bullet points and number lists. The person who originally designed the forms in Word insists on having them styled exactly the same. For example a person's name in that agreement could be bold and the price information could be in italics. This is unfortunately non-negotiable otherwise I'd have happily got rid of all this style jockeying a long time ago. The end result of this is a piece of paper but also sometimes a pdf file. So it's not about the user interface at all, sorry again I wasn't clear enough.

[comment]

Well, one thing that immediately comes to mind is using a calculation (field or variable) to assemble the printed text, instead of merging. This way you can control what happens to each element on each platform, for example:

Let ( [

macName = TextFont ( Name ; "Arial Bold" ) ;

winName =  TextStyleAdd ( Name ; bold ) ;

printName = Case ( Abs ( Get ( SystemPlatform ) ) = 1 ; macName ; winName )

] ;

"... and between " & printName & ", hereinafter "Applicant"... "

)

[Buckie]

Soo... it means replacing the graphical text field design with programmatic approach, leaving only a single field/variable on a layout? That is more or less doable. And even if there's an operator (user) without admin privileges in theory I could break the whole thing down into editable blocks of text that would get reassembled upon printing (just in case that operator needs to enter a correction into the static block of text that is not inside a merge field). Am I on the right path here? All this almost leads to the idea of re-implementing the styling in a separate solution, somehow. Like, for example, entering text with a markup, , and so on which would then be analyzed and implemented correctly according to the platform. What do you think? Any other ideas?

[comment]

I think each problem has its own solution. If I needed something more generic, I'd look at automating the workflow of exporting the data into a better-suited tool, for example a page layout program.

[Buckie]

Well, there's a lot of work for just printing a single agreement on Macs and Windows. My situation is complicated by users's desire to create their own layouts based on the existing ones and it'd take a lot of effort to educate them how to do that properly. Anyway, do you think that creating separate font families and subsequently distributing those to each client is a good idea? We have, suppose, plain Arial, and then maybe take Arial Italic and repurpose it to become "Arial 2", then do the same with bold "Arial 3" and so on. Then just use those for styling? This way FileMaker in Windows will behave just like FileMaker on a Mac. I was unsuccessful with it though for some reason, don't know how to wrangle fonts well enough - had it done and the font installed but FileMaker didn't list it.

[comment]

My situation is complicated by users's desire to create their own layouts

Yes, that would be a different situation, calling for a different solution. Perhaps they should create the templates in Word and populate them by using merge files exported from Filemaker, or by using a plugin like 360Works Scribe.

[Vaughan]

It is not possible to make the output from Mac and Windows render exactly the same if the OS native rendering engines are used. Applications that require accuracy (such as DTP) use their own rendering engines.

A 4 year old article, but still interesting:

http://fplanque.com/dev/computers/mac-os-vs-windows-font-rendering

[comment]

I believe the main issue here is that Filemaker does not take full advantage of the Mac OS X native rendering engine. A well-behaved OS X application does not have its own font selection menu; instead, there is a "Show Fonts" menu item that invokes a system-wide font-selection window (similar to choosing a color by the system-wide color picker).

[Buckie]

Yeah, I remember reading that explanation (print-centric vs display-centric rendering intents) some time ago...

Actually I was somewhat successful with fonts, finally managed to change the family name (Arial Italic became something else with 'regular' style instead of 'italic' to confuse FileMaker). However there is something wrong with conversion exporting because even despite changing just the family name the exported font is not the same height as the original one. Still, those two look have acceptably similar proportions on both platforms (as they probably should anyway).

There seems to be a lot of legacy stuff in FileMaker's code. I wonder if they ever dare to rewrite it all. Could be a very huge task.

[Vaughan]

However there is something wrong with conversion exporting because even despite changing just the family name the exported font is not the same height as the original one.

Exported data has NO formatting: it's plain text. The application you're using to view the data is applying its own formatting. No control from FMP.

Assuming you mean "exported" using the Export Records command.

[Buckie]

Vaughan, sorry for the confusion again, I was talking about the font that I exported after changing its name in a font editor. The idea is to fool the FileMaker in Windows into working the same way with font selector as the Mac version. So even despite not changing a thing other than the name of the font, the exported result was different from the original.

[comment]

The idea is to fool the FileMaker in Windows into working the same way with font selector as the Mac version.

What a horrible hack - especially considering it is the Mac version that doesn't behave correctly.

If you are wiling to put so much into it, perhaps you should consider going over the text (on the Mac side) and changing every bold-styled span to a font-styled span, etc. using the result of GetAsCSS() as your "map". See something roughly similar here:

http://www.briandunning.com/cf/203

[Vaughan]

I have no idea what all this has been about. Much ado about nothing.

[comment]

Ahm ... if you have no idea what all this has been about, how do you know it's about nothing?

[comment]

Buckie, here is another tidbit for you: on the Mac platform, if instead of printing directly you save the records as PDF, the faux bold and italic will be substituted by the appropriate font variants and rendered correctly. The attached PDF has two pages: the first page was "printed" using OS X native 'Print to PDF'; the second page was generated using Filemaker's 'Save Records as PDF' command.

Print&Append.pdf