Almost every application will need to display text of some kind on the screen. The basic techniques for displaying text are well-known, and MHP and OCAP applications can use the standard Java methods for drawing a string.
Displaying text on a TV, however, requires thinking about a number of issues that we can avoid on a PC platform. For this reason, MHP and OCAP offer some advanced features for text presentation that address some of the technical issues unique to a TV-based platform. Other issues are more design-oriented, and the application developer and designer have to take care of these when designing the application. We will examine both sets of issues in this tutorial, and offer some techniques for solving the problems that arise.
This is not a tutorial about presenting one or two words of text in a label – that is straightforward enough that any developer can work out how to do it. Instead, this tutorial is aimed at developers who need to display more than a couple of sentences of text in their application. MHP has a few tools to help do this, but these are not always as advanced as they should be and many applications will have to be tested on more than one receiver to make sure that the text is displayed correctly.
There are three major problems we face when displaying large amounts of text in an application. The first of these is the basic problem that reading text on a TV screen is difficult – TV displays typically have low resolution and low contrast, which makes text harder to read from a typical TV viewing distance. Choosing the right font is part of the answer to this problem, which is why both MHP and OCAP specify that the Tiresias font is the standard font used in receivers. This was specifically designed for readability on a TV screen, and will be much more legible than other fonts (although some people do not think very highly of Tiresias as a screen font, it is the best we currently have). Font sizes also play their part: since text is viewed from much further away, and the resolution is much lower, the recommended font size for text on a TV screen is much higher than for PC applications. Each pixel in a TV screen is treated as one point, so 18-point text will take up 18 lines on the screen. Because of the low resolution and poor contrast of a typical TV, this is really the smallest text that should be used in an application. These factors all affect the amount of text that can be fit on the screen at once, and in general they all tend to reduce the amount of text that we can use.
This brings us on to the second problem: navigation. If a piece of text is too long to fit on screen (or in the area of screen that is available to it), the user will need some way of moving around the text. While scrollbars work well on a PC where the user has a mouse to control the scrolling, this is not a good choice for a digital TV application. ‘Jump scrolling’ or paging through the text is a much better solution that is easier to navigate with a remote control. Vertical scrolling is not too bad, but the need for horizontal scrolling should be avoided at all costs. Care should also be taken to make sure that the method for navigating around a long piece of text does not clash with the method for navigating around the rest of the application. These are all issues that a UI designer has to consider when they are working on a digital TV application, and which are issues that they would not face in the PC world.
Text layout issues
So far, we have seen the high-level issues that face people designing a user interface. Things don’t get much easier when we start to implement that UI, either. Even presenting a simple piece of text offers a number of choices to the developer: how should the text be aligned? What margins should be applied? What happens if the text is too big for the area we have assigned it? If an application uses the usual Java methods for drawing strings (the drawString(), drawChars(), and drawBytes() methods in java.awt.Graphics), the application is responsible for managing all of these details. It’s up to the application to check if the string is too wide and to split it across multiple lines, and to work out where to split the text. It’s up to the application to manage the line spacing, and to take care of every other aspect of rendering a piece of text. This is called low level text rendering in MHP and OCAP.
As you can imagine, taking care of all these issues is complex work if we have a large piece of text. HAVi gave developers a partial solution to this problem with the HTextLayoutManager. This class will automatically lay out a piece of text, making sure that it does not overflow the boundaries of the area it has been assigned. If the text is too big for this area, then the text will be truncated and an ellipsis (‘…’) will indicate that the text has been shortened. In the most simple text layout manager, the HDefaultTextLayoutManager, the application can define a set of insets that will be applied to the allocated area and which will act as margins for the text.
Any HVisible object can have a text layout manager associated with it, and this can be set using the HVisible.setTextLayoutManager() method. Similarly, the getTextLayoutManager() method will return the text layout manager that is currently in use by the HVisible, or a null reference if no text layout manager is set. In most cases, a text layout manager will be used with an HText or HStaticText object, and an instance of a text layout manager can be passed as an argument to the constructor for those objects.
Text layout managers take a piece of marked up text as their input, although HAVi does not define which markup sequences can be used. Multi-line text is supported, in which case each line must be separated by a newline character (0x0A).
DVB took the functionality of text layout managers one step further with the org.dvb.ui.DVBTextLayoutManager class. This extends the HTextlayoutManager to provide some additional layout rules, allowing the application to control a number of other layout factors. These include the orientation of the text, horizontal and vertical alignment, and the starting corner for the text. Using these extra rules gives applications a little extra flexibility in laying out text, and so most applications will probably use a DVBTextLayoutManager instead of the default HAVi text layout manager. The example below shows one way of using a DVBTextLayoutManager with an HText object:
java.lang.String myString; org.havi.ui.HText myText; org.dvb.ui.DVBTextLayoutManager mgr; // The string that we want to display myString = "This is some text. It's a fairly long " + "piece of text that should show word wrapping on most " + "receivers.\nMultiple lines of text are supported " + "by the text layout manager if them are separated " + "by a \\n", // Set the font that we will use; in this case, we use the // standard Tiresias font. myFont = new java.awt.Font( "Tiresias", java.awt.Font.PLAIN, 18); // Create a new text layout manager mgr = new org.dvb.ui.DVBTextLayoutManager(); // Set some parameters on the text layout manager to control // how the test is displayed. mgr.setLineSpacing(23); mgr.setHorizontalAlign( org.dvb.ui.DVBTextLayoutManager.HORIZONTAL_CENTER); mgr.setVerticalAlign( org.dvb.ui.DVBTextLayoutManager.VERTICAL_CENTER); // Create an HText object, setting the font, foreground // and background colours, and the layout manager myString = new HText( myFont, java.awt.Color.white, java.awt.Color.blue, mgr); // Tell the HText object where it should be placed. The // text layout manager will automatically make sure that // the text stays within these bounds, truncating it if // necessary. myText.setBounds(10, 10, 400, 300);
Using a text layout manager to render text is known as high level text rendering in MHP and OCAP. There are no significant differences in the process of text layout between high level rendering and low level rendering, except that in high level rendering, text layout managers hide all of the complexity involved in rendering the text. High-level rendering is less flexible in some ways (e.g. the line spacing for the entire block of text will be the same), but this is unlikely to be a problem in most applications and high-level rendering is usually the best choice for displaying more than couple of words of text.
Text layout managers have a number of limitations. The first of these is implied in their name – they lay out a piece of text, but offer no other way of formatting it. HAVi assumes that formatting will be carried out by markup in the text, and they give a few examples of the types of formatting that could be supported, but they do not actually define this markup. MHP defines one escape sequence for changing the text colour. This sequence has the format
0x1B 0x43 0x04 0xrr 0xgg 0xbb 0xtt
where rr, gg, bb, and tt are the (hexadecimal) values for the R, G, B and transparency components of the colour to be used. The end of the coloured text is indicated by the escape sequence 0x1B 0x63. These escape sequences can be nested, to allow a section of text in one colour to be easily embedded in text of a different colour. Changing the colour is all that an application developer can do with escape sequences, however. If you want a different font size (or even a different style such as bold or italic), you need to draw that as a separate piece of text. This makes it hard to mix these styles in a single piece of text, and the only way to do this is to carefully hand-code the routines for drawing that piece of text.
Alternative text layout solutions
While the text layout manager may be enough for many purposes, it does not always offer the flexibility that an application may need. Many information services will want to store their content in data files that are separate from the application. A news application, for instance, will usually want to store the contents of the news stories in text files that can be entered by data entry staff rather than by Java developers. In many cases, this will be more than plain text – things like headings and some simple formatting may need to be stored as well. While developers could define a custom format for these files and then parse it into the application, a simpler way would be to use a markup scheme that already exists.
HTML is very well-known and can be used to mark up text for this kind of purpose very easily. The problem is that many MHP receivers do not support HTML. Luckily this is not as big a problem as it may first appear: many companies sell HTML rendering components or HTML browsers written in Java, and these can be incorporated into an MHP application relatively easily. Several network operators already use this approach for their Teletext services, and it works pretty well. Downloading a simple HTML browser or renderer is not significantly more difficult than downloading any other application, and the advantages far outweigh any problems. Using HTML or XML can give applications far more flexibility than other approaches, although it does make the application more complex. For most information services, however, the content will change for more often than the application, and so it makes sense to spend more time on developing the application if it saves time on updating the content.
Fonts
Every MHP and OCAP receiver will use the Tiresias font unless the application specifically sets another font for a piece of text. You may think that this means a piece of text would display the same on every receiver, assuming the same amount if space is allocated to it. This is a reasonable assumption, but unfortunately not a correct one: even though the font is the same, the font metrics (e.g. spacing between letters or lines, the height of a line, and other similar parameters) may not be the same. This means that different receivers will display text slightly differently, with some receivers fitting more text into the same area of screen. The screenshots below will give you some idea of the effect that this will have on your application.
As a result of this, text may fit inside the area allocated to it on once receiver, but overflow that area on another. There is currently no way of compensating for this with the Tiresias font, and the use of layout managers will not fix the problem. This means that applications which display a lot of text should take care to make sure that they can handle the case where text overflows the area assigned to it, and this may in turn mean testing your application on several different brands of receiver with different middleware implementations. The examples below show the effect of this in practice, on three different MHP implementations:
Examples of how different metrics for built-in fonts can affect text layout with text layout managers
As you can see, the line height in the last two examples is significantly higher than in the first, making less text visible on the screen. In the third example, this is even more obvious because of the way that text flows around the image.
More examples of this, including details of the font metrics, are shown on a separate page.
The only solution is to download a custom font as part of the application, which will have the same font metrics on every platform. The disadvantage of this approach is the extra time and complexity needed to load the font, as well as licensing issues related to the font. Even fonts such as Arial are not free for use in DTV applications, and developers should take care to license any custom fonts that they want to download to an MHP receiver.
Another issue facing middleware implementers is the task of mapping a font (which is often described in high-resolution units that are independent of the display device) into pixels on the screen. We won’t go into this here, but annex D of the MHP specification gives details of how this mapping should be carried out.
Aspect ratios
As if things were not complicated enough, we have to remember that an application may be displayed on displays which have an aspect ratio of 16:9 as well as on a standard 4:3 display. This is really only a minor inconvenience for most graphics issues – the images may appear stretched or squashed (depending on the original aspect ratio), but that is all. For text, this can be a much bigger problem. As we saw in the graphics tutorial, each display consists of three different sets of screen devices – a background device, one or more video devices and one or more graphics devices. The pixel aspect ratio of the graphics device will be different depending on the aspect ratio of the graphics device, and this in turn will affect how the receiver maps a font on to real pixels in the display. For a graphics device with an aspect ratio of 4:3, each pixel will be 48/45 points wide. For a graphics device with an aspect ratio of 16:9, each pixel will be 64/45 points wide. The result of this is that on a 16:9 display, a character will take up fewer pixels on the screen.
Since the bounding box for a piece of text is typically measured in pixels when we define our user interface, this causes problems since we can’t be sure how many pixels the text will take up. One solution is do design for the wider of the two cases, but this may not be the best approach for all cases. Luckily, we have an alternative approach. Each MHP receiver must support an emulated graphics configuration with an aspect ratio of 14:9. While this means that images and text will be distorted slightly on both 4:3 and 16:9 displays, it also means that text is guaranteed to take up the same number of pixels on the screen regardless of the aspect ratio of the picture. On a 4:3 display, the text will appear slightly condensed, while on a 16:9 display it will appear slightly extended, but in both cases the distortion is fairly small.
Using this aspect ratio does have its problems (most notably, it’s harder to perfectly align video and graphics), but for applications where text is a major part of the user interface, this may solve a number of problems.