5. Creating Fonts

Font resources used by the Font library can be created using ctr_FontConverter (or the command-line version ctr_FontConverterConsole) from fonts installed on a PC or from image data.

Warning:

CTR-SDK does not include a license to any font.

The ctr_FontConverter program uses fonts installed on a PC or image data to create font resources for the display of text using the font library. However, a license to use these fonts is needed to sell software that uses these fonts. You must always obtain all the appropriate licenses for each of your software titles.

Not only can ctr_FontConverter create font resources, but it also can output fonts as image data. The possible image data formats are BMP format and TGA format. Image data in these formats can be used to create font resources. In other words, you can output image data, revise or tweak it, and recreate the font resource from that data, and you can combine image data to create a font resource that contains multiple fonts.

5.1. Files Used to Create Font Resources

The following files are used when ctr_FontConverter creates font resources.

  • Character filter files
  • Glyph group files
  • Character order files

These files are all written in XML (eXtensible Markup Language), and generally share a common structure.

5.1.1. Common Structures

Although the name of the root element is different in the three types of files, each file has a common structure that contains the version attribute, the head element, and the body element. Although the structure of the head element is common among the files, the structure of the body element differs for each of the files.

Table 5-1 below lists the elements in the common portions. The elements and attributes indicated in bold are required.

Table 5-1. Elements in the Common Portions of the XML Files
Element

Elements It May Contain (Top Cell)

Attributes (Bottom Cell)

Description
Root element HEAD, BODY

For the root element, the name of the element is different in each file.

The elements it may contain and its attributes are common to all files.

version
HEAD CREATE, TITLE, COMMENT, GENERATOR

Contains the information describing the file itself (the header).

This element has a common structure in all files.

None.
CREATE None.

Contains information set when the file was created.

The user attribute contains the user name on the PC where the file was created. The host attribute contains the name of the PC. The date attribute contains the file creation date and time in ISO 8601 extended format.

The source attribute contains the filename of the source data file if a source data file exists.

user, host, date, source
TITLE None.

Contains the title of the file.

This title is sometimes displayed as a selectable item in the GUI version of ctr_FontConverter.

None.
COMMENT None. Contains comments from the creator of the file.
None.
GENERATOR None.

Contains information about the application that created the file.

The name attribute contains a string that identifies the application.The version attribute contains the application version string.

name, version

body Depends on the file Contains information comprising the body of the file.
None.

Figure 5-4 illustrates the hierarchy of elements.

Figure 5-1. Hierarchy of Elements in the Common Portions of the XML Files

Element Attribute Uppermost element version head create user host date source title comment generator name body

5.1.2. Character Filter Files

The character filter file (extension .xllt) is used for the creation of a compact font resource that contains only the required characters. When the font resource is converted into a font, it is possible to suppress the output of all characters except those specified in this file. This file is unnecessary when all characters contained in the pre-conversion data are to be included in the font.

The root element is LETTER-LIST and 1.0 is stored in the version attribute. The BODY element contains only one element: letter.

Table 5-2. Elements in the Character Filter File (Excluding the Common Portions)
Element

Elements It May Contain (Top Cell)

Attributes (Bottom Cell)

Description
LETTER-LIST HEAD, BODY

The root element.

The version attribute contains 1.0.

version
BODY LETTER

Contains information comprising the body of the file.

The only element it can contain is the single element LETTER.

None.
LETTER None.

Defines the characters to output.

The characters to output are specified by directly coding those characters. However, white-space characters (half-width spaces and tab characters) are ignored, and the half-width space is always included in the conversion results.

None.

Figure 5-4 illustrates the hierarchy of elements.

Figure 5-2. Hierarchy of Elements in the Character Filter File

Element Attribute letter-list version head body letter

The code below is the content of a sample character filter file (sample.xllt).

Code 5-1. Sample Character Filter File (sample.xllt)
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE letter-list SYSTEM "letter-list.dtd">
<letter-list version="1.0">
    <head>
        <create user="sample" date="2005-02-18T10:51:13" />
        <title>XLLT Sample</title>
        <comment>Sample Character Filter File</comment>
    </head>
    <body>
        <letter>
            FontConverter
            あいうえかきくけ
            任天堂
        </letter>
    </body>
</letter-list>

5.1.3. Glyph Group Files

The glyph group file (extension .xggp) is used for the creation of archived fonts (compressed fonts). By specifying a group set (or specifying a file using the command argument –op in the command-line version), you can create a font resource containing the group information set in this file.

The root element is GLYPH-GROUPS and 1.0 is stored in the version attribute. The BODY element contains only one element: letter.

Table 5-3. Elements in the Glyph Group File (Excluding the Common Portions)
Element

Elements It May Contain (Top Cell)

Attributes (Bottom Cell)

Description
GLYPH-GROUPS HEAD, BODY

The root element.

The version attribute contains 1.0.

version
BODY GROUP

Contains information comprising the body of the file.

The only element it may contain is the single element group.

None.
GROUP SP, GROUP

Defines the glyph group.

The enumerated characters are contained in a glyph group having the name specified in the name attribute. Multiple group elements can be nested in a GROUP element.

The only characters that can be used in the name attribute are the half-width alphanumeric characters (0–9, a–z, A–Z) and the underscore character (_). Within the same file, all GROUP elements must have unique name attributes.

name
SP None. Half-width spaces coded directly within GROUP elements are ignored, so this element is used to specify the half-width space within GROUP elements.
None.

Figure 5-4 illustrates the hierarchy of elements.

Figure 5-3. Hierarchy of Elements in the Glyph Group File

Element attribute glyph-groups version head body group name sp group  (can be nested multiple times)

The code below is excerpted from a sample glyph group file (sample.xggp).

Code 5-2. Sample Glyph Group File (sample.xggp)
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE glyph-groups SYSTEM "glyph-groups.dtd">
<glyph-groups version="1.0">
    <head>
        <create user="sample" date="2006-09-05T14:50:23" />
        <title>sample</title>
    </head>
    <body>
        <group name="all">
            <group name="ascii">
                <sp/> ! " # $ % & ' ( ) * + , - . /
                (omitted)
                p q r s t u v w x y z { | } ~
            </group>
            <group name="european">
                € ‚ ƒ „ ... † ‡
                ˆ ‰ Š ‹ Œ Ž
                (omitted)
            </group>
        (omitted)
        </group>
    </body>
</glyph-groups>

5.1.4. Character Order Files

The character order file (extension .xlor) is necessary when creating a font resource from image data or when outputting a font as image data. When used for input of image data, the order of the characters rendered in the image data must match the order of characters set in this file. When used for output of image data, the characters are rendered in the order set in this file, so this file also serves as a filter.

The root element is LETTER-ORDER and 1.0 or 1.1 is stored in the version attribute. The BODY element contains the AREA and ORDER elements.

Table 5-4. Elements in the Character Order File (Excluding the Common Portions)
Element

Elements It May Contain (Top Cell)

Attributes (Bottom Cell)

Description
LETTER-ORDER HEAD, BODY

The root element.

The version attribute contains 1.0.

If 1.0 is specified as the version attribute, no error results if multiple characters that have the same character code are coded within the ORDER element. However, if multiple glyphs that have the same character code are present, the first-coded glyph among them is used. Accordingly, edits to the other glyph images might not be reflected in the font resource. If 1.1 is specified as the version attribute, an error results if multiple characters that have the same character code are coded within the ORDER element, so we normally recommend that 1.1 be specified.

version
body AREA, ORDER

Contains information comprising the body of the file.

It can contain the AREA element and the ORDER element.

None.

AREA None.

Defines the font image contained in the image data using the number of characters in the horizontal and vertical directions.

The width attribute defines the number of characters in the horizontal direction. If this attribute is omitted, the default is 16.

The height attribute defines the number of characters in the vertical direction. If this attribute is omitted, the default is a value sufficient to output all the characters specified in the ORDER element.

width, height
ORDER SP, NULL

Defines the characters to output and their order.

The characters enumerated in this element are output to the font resource in the order defined within it.

None.
SP None. Half-width spaces coded directly within the ORDER element are ignored, so this element is used to specify half-width spaces in the ORDER element.
None.
NULL None. This element causes the output position to skip forward by one character. Use this element if you do not want to output the block in that position to the font resource.
None.

Figure 5-4 illustrates the hierarchy of elements.

Figure 5-4. Hierarchy of Elements in the Character Order File

Element attribute letter-order version head body area width height order sp null

The code below is excerpted from a sample character order file (cp1252.xlor).

Code 5-3. Sample Character Order File (cp1252.xlor)
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<!DOCTYPE letter-order SYSTEM "letter-order.dtd">
<letter-order version="1.1">
    <head>
        <create user="sample" date="2005-02-18T10:51:13" />
        <title>European Language (CodePage 1252 / Latin-1)</title>
        <comment>Windows Code Page 1252 character set. It is super set of ISO 8859-1 (Latin-1).</comment>
    </head>
    <body>
        <area width="16" />
        <order>
            <sp/> ! " # $ % & ' ( ) * + , - . /
            0 1 2 3 4 5 6 7 8 9 : ; < = > ?
            (omitted)
            € <null/> ‚ ƒ „ ... †
            ‡ ˆ ‰ Š ‹ Œ <null/>
            Ž <null/>
            (omitted)
        </order>
    </body>
</letter-order>

5.1.4.1. Notes on Coding

ctr_FontConverter uses Unicode as the character encoding for its internal processing. Accordingly, it uses Unicode to determine whether character codes are identical. For example, in CP1252 and Shift-JIS, the ASCII character codes match, and some extended Latin characters and half-width Japanese katakana characters are assigned to the same character code in these two different encodings. In contrast, in Unicode different character codes are allocated to the extended Latin characters and half-width Japanese katakana characters, so ctr_FontConverter determines them to not be the same character. Yet for the 16 characters listed in Table 5-5, although different character codes are allocated to these characters in CP1252 and Shift-JIS, the same character code is allocated in Unicode, so ctr_FontConverter unfortunately determines them to be identical. To avoid this problem, in the character order files cp1252_JIS_X0201_X0208_012.xlor and cp1252_JIS_X0201_X0208_012_94.xlor provided with the SDK, these 16 characters on the Shift-JIS side are replaced with <null/>.

Table 5-5. Characters Mapped to the Same Character Code in Unicode
Glyph Character Code in CP1252 Character Code in Shift-JIS Character Code in Unicode
´ 0xB4 0x814C U+00B4
¨ 0xA8 0x814E U+00A8
0x85 0x8163 U+2026
' 0x91 0x8165 U+2018
' 0x92 0x8166 U+2019
" 0x93 0x8167 U+201C
" 0x94 0x8168 U+201D
± 0xB1 0x817D U+00B1
× 0xD7 0x817E U+00D7
÷ 0xF7 0x8180 U+00F7
° 0xB0 0x818B U+00B0
§ 0xA7 0x8198 U+00A7
0x89 0x81F1 U+2030
0x86 0x81F5 U+2020
0x87 0x81F6 U+2021
0xB6 0x81F7 U+00B6

5.2. Creating Font Resources From Fonts Installed on a PC

ctr_FontConverter can create font resources from fonts installed on a PC. To exclude the possibility of using unlicensed fonts in products, the font resources are created using automatic font linking disabled, so that characters not included in the specified font are not included in the font resource.

When text is viewed in an ordinary text editor, automatic font linking enables characters not included in the font to sometimes be supplemented by characters from another font. The Windows application Character Map can be used to confirm exactly what characters are actually contained in a font.

5.3. Creating Font Resources From Image Data

ctr_FontConverter can create font resources from the combination of character order files and image data on which the font images have been rendered. The image data that can be used as input to ctr_FontConverter must be in the following format.

Table 5-6. Formats of Image Data Supported by ctr_FontConverter
Format Scope of Support
Indexed color BMP Per pixel: 1, 4, or 8 bits (2, 16, or 256 colors)
Direct color BMP Per pixel: 24 bits (RGB8) or 32 bits (RGBA8).
ColorMap type TGA Per pixel: index is 8 or 16 bits (256 or 65,536 colors), and palette is 24 bits (RGB8) or 32 bits (RGBA8). Run-length encoding compressed data is also supported.
TrueColor type TGA Per pixel: 24 bits (RGB8) or 32 bits (RGBA8). Run-length encoding compressed data is also supported.

ctr_FontConverter performs the following conversions depending on the color format and image data format specified as image data input options. Note that in intensity-format fonts, ctr_FontConverter inverts the luminance values of the image data. In other words, the closer a pixel is to black the higher its luminance value becomes, and the closer a pixel is to white the lower its luminance value becomes.

Table 5-7. Color Formats and Processing Performed in Conversion
Color Conversion Processes
A4

In the case of indexed color, the index value is converted to 4 bits.

In the case of direct color, the average of the RGB components is converted to 16-level grayscale.

A8

In the case of indexed color, the index value is converted to 8 bits.

In the case of direct color, the average of the RGB components is converted to 256-level grayscale.

LA4

In the case of indexed color, the index value converted to 4 bits is used as the luminance value.

In the case of direct color, the average of the RGB components converted to 16-level grayscale is used as the luminance value.

Regardless of the color format of the image data, the per-pixel alpha component converted to 4 bits is used as the alpha value.

LA8

In the case of indexed color, the index value converted to 8 bits is used as the luminance value.

In the case of direct color, the average of the RGB components converted to 256-level grayscale is used as the luminance value.

Regardless of the color format of the image data, the per-pixel alpha component converted to 8 bits is used as the alpha value.

RGB565 The RGB components are converted to 5, 6, and 5 bits, respectively, and the alpha component is not used.
RGB5A1 The RGB components are converted to 5 bits each, and only the most significant bit of the alpha component is used.
RGBA4 The RGBA components are converted to 4 bits each.
RGB8 The RGB components are converted to 8 bits each, and the alpha component is not used.
RGBA8 The RGBA components are converted to 8 bits each.
Linear Interpolation Correction

When the Font library renders characters, glyphs are displayed as textures applied to polygons. This enables hardware-based texture linear interpolation to be used to scale up characters. However, if the font format has an alpha channel and the pixel’s alpha value is 0, texture linear interpolation looks up the pixel color instead, which sometimes causes unintended display results.

With ctr_FontConverter, you can apply linear interpolation correction when you convert image data into a font resource. In linear interpolation correction, the color of pixels that are completely transparent (have an alpha value of 0) is overwritten with the average pixel color of all pixels that are not completely transparent (have a nonzero alpha value) among the eight adjacent pixels. The alpha value is not overwritten. Correcting glyphs in this manner resolves the unintended display problems caused by linear interpolation.

5.3.1. Blocks

A block is a subsection of the image data that contains a cell in which a glyph image has been rendered and a width-line region that indicates the character width. Each character coded in the character order file corresponds to one block, and the image data used for input to ctr_FontConverter must have these blocks packed one after another with no gaps in between.

The following limitations apply to the image data used for input.

width of one block × number of blocks in the horizontal direction = width of the image

height of one block × number of blocks in the vertical direction = height of the image

In other words, the blocks in the image are aligned with no gaps in between, and there must be no empty space or spacing between blocks.

In fact, the number of blocks in the horizontal (or vertical) directions are defined in the character order file. The tool compares these numbers to the dimensions of the image as determined from the image data, and calculates the dimensions of the individual blocks. These calculated block dimensions must be integers or the image data cannot be used for input.

The figure below is an example of image data.

Figure 5-5. Example of Image Data (Number of Blocks: 16×6)

Each block contains a cell, which is the region in which the glyph image has been rendered. Below the cell, there is a one-pixel blank area, and below that there is a width-line region having a height of one pixel. The width-line in this region defines the character width and the relative position of the glyph image within the cell. There is a one-pixel-wide blank frame surrounding the cell and the width-line region, and a one-pixel-wide grid frame surrounding the blank frame. Accordingly, the block boundary is the boundary of that grid frame against the grid frame of the adjacent block. The grid frames are not checked when image data is converted, but the blank frames must contain a solid color or the tool will determine that a glyph image has overlapped the edge of the cell.

The height of the width-line region and the number of pixels in the blank frame and grid frame are fixed, so the size of a cell is always determined as follows.

cell width = block width – 4 pixels

cell height = block height – 6 pixels

Figure 5-6 below is a schematic drawing of a block.

Figure 5-6. Schematic Drawing of a Block

Cell grid area margin area width width-line region

5.3.2. Cells and Width-Line Regions

Only the glyph image is placed within the cell. ctr_FontConverter detects the smallest rectangle present within the cell that contains all pixels with nonzero alpha values and all pixels whose color is not white (255, 255, 255), and handles it as the glyph image. For this reason, even if the cell itself is large, the white transparent spaces surrounding the glyph image are ignored and have no effect on the created font. If the image data does not include an alpha channel, the smallest rectangle containing non-white pixels is handled as the glyph image.

Only a single line segment called the width-line is drawn in the width-line region. The width-line defines the character width and the width of the spaces to the left and right of the character. The length of the width-line is taken as exactly equivalent to the character width, and any abnormality in this line (such as being discontinuous and broken into more than one segment) causes an error. The character width can be made smaller than the width of the glyph image, and in this case the character is displayed on 3DS overlapping with the previous character. You can move the glyph image left or right within the cell without affecting the output font as long as the width-line is also moved and maintains the same positional relationship with the glyph image.

If the size of the glyph image is 0 and the length of the width-line is also 0, or if the interior of the cell is a solid single color and the length of the width-line is 0, that glyph is not output. You can use this fact to control what glyphs are output instead of using a character filter file. Conversely, if a glyph is not passed for output despite being specified for output in the character filter file, the character may have been dropped unintentionally, and a warning is displayed.

5.3.2.1. Layout Information

The block at the upper-left corner of the image data contains several single-pixel points that specify parameters for string layout when strings are rendered. These single-pixel dots are the layout information. The four values serving as the parameters for layout are the baseline, the ascender line, the descender line, and the font width. These four values are specified with five points. These values are common to the entire font and cannot be specified for individual characters.

All of the dots are located in the grid frame and are white (255, 255, 255) if a grid has been rendered, or are rendered in the grid color if no grid has been rendered. Although the pixel that indicates the baseline position must always be present, the remaining four pixels may be omitted.

The single pixel at the extreme upper-left corner of the image is reserved for future use and must always be white (255, 255, 255). In addition, this single pixel can also be used as a color key for transparent color. If an alpha value is entered for this pixel, the transparent color is determined to be the color containing the alpha value.

Figure 5-7. Block Layout Information

Character width, glyph width, font width, left space width, right space width, ascender line, descender line, base line, font height, reserved pixel, pixel indicating the left edge of the font width (optional),  pixel indicating the right edge of the font width (optional), pixel indicating the position of the ascender line (optional), pixel indicating the position of the base line, pixel indicating the position of the descender line (optional)

Baseline

The point indicating the baseline position is rendered in the left edge of the grid frame. The upper edge of this pixel indicates the baseline position. In other words, the baseline lies on the boundary between pixels. The baseline serves as the vertical reference position when different fonts are used together or when characters are scaled.

Ascender Line and Descender Line

The points indicating the ascender line and descender line positions are also rendered on the left edge of the grid frame. Like the baseline, the ascender line and descender line lie on the boundary between pixels, with the lower edge of the ascender line’s pixel indicating the position of the ascender line, and the upper edge of the descender line’s pixel indicating the position of the descender line. The ascender line is treated as the upper edge of the string, while the descender line is treated as the lower edge of the string. The distance between the ascender line and descender line is called the font height, which is the reference size when scaling characters in the vertical direction.

The ascender line must always be positioned above the baseline, and the descender line must always be positioned below the baseline. However, it is possible for the baseline and the descender line to be specified by the same pixel, and in this case the descent is 0.

The two points indicating the ascender line position and the descender line position are optional and may be omitted, with the remaining points being interpreted as illustrated in Table 5-8. If no ascender line position or descender line position is specified, the upper edge of the cell is treated as the ascender line and the lower edge of the cell is treated as the descender line.

When ctr_FontConverter is used to output image data, the pixels indicating the ascender line position and the descender line position are sometimes rendered and sometimes not rendered. They are never rendered in conversions where Windows fonts are used as input. If image data is used as input, they are rendered if the input image contains pixels indicating the ascender line position and the descender line position, but are not rendered if not. When conditions are right to render the pixels indicating the ascender line position and descender line position, but the cell is too small to represent these pixels, the cell is automatically enlarged.

Table 5-8. Number of Points and Their Interpretation
Number of Points First Point from Top Second Point from Top Third Point from Top
0 Error
1 Baseline
2 Ascender line Baseline and descender line
3 Ascender line Baseline Descender line
4 or more Error
Font Width

The two points indicating the font width are rendered in the top edge of the grid frame. The two points represent the left edge and right edge of the width, respectively, so the number of pixels between these two pixels is the font width. These two points can be moved left or right with no effect on output as long as there is no change in the number of pixels between them. If the points indicating the font width are omitted, the width of the cell is taken as the font width. If used, both points must always be present (that is, you cannot omit just one of these points). The font width serves as the reference size for the tab width and for scaling characters in the horizontal direction.

When ctr_FontConverter is used to output image data, the pixels indicating the font width are sometimes rendered and sometimes not rendered. They are never rendered in conversions where Windows fonts are used as input. They are always rendered in conversions where font resources are used as input. If image data is used as input, they are rendered if the input image contains pixels indicating the font width, but are not rendered if not. When conditions are right to render the pixels indicating the font width but the cell is too small to represent these pixels, the cell is automatically enlarged.

5.4. Creating Font Resources From Existing Font Resources

Font resources can also be created and image data can also be output from BCFNT or BCFNA files. This capability can be used for filtering or investigating the characters contained in the font resources, or for checking or editing their glyph images.

Warning:

Be sure to obtain licenses to the fonts contained in the source font resources.


CONFIDENTIAL