UEFI HII (Part 10): Images

Before starting, you should be aware that the term 'image' has two different meanings in UEFI. First, it refers to executables (EXE), such as drivers and applications, that get loaded into memory by the LoadImage() and StartImage() services. Second, it refers to rectangular, full-color images.

Support for these images started with the UEFI 2.0 specification, with the EFI_GRAPHICS_OUTPUT_PROTOCOL. This protocol provide device-independent services for moving bitmapped images back and forth from a video device. But, it provided no standard means for finding and managing these images.

Then the UEFI 2.1 specification introduced the HII Database. Each driver can install pre-packaged images into the database. Then the driver can manipulate or display them using the EFI_HII_IMAGE_PROTOCOL.

Image Attributes
Images have the following attributes:

• Identifier. Along with the database handle, this identifier uniquely specifies the image.
• Width. The number of pixels per image row.
• Height. The number of image rows.
• Transparent. Indicates whether the pure black pixels (RGB(0,0,0)) will be drawn transparently over the background.
• Bitmap. Image pixels are organized left-to-right and then top-to-bottom. Each image pixel consists of 32-bits. The first 8-bits in each pixel are the blue (0 = off, 255 = on), the next 8-bits are the green and the next 8-bits are the blue.

Image Services

The UEFI HII Image protocol provides two classes of services:  

1. 
   
   Get/Set. You can get an image from the HII database, change an image in the HII database and add a new image to the HII database.
2. 
   
   Draw. You can draw an image, either using an image identifier or from a raw bitmapped image. In both cases, the drawing can be done directly to the screen or into another image, with or without clipping.

Conclusion

Images are slowly being integrated into firmware as an integral part, simply because of user expectations and a desire for OEMs to stand out in a crowd. UEFI 2.1 provides built-in support for basic image manipulation services. UEFI 2.3 also added support for animations. In our next article, we will look at how UEFI stores different types of images in the HII packages.

UEFI HII (Part 9): Font Package Encoding

Ok, now into the gory details of how font packages are encoded. In many ways, font packages are like string packages except, instead of strings, we are talking about font glyphs. There is a font header, followed by font information and then a series of font blocks.

The glyph blocks represent the glyphs in sorted order, starting with the glyph for character value 0x0001 and incrementing from there. Each glyph block increments the character value by either 1 or N. There are five basic types of glyph blocks:

1. Glyphs. These actually contain glyph data. There are variants for a single glyph or multiple glyphs, ones which use default character cell information or their own character cell information. The current character value is incremented by either 1 (for single glyph versions) or N (for multiple glyph versions).
2. Duplicate. This block duplicates the glyph data for a character value that has already been processed.  The current character value is incremented by 1.
3. Skip. These blocks skip a specified number of character values. For example, there might be no glyphs for character values 0x2000-0x20FF, but then one more glyph for character value 0x2100. A Skip block leaves a gap. The current character value is incremented by the skip count specified.
4. Defaults. This block sets up the default character cell information for the subsequent glyph blocks which use defaults. This is useful for fonts where a lot of characters share a specific set of information, such as Courier or other fixed-format fonts.
5. End. This marks the end of the glyph block information.

The actual glyph data is packed with one bit per pixel of the glyph, but rows are rounded up to the nearest byte (8 pixel) boundary. For example, consider the letter 'A'.

In this case, the actual glyph data is 9 pixels wide and 11 pixels high. If optimally packed, this would lead to a storage size of 99 bits or 13 bytes (12 with 3 bits left over). However, when this was being discussed, some preliminary implementation data suggested that the glyphs were much easier to handle if each row was byte aligned (the blue shaded area in the diagram). Then, after testing with compression software (since we assumed that the fonts would be stored compressed) that the bit-packed data actually was larger after compression than the byte-packed data.

Conclusion

This wraps up the second on fonts. Next week, we'll dive into how HII stores and handles images.

Harnessing The UEFI Shell

Just a quick plug to note that a book co-authored by myself and three Intel engineers (Mike Rothman, Bob Hale and Vincent Zimmer) is finally available for sale via Amazon or through Intel Press. UPS says that my personal copy arrives next Wednesday. Yeah!

UEFI HII (Part 8): Proportional Fonts

The UEFI Specification provids services and storage for manipulating bitmap fonts as part of the Human Interface Infrastructure (HII). Last week, we looked at the Simple Font, which describes a means of storing a fixed-width font for Unicode character values. Each character in the Simple Font is either in an 8 x 19 (narrow) pixel or 16 x 19 (wide) pixel character cell.

Proportional fonts extend bitmapped font support in several significant ways:

1. There can be multiple fonts, each described by its name, height and style (bold, italics, underline, etc.).
2. Each character cell in the font can be a different width.

Fonts
So, for UEFI, a font is a logical grouping of glyphs identified by a name, a size and a style.

• Font Name. "The font name describes, in broad terms, the visual style of the font." How do you tell that a character is part of the Arial font? Or Times New Roman? Well, they tend to share certain visual characteristics, such as whether they have serifs, or whether they are rounded or angular or represent alphabetic characters or symbols. 
• Font Size. "The font size describes the maximum height of the character cell, in pixels. The standard font always has the font size of 19." Rather than describing characters in terms of "points", the UEFI specification describes them in terms of the height of the character cell, in pixels. The UEFI specification does not use points, because (a) it only uses bitmapped fonts and (b) although points technically refers to 1/72nd of an inch, it actually does little to describe how much screen space a font will take up (except in comparison with another point size for the same font).
• Font Style. "The font style describes standard visual modifies to the base visual style of a font." In other words, you can have Arial, Arial + Bold, Arial + Italic, Arial + Bold and Italic, etc. They are still an Arial font, but they have additional stylistic modifiers. The UEFI specification explicitly supports bold, italic, underline, double-underline, embossed, outline and shadowed.

Glyphs
The glyph is the image representation of the character, with each dot in the image represented by a single bit, on or off. The off pixels are either not drawn (for transparent drawing) or else drawn in the background color. The on pixels are drawn in the foreground color. For example, for the letter A, it might look like this:

But this isn't enough information to draw the glyph. For one thing, we don't know how much space to leave between this glyph and other glyphs that we have drawn. This is one of the key differences between this font and the simple font in the previous articles. Simple fonts have the empty space above, below, before and after the character image built into the glyph. Proportional fonts track this sort of information separately, using three key ideas:

1. The character cell.
2. The baseline.
3. The character advance.

Character Cell

The character cell is a box that the glyph's image is positioned inside of. Each font has a character cell and each character glyph's image is placed relative to the top-left corner of that cell, or box. For example:

Baseline
The baseline (or Offset Y) allows UEFI firmware to draw text from different fonts on the same line and still have everything line up correctly. The baseline is calculated as the number of pixels above the Origin of the tallest character image.

 

In this picture, the baseline is the height of the tallest character (A). Notice that the character 'q' starts 3 pixels below the baseline, while both the 'A' and 'x' start on the baseline and the quotation mark (") starts 8 pixels above the baseline. The gap between the Origin and the left-most pixel of the glyph is known as Offset X. For the 'A' and 'q' and quotation mark, this is 1 pixel. For the 'x', this is 0 pixels.

Character Advance

The character advance is the number of pixels to move the Origin to the right. The character advance determines how much whitespace to put to the left and right of the glyph.

Conclusion

All of these details about offsets and baselines, advances and cells may seem intimidating, especially in a firmware environment. Many basic tasks become a lot more difficult when using proportional fonts: drawing text, editing a string or selecting text (with a mouse!). Fortunately, the EFI_HII_FONT_PROTOCOL provides functions which not only draw a string to a buffer or to the screen, but also report back information about the width and height of each character drawn. We will investigate these in more detail later.

Next week we will return to how the fonts are encoded.