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?

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.

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, 201214 yr by LaRetta

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.

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?

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...

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.

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.

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.

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

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.

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.

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.

Ariel is the Little Mermaid,

Yeah, right.

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...

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.

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.

I did, in the second post.

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.

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).

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.

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"... "

)

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?

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.

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.

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.

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

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).

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.

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.

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.

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

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

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

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

Vaughan, I don't know if you're referring to my posts or not, but I'll respond anyhow. My database solution is working just fine now save for this fonts issue. And the problem is that I'm not the one to call the shots on the form design. The person who designed those awesome agreement forms with a multitude of font styles won't budge, they want it styled that way, end of story. They also want to make edits without much effort, perhaps to add even more style! So unfortunately that's how it is.

comment,

thanks for the getascss tip! It feels like a better solution than doing it with hacked fonts.

I started by trying to extract the data from that large block of text on a layout by using GetLayoutObjectAttribute. I use it like this in a calculation field: GetLayoutObjectAttribute ( "mybox" , "content" ) to which I get "This number cannot be evaluated." The sample syntax for that Get is confusing - some examples list a semicolon and other just a comma. I get the error with the comma but with the semicolon there's neither an error nor any result. I've tried other attributes, such as "bounds" and still get an empty field. Possibly missing something obvious? I did name the object in the Inspector in the 'Position' tab.

comment,

wow! indeed it does work that way! That is totally weird! So it seems like a good way to do it, just need to add some AppleScript to print the result and delete the file afterwards. Nice!

The default separator between function separators is semi-colon, but it may change if your application is localized. If in doubt, select the function from the top right corner - it will be inserted in the correct prototype. Make sure the result is set to Text (and you probably should make it unstored).

just need to add some AppleScript to print the result and delete the file afterwards.

If you save it in the temp folder, you don't even need to delete it.

Yes, it was a d'oh moment - the calculation wasn't unstored. Let's see if I can come up with a working AppleScript now... But actually I do like the GetAsCSS approach too.

actually I do like the GetAsCSS approach too.

LOL, it would make a great summer project. The AppleScript, OTOH, should take about 15 minutes including testing...

Oh yeah. I kinda forgot that there's no SETwithCSS. So you're right.

It was a surprisingly simple task. Can anyone test it for me as I have no printer right now?

The script is like this:

Save Records as PDF filemac:/Macintosh HD/tmp/printout.pdf

Perform AppleScript do shell script "lpr /tmp/printout.pdf"

And to finish this thread, yes, the method above works. It's best to find out the drive name beforehand, so...

Set Variable [$volumename; Value:Get ( SystemDrive )]

Save Records as PDF filemac:$volumename/tmp/printout.pdf

Perform AppleScript do shell script "lpr /tmp/printout.pdf"

There are various options you can pass to lpr, like duplex printing or rear tray printing.

You can find out all the options for your printer by typing

lpoptions -l

in the terminal and then look for pairs that look like

Printer's Specific Value/Human-readable description: *value1 value2 value3

Then you set Printer's Specific Values using lpr's -o flag like so

lpr -o EPIJ_FdSo=0 -o Another_option=2 file_name_to_print

with the first being a string telling Epson B-300 printer to source paper from its rear tray.

Thanks a lot to comment for helping me with this one and everyone else who contributed!!

Thanks to everybody who contributed in this thread, really helped me a lot :)

We solved this problem in the typesetting/printing industry long ago. The problem is most screen fonts didn't match the printer fonts. In FMP the problem is the Mac screen font doesn't match the Windows screen font.

We started off by only guaranteeing output using Adobe postscript fonts. The final solution the industry adopted was to embed the fonts in the documents. Adobe came up with this and it works great.

Perhaps we could ask FM to start embedding fonts in our solutions.

The historical reasons are based on the industry's adoption of Adobe postscript as the standard page description language. Countless millions of dollars were invested in postscript raster image processors and film output devices. But Microsoft refused to license Adobe and Mac postscript took 99.9% of the desktop publishing market. Microsoft finally adopted TrueType (licensed from Apple) but in usual Microsoft fashion they munged it a bit so it doesn't match Apple's TrueType.

If you use the same TrueType font on both platforms they match. Asking a client to install a font is no good, so embedding became the answer for cross-platform font matching.

The simple workaround for now is to design on the PC and use Verdana. This cripples fontography severely but it's all we have until we get embedded fonts.

HTML5 and CSS3 call for embedded fonts for web pages. Designers were ecstatic at the new standard. The problem now is to get all the browser designers to agree on a font technology, which they have bitterly warred over, so no satisfactory web solution has been achieved.

I'd suggest TrueType embedding for FMP since both platforms support it.

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

In theory, yes. but be sure to leave a bit of extra text box or you will see things like Tahoma on Mac cut off. I usually leave a character width or two.

It happens with Verdana and some others as well. But that is what Vaughan is saying ... If you design on Windows then the fields are large enough that displaying them on Mac show the entire font but if they are designed on Mac you must increase field height or they cut off.

And this is 'a few px' PER LINE. If a Mac person has a large text box then an entire last row of text (or more) can disappear on Windows.