Selecting fonts and choosing colours - Steve Mumford looks at the considerations

Last time round I looked at the overall structure our label printing application might take, and we came across certain areas that would require further investigation during the course of coding. These included creating font and colour selection menus, advanced drag and drop code for use in saving files, moving and resizing objects, optimised redrawing routines and direct memory transfer. This month I intend to cover different methods of selecting fonts and colours, as well as revising a little menu theory.

Before we start, let's think about how flexible our selection routines need to be, and check to see how other common programs perform these tasks. Firstly, it's necessary to make an estimate of what sort of demands these tools will be placed under, so that we can design them to provide the maximum amount of use without being overly complicated.

Because we're designing a label application rather than a heavy-duty graphics package, the colours menu can afford to be fairly simple - taking the Draw colour picker as an example, its CMYK and HSV options are too complex to be required in our application. However, we must still be able to pick a colour from the entire spectrum, so clicking on an appropriately coloured icon (a technique Paint used until the advent of 24-bit colour) will not be enough, and a method of using nudge buttons or slide bars to alter a colour will have to be employed.

The number of fonts installed on a system can vary greatly, so choosing a selection method is quite an interesting task. The accepted technique for most Acorn applications is to produce a hierarchical menu, drop-down or standalone, listing all the major font families with their available weights and styles in sub-menus off the main list. On the PC, it's pretty similar, and even the bloated Microsoft Word uses an almost identical method - the main difference is the fact that the most commonly-used fonts are entered in duplicate at the head of the alphabetical list, so that users with more fonts than sense can find their favourites quickly, without having to delve through the rest of the tree.

This is a problem that we might turn our attention to; I'm sure we've all been in the position where we've known just what style of font was required, but couldn't remember the name of it. A method of combining the ease of picking a font from a list with the convenience of previewing the results before applying that selection would save a useful amount of time.

Luckily, RISC OS provides us with two SWI commands that semi-automate the process of scanning the font paths and building the family lists - these are Font_ListFonts and Font_DecodeMenu. The first SWI serves a double purpose, and is capable of producing a low-level list of the faces known to the Font Manager as well as being able to create a pre-canned menu definition that can be passed straight onto Wimp_CreateMenu. The second SWI is used, as its name suggests, to translate a menu selection into a usable font name. Used together, these calls would allow us to provide the traditional style of font selection, as well as giving us the raw data we would require if we wanted to build a more radical selector.

Both the font and colour selection tools could be presented to the user in the form of a dialogue box, automatically created when the user calls up a menu over an object on screen. Dialogue boxes are maintained by the Wimp until another menu option is chosen or the box is explicitly closed; this behaviour is ideal for the tasks we have in mind since the user would then be able to preview the effect of several different options before committing the change to the document.

Using dialogue boxes in this way also means that the selection tools will always remain context-sensitive to the item they're supposed to be operating upon, although the disadvantage is that the operator has to call up a menu whenever he or she wishes to alter the characteristics of an object.

Another way of tackling the problem is to include the font and colour information in a toolbar that's docked with the main window - ArtWorks uses this facility to its advantage. Whenever a new object is selected the details are updated, and whenever any change is made in the toolbar, those alterations are applied to the associated object in the document. The main disadvantage of this technique is the amount of space the toolbar eats up in the editing window, especially when each object has many editable parameters.

These two methods should cover all of the situations we'll encounter, and will provide a good basis for any more advanced systems we implement in the future.