4.3.3.3 Device Output
Description
Before describing device output, it is important to draw a distinction between characters and glyphs. A character is an abstract representation used for text processing. A glyph is a physical shape that is used to represent a character. There is not necessarily a 1-to-1 mapping between characters and glyphs. In general, there is an m to n mapping between characters and glyphs where m> 0 and n> 0. For example:
ü = u + umlaut (diacritical mark), 1 character to 2 glyphs
f + f = ff (ff ligature), 2 chars to 1 glyph
For more information on characters, see Section 4.3.2.1 "Characters (Semantics and Codespaces)."
This situation is even more common for languages that require what is collectively referred to as complex text layout (CTL), for example, Thai. In Thai, consonants can combine with vowels and tone marks to be represented on the screen as a single glyph.
The glyph point size needed to ensure legibility of characters tends to vary between languages. While a Latin based language can render quite well with an 8 point font, Chinese might need a much larger font size before
the glyphs are readable on the screen.
Another aspect of character output is the direction of character rendering on the output devices. The writing system is not always left-to-right and top-to-bottom. In Arabic and Hebrew, the text can be bi-directional, going from right-to-left mixed with left-to-right. In Japanese text processing systems, rendering text vertically from top to bottom is very common.
It is important that software products make no inherent assumptions about the mapping between characters and glyphs and the directionality of the text.
Software that controls the display by carrying its own graphics kernel, rasterizer, and fonts are generally considered a provider. If an application provides command line interface or character based interface, it does not control the display properties, such as fonts or color, directly. Instead it controls the appearance indirectly by using terminal interface libraries, such as libcurses). To do this, these terminal libraries interact with terminal emulators, such as dtterm). Hence software that
provides a terminal interface is also considered to be a provider, as it is responsible for displaying application messages and obtaining
user input. The provider software exports its display services either natively or using higher level interfaces, such as Motif in UNIX or Java Foundation Classes/Swing.
Command Line Interface
Providers receive text in the form of character encoding values and render characters according to the proper encoding and locale. The proper encoding and locale can be determined using system queries or by parameters included along with the text. To supply the text, and possibly encoding and locale information to the provider, consumers call provider functions .
Character Interface
In addition to proper character rendering, providers allow for text wrapping and spacing variations. Consumers call the provider functions with charset and locale information.
Graphical Interface
Graphical interfaces involve not only correct character rendering and text wrapping, but also formatting of layout. Text is more likely to be produced in a proportional font, juxtaposed with graphics. Objects such as buttons, scroll bars, and input fields must be managed according to the size of the rendered text, the orientation, and the input method.
Application Protocols
Not applicable.
Storage and Interchange
Not applicable.
Application Programming Interfaces (APIs)
Provider APIs can supply character-to-glyph transformation, font metrics data, string rendering and text wrap, and layout orientation swapping. Consumers provide the data stream, charset, locale, size, and other required information using the APIs.
Requirements for Compliance
Command Line Interface
Providers must map character codes into the correct corresponding glyphs.
Consumers must supply provider functions with the required information for correct rendering.
Character Interface
In character interfaces, provider software should handle character-to-glyph mapping, shielding consumer applications from dealing directly with glyphs. In addition, providers should handle plain text wrapping and spacing based on the character set and language.
Consumers must supply provider functions with all necessary information to correctly render the data.
Graphical Interface
The following requirements apply to providers:
- Providers should not make any assumptions about layout or directionality of components.
- Providers must be able to accommodate complex text layout (CTL) rules, in both horizontal and vertical directions.
- Providers should not optimize rendering based on a single glyph.
- Font metrics computation should be flexible enough to take into account multiple characters per glyph, zero width characters, and composite characters.
- Providers should not assume that a single physical font contains all the glyphs. Glyphs can be found in a set of fonts logically grouped together.
- Characters and glyphs must be handled in a locale independent way.
The following requirements apply to consumers:
- Consumers must supply provider functions with the information necessary for proper output.
- Consumers must not break compliance by overriding provider facilities or embedding character-to-glyph mapping and directionality.
Application Protocols
No requirement.
Storage and Interchange
No requirement.
Application Programming Interfaces
APIs must contain enough information to enable providers to correctly transform characters into glyphs, retrieve accurate font metrics, render strings, and wrap text.
If possible, consumers should use APIs provided by the underlying platform to convert characters into glyphs and to calculate font metrics.
|
|
Print-friendly Version
