Tips_todo   >   Misc   >   Fonts

Fonts

In Omnis Classic cross platform fonts were accomplished using the #WIRFONTS, #MARFONTS, and #WIRFONTS, #MAWFONTS tables. In Studio, Omnis introduced the #STYLES tables. #STYLES is a much better way system for handling cross platform fonts.

Using #STYLES allows you to effortlessly change an entire group of window or report fields throughout your library.

In this section I give advice on what I've learned about fonts and #STYLES while developing my own application.

#STYLES

The Omnis Studio help states that #STYLES supercedes #WIxFONTS, #MAxFONTS.
#STYLES is better because it not only allows you to specify different fonts for different platforms, but it also give you full control over font size, font style, etc.

Once a style is declared and used in your library, any text which is assigned $fieldstyle is mapped
to the row # in the #STYLES table, not the style name! If you change a style name in the table,
the style name of ALL the text in your library which is mapped to that row will immediately change its $fieldstyle name to match the #STYLES style name. (Try it, it's harmless to do, just be sure to change it back.)

If a text related object with a $fieldstyle is copied into your library, Omnis tries to match its
name to the existing styles in the #STYLES table, if it finds a match, the $fieldstyle is then mapped to that row. If it doesn't find a matching style, Omnis then automatically adds the new style to the next available line in the #STYLES table.

GOTCHA: If you don't have any styles in your library, your styles table will be built in the order that you drag components in. Example: You have empty #STYLES tables in Library A and B. In Libary A and you first drag in a button object, #STYLES row 1 will be OMNISbutton. In Library B you drag in an entry field first, row 1 will be OMNISfield. As you can see, that can get messy if you decide later decide you want the same #STYLES table in all your libraries and you drag a brand new styles table into your library.

If you drag #STYLES from Library A to Library B, the fieldstyles which were mapped to #STYLE row 1, will still be mapped to #STYLE row 1. The $fieldstyles in your library are mapped to the Row#, not the name.

COMPONENT STORE #STYLES

The Component store has a number of fieldstyles already set by Omnis. They are:

1. OMNISbutton - Standard Pushbutton - MS SansSerif 9 (Win) Geneva 10 (Mac)
2. OMNISlist - Standard List - MS SansSerif 9 (Win) Geneva 10 (Mac)
3. OMNISfield - Standard Field - MS SansSerif 9 (Win) Geneva 9 (Mac)
4. SansSerif9 - MS Sans Serif 9 (Win) Geneva 10 (Mac)
5. OMNISweb - Web Component - Arial 9 (Win) Geneva 9 (Mac)

I'm not sure why OMNISfield uses Geneva 9 for OMNISfield and Geneva 10 for the others. In my own styles table I've changed it to Geneva 10.

CREATING YOUR OWN #STYLES

I would strongly recommend that your own #STYLES table includes these 5 styles as the first 5 styles in the exact same order as in the Component Store. If you don't include them, they will be added automatically (randomly) to your #STYLES table as you drag new components from the Component Store into your library. (If you are starting your own #STYLES table you can drag the #STYLES table from the Component Store into your own library.)

You should think through and set up your #STYLES table very early in developing your application. Otherwise you'll be going back doing a lot of extra clean up work later on.

Don't use font names for your style names. Set up separate styles for windows and for reports. Fonts that work well for windows, don't necessarily work well for reports, so keep them separate.

You might want a specific style for titles in windows, another style for Company Name, another style for text in windows. For reports you might set up styles for Company Name, Title Subtitle, report text, Micro text, correspondence text... you get idea. To make style easy to recognize Window styles (other than the 3 Omnis styles) could be prefixed with lower case w, Report styles could be prefixed with lower case r. Don't get carried away and declare more styles than you need. Don't create too many styles that enforce colour or justification. (You'll have too many $fontstyles)

Suggested styles are:

Component Store #STYLES:
1. OMNISbutton - Standard Pushbutton (Mac:Geneva 10, Win:MS SansSerif 9)
2. OMNISlist - Standard List (Mac:Geneva 10, Win:MS SansSerif 9)
3. OMNISfield - Standard Field (Mac:Geneva 10, Win:MS SansSerif 9)
4. SansSerif9 - MS Sans Serif 9 (Win) Geneva 10 (Mac)
5. OMNISweb - Web Component (Mac:Geneva 9, Win:Arial 9)

Additional Styles:
6. OMNISlabel - Standard Labels (Mac:Geneva 10, Win:MS SansSerif 9)
7. wCompanyName - window text in the style that best suits the company
8. wTitle - normal window title text (Mac:Charcoal/Chigaco 12, Win:Arial 10)
9. wBIGTitle - very large titles text (Mac:Helvetica 20, Win:Arial 14)

Report Styles:
10. rText - regular report text (Mac/Win:Helvetica 10)
11. rMediumText - slightly smaller report text (Mac/Win:Helvetica 9)
12. rCorrespText - report text for correspondence (Mac/Win:Times New Roman 12)
13. rSmallText - report text for tiny header or footer text (Mac/Win:Helvetica 6)
14. rTitle - report text for report titles (Mac/Win:Helvetica 12 Bold)
15. rBIGTitle - report text for BIG titles (Mac/Win:Helvetica 18 Bold)
16. rSubtitle - report text for for the subtitles (Mac/Win:Helvetica 10)
17. rCompanyName - report text in the style that best suits the company (Mac/Win:Helvetica 12 Bold?)
18. rSpacer - RED report spacer (Red color makes spacer fields stand out on the report)
19. rMicroSpacer - RED report spacer (Mac/Win:Helvetica 3)

Note: I try to make each style name unique within the first few characters. That way when I open
the text $fieldstyle drop down menu in the property manager, I just have to type 'rsm' to go to 'rSmallText'.

By using styles, you can very quickly change the look of reports and windows in your entire application to suit different clients and applications.

To set up styles, press F2, Command/Ctrl+Shift+Y to show the system classes in your library, then double-click on the #STYLES class. The interface is intuitive and the Omnis documentation is clear, so I won't get into more detail.

See 'Cross Platform Fonts' for recommendations on what fonts to match between Mac and Wintel.

#WIRFONTS, #MARFONTS

If you haven't guessed already, these stand for Windows REPORT Fonts and Mac REPORT Fonts. These table are the way cross platform fonts were handled before Studio introduced #STYLES.

You can leave these tables empty if you are exclusively using #STYLES in your application. Removing all the fonts from these tables, will force you to use styles. Maybe a good way to discipline yourself to use styles. (If wish I did, it would have saved me a lot of rework)

IF YOU DON'T USE STYLES THEN READ ON.

If you don't use #STYLES, then you need to add fonts to these tables in order for them to show up in the 'font' property of report objects.

If you open a brand new library, Omnis shows the following report fonts in these tables:

1 - Mac:Monaco, Win:Arial
2 - Mac:Courier, Win:Courier New
3 - Mac:Helvetica, Win:Times New Roman
4 - Mac:Geneva, Win: MS Sans Serif
5 - Mac:Chicago, Win:Times

I can't say I'd consider all of these as good crossplatform matches.
Monaco and Arial?, Helvetica and Times? I would NOT recommend Geneva OR MS Sans Serif as report fonts.

Mac OS9 has matches for most of the standard wintel fonts, so the REPORT fonts table I might use:
1 - Mac:Helvetica, Win:Arial
2 - Mac:Courier New, Win:Courier New
3 - Mac:Times New Roman, Win:Times New Roman
4 - Mac:Palatino, Win:Palatino

I didn't have a broad range of printers to test this on, so let me know if you run into problems with the report fonts I've suggested.

If you don't assign styles to your report text, then this table is used for picking the 'other' font when your application is used on the 'other' platform. The weakness is that there is not fontsize control with these table, so the same fonts might print bigger from Wintel, than from Mac. #STYLES give you the added control of fontsize, plus color, etc.

Once you're happy with the font matching in this table, don't mess with it. The font properties in your library objects (except #STYLES) are mapped to the Row # in this table, so if you change Helvetica to Times, every text senstive object that doesn't have a style and used Helvetica will now be Times.

So take your time, experiment, and get the report fonts table set up the way you want it. Then don't mess with it. If you need to add fonts, add them to the bottom of the table.

BUT, I recommend you ignore these tables, and just go with #STYLES.

#WIWFONTS, #MAWFONTS

If you haven't guessed already, these stand for Windows WINDOW Fonts and Mac WINDOW Fonts. These table are the way cross platform fonts were handled before Studio introduced #STYLES.

Removing all the fonts from these tables, will force you to use styles. Maybe a good way to discipline yourself to use styles. (If wish I did, it would have saved me a lot of rework)

IF YOU DON'T USE STYLES THEN READ ON.

If you open a brand new library, Omnis shows the following window fonts in these tables:

1 - Mac:Monaco, Win:Arial
2 - Mac:Courier, Win:Courier New
3 - Mac:Helvetica, Win:Times New Roman
4 - Mac:Geneva, Win: MS Sans Serif
5 - Mac:Chicago, Win:System

I can't say I'd consider all of these as good crossplatform matches.
Monaco and Arial?, Helvetica and Times?

For my application pretty much the only screen font I use in my windows is Geneva.
So for the window fonts table you might keep it simple as follows:

1 - Mac:Geneva, Win: MS Sans Serif (for most screen text)
2 - Mac:Helvetica, Win:Arial (for titles)
3 - Mac:Charcoal, Win:System (for titles to look like the OS)
4 - Mac:Monaco, Win:Courier (for monospace text)

In Classic I used monospace text in lists, but in Studio I use Headed lists and set alignment, so Geneva/MS Sans Serif work great.

I 'm not a font expert, so let me know if have other suggestions.

If you don't assign styles to your window text, then this table is used for picking the 'other' font when your application is used on the 'other' platform. The weakness is that there is not fontsize control with these tables, so the same fonts might displayed differently.

Once you''re happy with the font matching in this table, don't mess with it. The fonts in your library are mapped to the Row # in this table, so if you change Geneva to Times, every text senstive object that doesn't have a style, and every style definition will be changed.

So take your time, experiment, and get the window fonts table set up the way you want it. Then don't mess with it. If you need to add fonts, add them to the bottom of the table.

BUT, I recommend you ignore these tables, and just go with #STYLES.

Cross Platform Fonts

You should read the #STYLES notes before reading this section. I make some recommendations on what fonts to use for cross-platform compatibility. This is not based on a lot of experience or testing, so use your own judgement, and test your results.

As mentioned in #STYLES, you should have separate styles for reports and windows, don't mix them.

WINDOW(SCREEN) STYLES

Omnis has some default styles for windows which work well.

OMNISbutton - Mac:Geneva 10, Win:MS Sans Serif 9 (bold)
OMNISfield - Mac:Geneva 9, Win:MS Sans Serif 9
OMNISlist - Mac:Geneva 10, Win:MS Sans Serif 9

I'm not sure why Mac:field is 9 and the others 10, you can change them anytime you like. In my application, I set them all to Geneva 10/MS Sans Serif 9. I also changed OMNISbutton to plain (non-bold) text.

You might consider the following styles for your windows

wBIGTitle - Mac:Helvetica 20, Win:Arial 14
wTitle - Mac:Charcoal 12, Win:Arial 10
wMonospace - Mac:Monaco 9, Win:Courier New 9 wCompanyName - whatever looks best for the particular company, will look the same everywhere.

You can set colors in your styles, but I found it made my styles list too long with too many choices, so I went back to keeping it simple, leaving colours to be changed in the window if needed.

REPORT STYLES

Omnis does not have default styles for report text objects in the Component Store. (v2.4)
Do NOT use Geneva or MS Sans Serif for report styles, in my testing they didn't work well.

Between my Mac G3 OS 9 Powerbook and Wintel Windows98 box I found the following decent report fonts to work on both platforms. Courier New, Helvetica, Palatino, Times New Roman. I was printing to Apple and HP laserprinters.

Arial seems to be the Wintel standard sans serif report font, Helvetica for the Mac. You can't go too far wrong with those fonts.

I had an Apple Laserwriter 16/600 and and HP DeskJet 4MV laser printer (postscript) for testing and was printing to them from a Mac OS9 and a Wintel Win98 box. In my situation I found that Helvetica was on both platforms and was on the printers, so I got best results using the same size Helvetica on both platform. Your might experience different. I would appreciate hearing your results on what works and doesn't work at your installations

The only problem I have is that the Wintel reports use less vertical space per line on the page than the Mac reports. (except in kExtendingJst fields) I also found that picture fields print shorter vertically on the Wintel than the Mac.

See #STYLES for the report styles font recommendations.

By using a separate style for Company Name, you can change the font/size for rCompanyName to suit individual companies, and every report will have the Company name in the font/size preferred by that client. Same goes for the other styles. If you stick with them, you can change every report in the click of a mouse.