One effect of this is that there are a few library packages that handle changes to fonts automatically. Some programs use these packages to present font-friendly interfaces. However, taking code from one of these libraries to another is not always easy. Similarly, these libraries are not all in development or accessible, so bugs are often immortal. Additionally, these libraries often don't play well with the BeOS widgets. Also, they may not implement font sensitive versions of all BeOS widgets.

Out of the programs that don't use these libraries, there are a few that are font friendly or where font size is irrelevant or controlled by the application. The rest of the apps (seemingly the majority), just don't handle font changes at all. This includes some programs bundled with BeOS.

Font Size

The first font change problem that most people come across is font size. The default font prefs app will only allow sizes 9-12 for a system font. For some people this is too small. Possibly for others too big? Even with this small range though, problems crop up quickly. Changing the system font size to 12 will make text get cut off in many dialogs, such as the E-mail preferences application.

Ascendancy, descendancy

The characters in different fonts have different amounts of ascnedancy and descendancy, even at the same size. This can cause font characters to "run into" other GUI objects.

Finding a solution

I think that any solution is going to consist of a set of widgets that are font friendly. Possible options:

• New separate parallel widget heirarachy
  This option can be ruled out easily. Although we want to tweak the heirarchy at one point or another, there's no reason to do anything this drastic.
• A constructor time option
  This option is a pretty good one from a developer perspective. Developers can use the old widget behavior if they want it, and use the new widget behavior otherwise. There is a question of which is the default. :-)
• Just do it
  This option is perhaps most optimal from the user perspective. Every application is font compliant. However, applications that don't take this into account could function poorly. (widgets growing into strange places, etc.)

With any option it is likely that there will be more than local changes required. That is to say, a widget might reasonably make it's height the font height, but if it makes itself wider at the same time, the dialog it is in may not be able to contain it. If it is not scrollable, the widget will grow off the edge of the dialog. This is usually handled in one of two ways, decidable at implementation: 1. the dialog is allowed to grow. 2. the dialog informs the widget that it is constrained and can not grow. How exactly the negotation of constraints is done is a matter of more complexity.

The above paragraph is just a taste of the complex issues that are wrapped up in doing this well. Java tried very hard to do this "right" with it's layout managers but a lot of people are generally unhappy with what happened there. I hope that we can come up with a "Be" solution that will integrate well with the existing framework and not be overly burdensome to either our developers or our processors. :-)

Current Libraries

liblayout - used by SoundPlay and many other BeOS applications

Santa's gift bag - used by BeShare and many other BeOS applications

ArpCommon - Yet Another Layout Library