JPH10111678A - Font file - Google Patents

Abstract

PROBLEM TO BE SOLVED: To make it possible to omit the waste of data capacity in a font file using outline fonts and to unify the positions of the terminal characters of respective lines. SOLUTION: The font file comprises a character shape table (GY-TBL) which rearranges the character shape data of the common outline font to plural different emulations or resolution to one set, a location table (LOC-TBL) which describes the offset data of the respective character shapes and a common table (CMi-TBL) which corresponds these codes and the indices of the location table by each style of type. The common table is provided with a base table (BASE-TBL) which houses base line positions (BS) and character heights (CH) at the time of a basic size and the distances (BU) from the base lines to underlines, a character width table (HW-TBL) which houses character widths (CW) by each resolution and a character height table (HD-TBL) which houses the BS, CH and BU of each resolution.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a font file used for converting character code data into character image data for printing or displaying.

[0002]

2. Description of the Related Art In various printers and display devices such as a conventional laser printer, a bitmap font is mainly used as a font file for converting character code data into character image data for printing or displaying. I was Since the bitmap font has a large amount of data, an extremely large memory capacity is required when having a plurality of fonts, which is uneconomical.

Accordingly, outline fonts having a reduced data amount have been developed. Even in such a case, a printer (e.g., emulation) and a host machine such as a personal computer or a word processor for creating character code data are further provided. Had a font set for each output device resolution.

[0004]

[Table 1]

Table 1 shows a configuration example of a conventional font file. In Table 1, Mincho L, Mincho PL, R9
8, R18 are different emulations, R98,
Some R18s have different resolutions. ANK
Are alphabets (Alphabet), numbers (Numeric), kana (Ka
na) is an abbreviation for half-width character set. In this half-width character set, the same one (ANK2, ANK3) is registered in font sets of different resolutions. GY-TBL is a table of character shape (glyph) data of each character that composes the font set, HW-TBL is a character width table that describes the character width of each character, and HD-TBL is a baseline (BS) of each character and characters High
(CH) and the distance from the baseline to the underline (B
9 is a height data table describing U).

[0006]

As described above, in an output device such as a printer that supports multi-emulation, a different font set is created for each emulation. Therefore, when the number of corresponding emulations is increased, the Every time I had to increase the font set.

Further, since the resolution of the bitmap and the resolution of the printer engine are paired, a font set is required for each resolution. For this reason, with the diversification of host machines and the increase in resolution of output devices such as printers, an increase in the data capacity of font files has become a problem, resulting in increased costs.

For example, if the resolution of the printer engine is 60
As the number increases from 0 dpi to 1200 dpi, the amount of font data required for each character increases accordingly.
Naturally, the size of the bitmap font corresponding thereto has also increased, and the bitmap font has become less practical due to the large capacity and the large number of types. However, the above problem remains even when an outline font is used. In addition, because the character width and height differ for each font, the number of characters that can be written on each line changes,
There was also a problem that it was difficult to align the position of the end character of each line.

SUMMARY OF THE INVENTION The present invention has been made to solve these problems in a conventional font file, and eliminates waste of data capacity in a font file using an outline font and aligns the position of the end character of each line. It is also intended to realize with wings (WYSIWYG).

[0010]

SUMMARY OF THE INVENTION In order to achieve the above object, the present invention provides a font file used for converting character code data into character image data for printing or display. Glyph table (GY) that collects glyph data of common outline fonts for different display resolutions
-TBL), a location table (LOC-TBL) that describes the offset data of each character, and a common table (CMi-TBL) that associates the code with the index of the location table for each typeface.

Further, the common table (CMi-TBL)
Contains a base table (BASE-TBL) that stores the baseline position (BS), character height (CH), and distance (BU) from the baseline to the underline for the basic size, and the character width for each resolution Character width table (HW-TB) containing (CW)
L) and a character height table (HD-TBL) containing the baseline position (BS), character height (CH), and distance (BU) from the baseline to the underline for each resolution. .

If all the bitmap fonts are abolished and replaced with outline fonts, the fonts are identical in many fonts (fonts), and the only differences are the order of the fonts in the font set and the reference resolution. In this case, only the character feed width and the baseline of the character when the font set was used.

Therefore, the font file according to the present invention does not have information such as a character shape, a character width, and a baseline in units of a font set, but shares character shape data among fonts corresponding to different emulations and resolutions. Font sets can be created efficiently by having unique values only for information in different parts, and font sets can be created efficiently by using existing font sets when adding new font sets. .

Further, by having the data such as the character width and the character height as a separate table, it is easy to control the distance between each character, and it is also easy to align the position of the last character of each line.

[0015]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a schematic diagram showing a configuration of a font file according to an embodiment of the present invention.

First, a character shape table (GY-TBL) 1 in which character shape data are put together is created by utilizing the fact that the character shape data (glyphs) of each font set often match. In this character shape table 1, the relative positions of the nodes representing the respective character shapes from the baseline are recorded in xy coordinates.

Further, a location table (LOC-TBL) 2 in which the offset data of each character is described is created.
Furthermore, a font (font: Mincho L, Mincho P in the example of FIG. 1)
-L, R98, R16), a common table (CMi-TBL) 3 is created in which the code is associated with the index of the location table (LOC-TBL) 2, and offset data of each character in each font is referred to. Make it easier. A font file is composed of these character table (GY-TBL) 1, location table (LOC-TBL) 2, and common table (CMi-TBL) 3, and stored in a font memory (ROM or RAM) of a printer or the like.

First, the location table (LOC-TBL)
A font code CI for defining a font set is set using the indexes (0 to n). Next, three types of tables for indicating the size of each character are created. One is a base table (BASE-TBL) that stores the character height CH, the baseline position BS, and the distance BU from the baseline to the underline in the basic size defining the character shape. The lengths indicated by CH, BS, and BU are shown in FIG.

The following table shows the character width CW for each resolution.
(In this example, CW180, CW240, CW300) is a character width table (HW-TBL) containing data. FIG. 3 shows the character width CW and the offset.

The last table shows the character height C for each resolution.
H, baseline position BS, and data of distance BU from the baseline to the underline, CH180, CH240,
It is a character height table (HD-TBL) containing CH300, BS180, BS240, BS300, BU180, BU240, and BU300. The meaning of each of these data is the same as that of the base table shown in FIG. 2 except for the difference in resolution. These are summarized for each typeface in a common table (CM
i-TBL) and its configuration is shown in Table 2. Here, i is a typeface number given to identify each typeface.

[0021]

[Table 2]

In order to actually print characters or display them on a screen, character data is generated as shown in the flowchart of FIG. In this case, the width of the bitmap font originally used for emulation is fetched from the character height table (HD-TBL) and used.

This processing is started when the character code, layout position, font number, and size H are received from the host. First, the type numbers (Mincho L, Mincho P-L, R9
8, character data is extracted from the character table of the font file from the character code and the identification number assigned to R16.

Next, from the character height table (HD-TBL),
From the data of the size (character size) of the base bitmap font, the number of dots suitable for the designated size H from the host is calculated. And base table (BASE-T
Use the font size in (BL) to determine the magnification. Then, the character coordinates are generated by multiplying the node coordinates representing the character shape by the scaling factor. After that, the completed character data is output.

By configuring a font file in this way, character data is registered only when a new one is required, and each font set uses existing character data as much as possible and duplicates the same character data. Since registration is not performed, the data amount can be reduced even if various emulations and resolutions can be supported. Even when a new font set is added, an increase in the amount of font data can be minimized.

Further, since the character width is calculated by referring to the character height table (HD-TB) while comparing the character width with the reference size, the position of the last character of each line is calculated in the same manner as when a bitmap font is used. (WYSIWY
G) is done. Similarly, in the case of vertical writing, there is data at the standard resolution in the vertical arrangement such as the baseline, so
In the same manner as when a bitmap font is used, the position of the end character of each line can be aligned.

[0027]

As described above, according to the present invention, a font file using an outline font which can support various emulations and resolutions can be realized with a minimum amount of data, and the end character of each line can be obtained. Wizwing (WYSIWYG) for aligning the positions is also possible.

[Brief description of the drawings]

FIG. 1 is a schematic diagram showing a configuration of a font file according to an embodiment of the present invention.

FIG. 2 is an explanatory diagram showing a character height CH, a baseline position BS, and a distance BU from a baseline to an underline.

FIG. 3 is an explanatory diagram showing a character width CW and an offset.

FIG. 4 is a flowchart showing a work process performed when generating character data.

[Explanation of symbols]

 1: Character table (GY-TBL) 2: Location table (LOC-TBL) 3: Common table (CMi-TBL)

Claims (2)

[Claims] 1. A font file used for converting character code data into character image data for printing or displaying, wherein said font file has a common outline font character shape for a plurality of different emulations or different printing or display resolutions. Glyph table (GY-TBL) that collects data
And a location table (LOC-TBL) describing the offset data of each glyph, and a common table (CMi-TBL) in which the code is associated with the index of the location table for each typeface. Font file to use. 2. The font file according to claim 1, wherein the common table (CMi-TBL) includes a base line position (BS), a character height (CH), and a base line to an under line at a basic size. Table (BASE-TBL) that stores the distance (BU) of each character, character width table (HW-TBL) that stores the character width (CW) for each resolution, baseline position (BS), and character height for each resolution (CH) and a character height table (HD-TBL) containing the distance (BU) from the baseline to the underline.