JP3715917B2 - Typeface data management method and apparatus - Google Patents

Description

[0001]
[Industrial application fields]
The present invention relates to a typeface data management method andapparatusA typeface data management method for managing data files of various typefaces used in, for example, a personal computer, a word processor, a desktop publishing apparatus, etc.apparatusIt is about.
[0002]
[Prior art]
Conventionally, typeface data managed in a character processing system stores all character data in a single typeface in one file for reasons such as ease of management.
[0003]
[Problems to be solved by the invention]
The typeface data management method according to the conventional method has the following problems.
[0004]
All typeface data is stored in the file beforehand,For example,The target of installation was only a selection of typeface units. For this reason, even typeface data that is not generally used is installed at the same time, resulting in pressure on the disk memory.
[0005]
[Means for Solving the Problems]
The present invention has been made in view of the prior art, and has a flexible typeface data management method.And equipmentIs to provide.
[0006]
For this reason, for example, one typeface data management method of the present invention comprises the following steps.
[0007]
  In a typeface data management method for retrieving data about a requested character from a typeface data file,
  In the first typeface, among the partial code spaces each consisting of continuous codes, the typeface data file corresponding to any partial code space is held in common with the second typeface, and the typeface management information is held.
  When there is a character request including a code in the first typeface, the typeface data is obtained from the commonly used typeface data file if it corresponds to the range of any partial code space based on the typeface management information.It is characterized by that.
[0008]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, the present invention will be described in detail with reference to the drawings.
[0009]
First, a brief description will be given of a movement until a font data is acquired when a system handling character data such as a personal computer displays or prints characters.
[0010]
FIG. 1 is a block diagram showing a basic configuration for operating these systems.
[0011]
In FIG. 1, reference numeral 101 denotes a CPU, that is, a central processing unit, which performs activation of the entire system, arithmetic processing, and the like. Reference numeral 102 denotes a read-only memory (ROM), which is a storage area for a system startup program (boot program) and character pattern data. A random access memory (RAM) 103 is loaded with a system program, various application programs, a driver program for generating a character pattern, and the like, and is used for temporarily storing various data. Of course, a program relating to a flowchart to be described later is loaded into the RAM 103 and executed. A keyboard control unit (KBC) 104 receives key input data from the keyboard (KB) 105 and transmits it to the CPU 101. A CRT control unit (CRTC) 106 controls the display device (CRT) 107. Reference numeral 109 denotes an external storage device such as a floppy disk device (FD) or a hard disk device (HD), in which various programs such as system programs and application programs, and font data are stored. When the program is executed, the program stored in the external storage device 109 is loaded into the RAM 103 and executed by the CPU 101. Reference numeral 110 denotes a printer control unit (PRTC). Reference numeral 111 denotes a printer (PRT) that forms a visible image on recording paper based on transmitted data under the control of the PRTC 110. A system bus 112 serves as a data path between the above-described components.
[0012]
FIG. 2 is a diagram showing a memory map of the RAM 103. 201 is a system area in which the system is loaded, 202 is an area in which a character development processing unit is loaded, and 203 is an area in which the character development processing unit stores bit pattern data. Reference numeral 204 denotes an area to be read for referring to the vector pattern data stored in the external storage device 109 during the character expansion process. Reference numeral 205 denotes an area for generating a management information table for operating the system. Reference numeral 206 denotes a typeface vector data cache area.
[0013]
FIG. 3 shows a configuration of a system that handles the character data.
[0014]
3, 301, 302, and 303 represent various typeface data stored in the external storage area 109 in FIG. The type and number of typeface data stored in the external storage device 109 are not substantially limited.
[0015]
Reference numeral 304 denotes a system control unit, which includes 201, 204, and 205 in FIG. Reference numerals 305 and 306 denote character expansion processing units, that is, rasterizers. The character expansion processing function may be realized only by software, may be realized by hardware, or may be realized by using both hardware and software. I do not care. The number of rasterizers included in the system is not limited as long as at least one rasterizer is included. Reference numeral 307 denotes an application unit (for example, a program such as a word processor) that issues a character acquisition request to the system.
[0016]
In FIG. 3, the application unit 307 issues a character acquisition request. The character acquisition request is made using a character code and typeface information corresponding to the character one-to-one in order to determine the character to be acquired. In order to acquire the requested character data, the system control unit 304 acquires necessary data from the font data 301, 302, and 303. If the acquired data is contour vector data constituting an outline font, the data is transferred to the rasterizers 305 and 306. If the acquired data is bit pattern data, it is transferred to the application unit 307 as it is. The rasterizers 305 and 306 develop the received contour vector data into a bit pattern and send it back to the system control unit 304. The system control unit 304 returns the bit pattern data received from the rasterizers 305 and 306 to the application unit 307.
[0017]
Next, the embodiment will be described in detail based on the above description.
[0018]
This embodiment aims to make it possible to acquire typeface data by dividing a typeface data file and installing only necessary portions. The division method will be briefly described with reference to FIG.
[0019]
FIG. 4 simply shows the structure of the divided file. In order to simplify the description, it is assumed that the typeface A constitutes one typeface with character codes 0 to 600.
[0020]
This typeface A is divided into four parts of 0 to 100, A1, 101 to 199, A2, 200 to 500, A3, and 501 to 600. In this typeface A, the A3 portion is data that is not generally used, and is the portion that requires the most disk memory.
[0021]
The divided typeface information is shown at the time of typeface installation, and a part to be installed is selected by the user's hand (keyboard). As a result of the selection, only the necessary part is installed, and a typeface information file 500 describing the breakdown of the typeface of the installed result shown in FIG. 5A is created on the external storage device 109. FIG. 5B shows the result status of the installed typeface file.
[0022]
When the system is started, information is read from the typeface information file 500, information indicating the breakdown of the installed typefaces is extracted from the typeface information file, and a typeface management information table as shown in FIG. create.
[0023]
The flow of creating the typeface management information table will be described with reference to FIG. The figure shows the processing related to the typeface during the initial processing when the system is turned on, and the processing procedure is stored in the external storage device 109.
[0024]
First, in step S702, the typeface information file is opened, and in the next step S703, the typeface name information is acquired from the opened typeface information file, and the typeface name information is written into the typeface management information table.
[0025]
In step S704, the file name is acquired from the typeface information file, and the file name information is written into the typeface management information table. In step S705, based on the file name of the typeface acquired previously, the file open process for making the file accessible is performed. In step S706, information on the start code and end code of the typeface data stored in the file is read from the typeface file accessible in step S705, and is written in the typeface management information table.
[0026]
In step S707, it is checked whether a file of the same typeface still exists in the description in the typeface information file. If it exists, the process returns to step S704 to acquire the next file name and update the table.
[0027]
If it is determined in step S707 that the same typeface file does not exist, the process advances to step S708 to check whether there is an unprocessed typeface in the typeface management file. Processes the typeface. If it is determined that the creation of tables for all typefaces has been completed, the process advances to step S709 to close the typeface information file that was opened in the previous step S702, and the process ends.
[0028]
With the above processing, a typeface management information table as shown in FIG. 6 is created in the typeface information management area 205, for example.
[0029]
Next, the flow until the necessary typeface data is acquired using the typeface management information table of FIG. 6 will be described with reference to the flowchart of FIG.
[0030]
In step S801, character data acquisition processing is started.
[0031]
In step S802, information (character code, typeface information) related to characters acquired from the AP unit 307 in FIG. 3 is acquired. In the next step S803, the first typeface of the typeface management information table shown in FIG. 6 is searched (the pointer indicates the first typeface in the table in the initial stage), and it is checked whether the typeface is the corresponding typeface. When it exists, it progresses to step S804, and when it does not exist, it progresses to step S805.
[0032]
If it is determined that the typeface is not corresponding and the process proceeds to step S805, it is determined whether another typeface exists, and if there is another typeface, the pointer is advanced there.
[0033]
When the corresponding typeface can be found and the process proceeds to step S804, whether or not the requested character code is within the managed range on the typeface management information table, in other words, the character code is managed. Determine if you are. Since the pointer at this point is placed at the head position in FIG. 6, it is determined whether or not the requested character code is within the range of “0” to “100”.
[0034]
If it is determined that the file does not exist, the process advances to step S806 to determine whether or not a file of the same typeface is managed in the line next to the target line in the table. If there is, the pointer is advanced by 1, and the process returns to step S804. If it is determined that the next file does not exist, the characterless process is performed.
[0035]
On the other hand, if it is determined that the character code of the requested typeface is managed, the process proceeds to step S807, where the file name is obtained from the target line in the typeface management information table, and in step S808, the obtained file name is obtained. Based on the above, the typeface data is acquired from the file, and the process proceeds to the end process S810.
[0036]
As described above, according to the present embodiment, only the required character code range of the required typeface can be installed in the system, so that the memory consumption of the external storage device 109 can be suppressed and the management of unnecessary portions can be performed. Since this is not done, the processing speed can be increased.
[0037]
<Description of Second Embodiment>
In the above embodiment (first embodiment), for example, when the typeface management information table is as shown in FIG. 6, when there is a character acquisition request for the character code “501” of the typeface A from the application unit, FIG. Steps S804 and S806 in Step 8 are looped three times. There is no problem when the frequency of character acquisition requests for the character codes “501” to “600” is not so high with respect to the overall request, but the processing speed is high when the frequency is higher than other character codes. The decline of is inevitable.
[0038]
Therefore, in the second embodiment, the frequency of occurrence of character acquisition requests is counted and reflected in the creation of the typeface management information table at the next startup.
[0039]
The system configuration in the second embodiment is also shown in FIG. The same applies to a third embodiment and later described later. In the second embodiment, a case will be described in which font data A1 to A4 in the entire range shown in FIG. 4 is specified when font data is installed in the external storage device 109. The program according to the flowchart of FIG. 8 is naturally stored in the external storage device 109. This also applies to each embodiment described later.
[0040]
FIG. 9 shows an initial state of the typeface management table created in the second embodiment. The difference from FIG. 6 of the first embodiment is that a column for storing and holding the number of accesses of each code range in the same typeface is provided. Since the procedure for creating the typeface management information table itself is the same as that in the first embodiment, a description thereof will be omitted and the character data acquisition process will be described with reference to FIG.
[0041]
The difference between the flowchart of FIG. 10 and FIG. 8 in the first embodiment is that step S807 is replaced with step S807 'and step S811 is added.
[0042]
In the figure, when there is a character data acquisition request from the application unit for the typeface management table, and the requested character data is managed by the management table, the process proceeds from step S804 to step S807 '. When processing proceeds to step S807, the file name is acquired from the typeface management information table, and the value in the corresponding access column of the typeface management information table is incremented by “1”. In step S808, based on the acquired file name, typeface data is acquired from the file, and the process proceeds to end processing S811.
[0043]
As a result, for example, the typeface management information table is as shown in FIG.
[0044]
In step S811, a process of rearranging the order stored in the typeface management file by the number of accesses in the management table at that time is performed, and the present process ends.
[0045]
For example, if the typeface management information table is in the state shown in FIG. 11, the file access count for typeface A is A4> A3> A2> A1, so the contents of the typeface information file are as shown in FIG. The order is changed.
[0046]
Since the table is created in accordance with the order stored in the typeface information file when the apparatus is activated, the typeface management information table at the next activation is as shown in FIG. That is, the file A4 in the typeface A is positioned first, so that it is possible to improve the access speed for the character data location acquisition request.
[0047]
In the second embodiment, the typeface information file is updated each time a character data acquisition request is generated. However, the processing speed can be further increased by performing the power-off processing of the system.
[0048]
In the system power-off process, the number of accesses of the partial files (A1 to A4) constituting each typeface is also saved as an appropriate file, and the number of accesses is obtained from the file at the next system startup, and the table is stored. The order may be determined.
[0049]
As described above, according to the second embodiment, since the character code range having a larger number of accesses is preferentially arranged at the head of the typeface information management table, the overall cost performance related to the generation of character patterns can be improved. It becomes possible.
[0050]
<Description of Third Embodiment>
Next, a third embodiment will be described. In the third embodiment, the code range specified by the user among a plurality of typefaces is replaced with another typeface.
[0051]
FIG. 14 shows the structure of the divided file in the third embodiment. A different point from that of FIG. 4 in the first embodiment is that a plurality of typefaces are divided. In the figure, A1 to A3, B1 to B3, and C2 indicate file names, respectively.
[0052]
In the third embodiment, for example, the range of the character codes “101” to “199” in the font A is subordinate to that of the font C. For example, when a request for character data of the character code 101 in the font A comes from the application, Data is extracted from the file C2 (actually the typeface C) and processed.
[0053]
According to this, for example, it is possible to generate a desired typeface pattern for each character type while using one “typeface name” of alphabets, numbers, flat, katakana, kanji, and the like. In some cases, for example, when the entire font A is an outline font and the font C is a dot pattern, a specific portion can be processed at high speed.
[0054]
An example of the contents of the typeface information file in the third embodiment is shown in FIG. The typeface information file can be created freely by the user or automatically by the system. Alternatively, as shown in the first embodiment, the user may select font data at the stage of installing the font data in the system.
[0055]
As shown in FIG. 15, if the part of the file A2 of the typeface A is subordinate to the corresponding part of the typeface C, the file A2 in the typeface A need not be installed in the external storage device 109. Memory consumption of the device 109 can also be suppressed. Further, when a user registers his / her own typeface, it is only necessary to determine which type of character code is used for which typeface, so the amount of memory consumed by the user typeface is substantially dependent on it. Only the typeface information file showing the relationship. As shown in FIG. 15, information indicating whether or not each typeface is subordinate is added. In one typeface, whether or not it is subordinated for each character code range. If there are subordinates, information indicating what the typeface is is added.
[0056]
Now, when there is a typeface information file as shown in FIG. 15, when this system is activated, a typeface management information table as shown in FIG. 16 is created in the typeface information management area of the RAM 103.
[0057]
Processing related to the creation of the typeface management information table will be described with reference to the flowchart of FIG.
[0058]
When this process is started in step S751, a certain area is secured in the typeface information management area 205 in order to create a typeface management information table. In step S752, the typeface information file stored in the external storage device 109 is opened, and in the next step S753, typeface information is acquired from the opened typeface information file.
[0059]
When the process proceeds to step S754, it is determined whether or not the typeface being noticed is a dependent typeface. If it is a dependent process, the process returns to step S753. If it is determined that the typeface is not a dependent typeface, the process proceeds to step S755.
[0060]
The process proceeding to step S755 means the start of table creation for one typeface. Therefore, here, the typeface name is written in the typeface information management table, and a table in which the dependency relationship for each character code range with respect to the typeface is clarified by the processing described below is constructed.
[0061]
In step S756, the following information is extracted from the open typeface information file, that is, the subordinate information for the code range in the target typeface. In step S757, it is determined whether or not the extracted character code range is subordinate, in other words, whether or not there is subordinate information in the extracted information.
[0062]
If there is no dependent information, the process proceeds to step S758, and the file name unique to the focused typeface is written in the typeface information management table so as to correspond to the focused code range.
[0063]
If there is subordinate information, the process proceeds to step S759, where the corresponding file name of the subordinate typeface is extracted and written into the typeface information management table.
[0064]
In any case, the process proceeds to step S760, and the file is opened and made accessible based on the file name acquired in step S758 or 759. In the next step S761, information on the start code and end code of the typeface data stored in the file is read from the typeface file that can be accessed, and written in the typeface information management table.
[0065]
When the process proceeds to step S762, it is determined whether or not the process for one typeface has been completed. If it is determined that the process has not been completed, the process returns to step S756 to perform the above process.
[0066]
If it is determined that the processing for all code ranges for one typeface has been completed, the process advances to step S763 to determine whether there is a typeface to be processed next. If the typeface to be processed remains, the process returns to step S753. If there is no typeface to be processed, the process proceeds to step S764.
[0067]
If the process proceeds to step S764, the open typeface information file is closed, and the process ends in step S765.
[0068]
As a result, for example, when there is a typeface information file as shown in FIG. 15, a typeface information management table as shown in FIG. 16 is created.
[0069]
Note that the processing for acquiring the font data using the font information management table created in this way is the same as that in the first embodiment described above. That is, when a request is made to acquire the typeface data of the character code “101” of the typeface A from the application section, the table is checked, and it is detected that the character code “101” for the typeface A is the file name C2. The corresponding typeface data is extracted from C2, and a character pattern is generated. If this typeface data is outline data, it is once passed to the rasterizer 305 to generate a dot pattern and passed to the application.
[0070]
As described above, according to the third embodiment, by replacing data of another typeface with a desired code range of one typeface, for example, a sentence mixed with English or Japanese is created. In some cases, it is possible to input characters in a typeface that reflects the user's will without changing the typeface.
[0071]
Moreover, the typeface data originally associated with the code range instructed to depend on the data of other typefaces at the time of installation or at an arbitrary time becomes virtually unnecessary, and that part is removed from the installation target or deleted. Therefore, the memory consumption of the external storage device 109 can be suppressed.
[0072]
<Description of Fourth Embodiment>
A fourth embodiment will be described below. Normally, when installing typeface data in a system, it is essential to store one entire typeface in one logical storage device. The fourth embodiment makes it possible to store one predetermined storage destination in a logically different device. In this way, for example, each logical device does not have enough free space to store all of the typeface, or responds to a request for providing a certain amount of free space in each logical device.
[0073]
Incidentally, the logical storage device referred to here is a concept including a physical device. For example, when one physical storage device is logically divided into a plurality of logical devices, or the same physical device. This is a concept including devices that have different paths.
[0074]
An example of a typeface information file in the fourth embodiment is shown in FIG. In the drawing, only one typeface is shown for ease of explanation. In the figure, A1 to A4 are file names of the typeface A corresponding to the code range as described in the first to third embodiments.
[0075]
Briefly describing the drawing, it is shown that typeface data in a certain code range for the typeface A is stored in the logical drive A as the file A1.
[0076]
In the fourth embodiment, the typeface information table is extracted when the system is activated, and a typeface information management table as shown in FIG. 19 is created based on the data described therein.
[0077]
As for the format of the typeface information file and the typeface information management table created based on the typeface information file in the fourth embodiment, the drive name of the storage destination is described with respect to the format shown in FIGS. 5A and 6 of the first embodiment. Only the difference is. Those skilled in the art will be able to easily guess if there is a gap between the processing contents of the first embodiment described above and the structure of the typeface information file shown in FIG. Therefore, the description is omitted here.
[0078]
However, in the fourth embodiment, it has been described that the storage destination of the files of the individual code ranges constituting the typeface data is specified at the time of installation, but of course, all of them are once stored in the same storage drive, and thereafter If necessary, the font data in the appropriate code range may be moved to another storage device (for example, a higher speed external storage device).
[0079]
As described above, according to the fourth embodiment, one typeface data does not have to be in the same position of one logical device, and can be stored in a desired device, so that an external storage device can be used effectively. It becomes possible.
[0080]
<Description of Fifth Embodiment>
Next, a fifth embodiment will be described. For example, even when a character design of a specific range is used, it is necessary to store the font data of the entire range of the font of the design, so the memory consumption of the external storage device cannot be ignored. In the fifth embodiment, such a problem is eliminated.
[0081]
FIG. 20 simply shows the structure of the divided file. In the drawing, the typeface A indicates that one character typeface is composed of character codes 0 to 500, and three parts of A1 of 0 to 100, A2 of 101 to 199, and A3 of 200 to 500 are shown. As a general code range. The typeface A 'is the same as the typeface A, has a different character set, has only a character data portion that must be changed when the character set is switched, and the included character code is the same as 101 to 199 A2. That is, as a typeface, A 'is the same as A, but only character codes 101 to 199 are used.
[0082]
Note that a character set refers to a character expression in the same code range (space), for example, flat and katakana, English alphabet and Russian alphabet.
[0083]
In order to perform the typeface management, the typeface information file in the fifth embodiment describes the relationship between the typeface file and the character set as shown in FIG.
[0084]
The procedure for creating the typeface management information table constructed in the typeface management information area 205 in the RAM 103 at the time of system startup is performed according to the procedure shown in FIG. 7, and therefore the description thereof is omitted here. As a result, the typeface management information table shown in FIG. 22 is constructed. In the table, A1, A2, A3 and A2 'are file names of data for constructing typeface data A and A', respectively.
[0085]
The flow of character data acquisition using the typeface management information table created in this way is also performed according to the procedure shown in FIG. 8, but will be described as follows.
[0086]
First, in step S801, character data acquisition processing is started.
[0087]
In step S802, information (character code, typeface information, character set) related to characters acquired from the AP unit 307 in FIG. 3 is acquired. In the next step S803, the typeface management information table in FIG. 6 is searched to check whether the corresponding typeface and character set exist. When it exists, it progresses to step S804, and when it does not exist, it progresses to step S805.
[0088]
In step S805, it is determined whether another typeface still exists on the typeface management information table shown in FIG. If it exists, the process advances to step S803 to check another typeface in the table.
[0089]
If it is determined that the requested typeface exists in the table and the process proceeds to step S804, it is determined whether the requested code is included in the start code and end code of the target character set in the target typeface. . In addition, since the code range assumes that “−1” is stored for both the start code and the end code for a file that does not exist, it can be easily determined whether the character data of the code is managed.
[0090]
If it is determined in step S804 that the requested character code is outside the range of the focused character set, the process proceeds to step S806, where there is an unchecked character set in the same typeface. Judge whether. If there is, the process returns to step S804, and it is determined again whether or not there is a character set corresponding to the request code. If there is no character, the process proceeds to step S809 to perform a characterless process.
[0091]
On the other hand, if it is determined that there is a character set that manages the typeface of the requested character and its character code, the process advances to step S807 to obtain a file name from the typeface management information table, and the file name is obtained in step S806. Get the corresponding character data from the file. And it progresses to step S810 and complete | finishes a process.
[0092]
As described above, according to the fifth embodiment, even if characters of the same typeface or different character sets are designated, only the typeface data of the code range including only the characters to be used is included. The data corresponding to all the character codes is not necessary, and the storage area of the external storage device can be used effectively.
[0093]
<Description of Sixth Embodiment>
In the fifth embodiment, for example, when using the same typeface A ′ as the typeface A but using a different character set, only the typeface data in the character code range to be used is stored in the external storage device. It was intended to make effective use of memory.
[0094]
In the sixth embodiment, different typefaces are stored, and typeface data in the same range of the other typeface is used as typeface data of a specific code range in one typeface. As a result, it is not necessary to have redundant typeface data in common use, and the memory can be used efficiently.
[0095]
FIG. 23 simply shows the structure of the divided file in the sixth embodiment. In the drawing, the typeface A indicates that one character typeface is composed of character codes 0 to 500, and three parts of A1 of 0 to 100, A2 of 101 to 199, and A3 of 200 to 500 are shown. As a general code range.
[0096]
Similarly to type A, type B is managed by dividing the entire character code space into three, and among these, character codes 0 to 100 and 200 to 500 use type B data specific to type B. For 101-199, the font A is used.
[0097]
In order to perform the typeface management, the typeface information file in the fifth embodiment is composed of the typeface type and the divided typeface data file name for constructing the typeface as shown in FIG.
[0098]
The creation procedure of the typeface management information table constructed in the typeface management information area 205 in the RAM 103 at the time of starting the system is performed according to the procedure shown in FIG. 7, so the description here is omitted. 25 is constructed in the typeface information management area 205 in the RAM 103.
[0099]
The character data acquisition process may also follow the flowchart shown in FIG. That is, when there is a character data acquisition request from the AP section, it is determined which typeface of the typeface information management table has been selected based on the typeface data specified in the request, and then in the typeface The file name managing the designated character code is acquired, and then the corresponding character data is acquired from the file.
[0100]
<Description of Seventh Embodiment>
So far, when identifying typeface data, the typeface name or type number representing the typeface, or the type name and type number, or the style information, width information, and weight information as required, are used separately. The determination process has to be complicated and takes time.
[0101]
Therefore, in the seventh embodiment, an example will be described in which such discrimination can be performed easily and at high speed.
[0102]
FIG. 26 shows a format of style width weight information in the seventh embodiment. As shown in the figure, 4 bits (0 to 15 as values), 4 bits as width information, and 8 bits (0 to 255) as weight information are allocated as style information. As style information, “0” is defined as regular, “1” is defined as italic,. As width information, 4, 6, 8, 10, and 12 are associated with extra condence, condence, regular, expand, and extra expand. As weight information, 60, 70, 80, 90, 100, 110, 120, 130, 140 are associated with special, extra fine, fine, medium thin, medium, medium thick, thick, extra thick, and special thick. It was.
[0103]
Now, an installation procedure in this embodiment (installation of the external storage device 109 from the floppy disk to the hard disk) will be described with reference to the flowchart of FIG.
[0104]
First, in step S301, a request is made to set a medium in which typeface data to be installed and data necessary for installation (installation data file) are stored, and the user is allowed to specify the medium.
[0105]
In step S302, the typeface name information, typeface number, and style weight information are read from the installation data file in which the typeface data to be installed is stored.
[0106]
In step S303, the typeface data in the typeface information file already installed at the installation destination is read. At this time, if it is determined in step S304 that the typeface information file to be read does not exist in the installation destination, the typeface file is created (step S305).
[0107]
Next, the process proceeds to step S306, where the contents of the typeface information file at the installation destination are compared with the typeface information to be installed. The priority of the comparison processing is: first font type number, second style width weight information, and third font name. If all of the above items are the same, the font is unconditionally the same typeface. Also, if the contents of the first item and the second item are the same, the character data of the typeface is the same, so the processing that prevents the contents of the typeface from overlapping and the typeface name is unique. Whether to process is determined by this processing (for example, the user is instructed).
[0108]
When the process proceeds to step S307, it is determined whether the typeface data to be installed by this installation process is updated or newly added. The update process is a case where all three items are the same as described above.
[0109]
If it is determined that the update processing is to be performed, the process proceeds to step S309, and the existing font type data is overwritten at the same typeface existing position described in the typeface information file. At this time, if the installation destination is separately instructed by the user, a process of writing in the instructed position is performed.
[0110]
If it is determined that the new typeface is installed, the process advances to step S308 to install the typeface name, typeface number, style width weight information, tag file name, and typeface information.
[0111]
Finally, this process ends and returns to the caller.
[0112]
FIG. 28 shows the contents of the installation media and the contents of the installation data file therein.
[0113]
Information necessary for installation is described in the installation data file. Typeface information is stored in the typeface file. The tag file stores data for creating a typeface from information in the typeface file. Therefore, it is considered that there is a typeface for a tag file using a plurality of tag files from one typeface data.
[0114]
FIG. 29 shows an example of the contents of the typeface information file in the present embodiment. “NAME” is a description name, font information (main font number, sub font number, style width weight information). “DEFTAG” is a tag file name and a typeface name existing in the tag file. “FILE” is the installation destination of the typeface disk and the file name of the typeface file.
[0115]
FIG. 30 shows an example of the contents of a tag file. In this file, face names are stored in the tag file size, typeface number, style width weight information, description name, and typeface metrics information. The font type number and style weight information are linked to the font data.
[0116]
FIG. 31 shows the contents of the typeface file. This file stores typeface composition information (file size), typeface data (typeface start code, number of characters), typeface number, and style width weight information.
[0117]
As described above, according to the seventh embodiment, after installation, the style width weight including the style information, the width information, and the weight information of the typeface information is included as information representing the typeface, so that the typeface name, the typeface number, etc. This makes it possible to distinguish fonts more easily than at high speed.
[0118]
<Description of Eighth Embodiment>
An eighth embodiment will be described. In the eighth embodiment, a principle for optimizing font-related file names will be described. As an example, an example in which the file name managed by the system (or OS) in this embodiment is 8 characters (8 bytes) and the extension is 3 characters (3 bytes) will be described.
[0119]
FIG. 32 shows the character structure used for the file name of the typeface physical file in the eighth embodiment.
[0120]
In the figure, (1) is the two characters for typeface identification shown in FIG. 34, and (2) is a number representing the style width information (0 to 9) shown in FIG. The number indicating the weight information shown in FIG. 37 is located in (3), and the size / support area information shown in FIG. 38 is in (4). {Circle over (5)} is file identification information, and the character string “JFD” is used in the embodiment.
[0121]
FIG. 33 shows the structure of the file name of the typeface logical data file of typeface data. (6) is typeface management information, which is expressed using arbitrary three characters. (1) indicates the release order of this file, which is applied according to FIG. (3) is the weight information shown in FIG. (8) is metrics information identification information. This item indicates the release order of this file. If the information is the same as the printer font, it is represented by “P”. {Circle over (5)} is file identification information. In this case, “FON” is used.
[0122]
Hereinafter, FIGS. 34 to 38 will be described in more detail.
[0123]
FIG. 34 shows physical typeface identification information. MI stands for Mincho, GO stands for Gothic, RG stands for Round Gothic, KA stands for Samurai typeface, and KY stands for Textbook typeface. In FIG. 35, MIN represents Mincho, GOT represents Gothic, RGO represents Maru Gothic, KAI represents 楷 typeface, and KYO represents textbook type.
[0124]
FIG. 36 shows style width information. There are two types of styles, regular and italic, and width information includes extra condence, condence, regular, expand, and extra expand. With this combination, for example, as shown in the figure, “1” is assigned in the case of regular and extra condence. Similarly, “1” is assigned to regular and condence, “2” is assigned to regular and regular, “3” is assigned to regular and expand, and 4 is assigned to regular and extraexpand. Also, “5” is assigned to italicr and extra condence, “6” is assigned to italic and condence, “7” is assigned to italic and regular, “8” is assigned to italic and expand, and “9” is assigned to italic and extra expand. .
[0125]
FIG. 37 shows weight information. In the embodiment, numerals 1 to 9 are assigned to special, extra-thin, fine, medium-thin, medium, middle-thick, thick, extra-thick, and extra-thick.
[0126]
FIG. 38 shows size / support area information in the embodiment. The size data is represented in hexadecimal using the upper 8 bits of this data ("1" to "F" in terms of characters). In the case of scalable typeface data such as outline data, the number “0” is used. Also, each area is assigned to the lower 8 bits, and if it is a corresponding area, that bit is set to “1”. In the embodiment, bit 7 is a non-Kanji area, bit 6 is a first level area, bit 5 is a second level area, bit 4 is an old JIS area, bit 3 is a kana area, bit 2 is a proportional area, and bit 1 is an external character area. Bit 0 is set as a special area.
[0127]
The file name is determined as described above. Hereinafter, typeface information and an example of determination based on the typeface information will be shown.
[0128]
Typeface information {1. Typeface name: Mincho, 2. Style name: regular, 3. Character width information: condence, 4. Character weight information: Medium, 5. Character size: 100 dots, 6. Support area, first level, 7. Metric information identification information: “P” because it is the same metric information as the printer font, file classification with 8 extensions: JFD (typeface physical data file) and FON (typeface logical data file), 9: typeface management environment name: FontManaging }.
[0129]
In this case, in order to determine the name of the typeface physical data file, (5) shown in FIG. 32 becomes “JFD”. (1) becomes “MI” according to FIG. Further, (2) is “1” according to FIG. 36, and (3) is “5” according to FIG. When the size 100 is expressed in hexadecimal, it is 64H, and since only bit 6 is set according to FIG. 38, the lower 8 bits are 40H, and therefore (4) is “6440”.
[0130]
That is, the file name is “MI156440.JFD”.
[0131]
Next, in the case of a typeface logical data file, the extension {circle over (5)} is unified to represent “FON”, and {circle over (6)} represents FontManager, so “FO_, {circle over (1)}” is “MIN”, 3 is “5” and FIG. 8 is “P” according to FIG.
[0132]
Therefore, the name of this typeface logical data file is “FM_MIN5P.FON”.
[0133]
As described above, according to the eighth embodiment, the information indicating the data stored in the file is displayed in the typeface file name, so that the information stored in the typeface file can be easily understood. .
[0134]
<Description of Ninth Embodiment>
A ninth embodiment will be described.
[0135]
Normally, for character pattern generation, a bitmap pattern is stored in advance as described above, a bitmap font method for obtaining the pattern, and outlines of the character are formed based on the outline data, and the inside of the character pattern is filled. There is an outline font method that obtains character patterns.
[0136]
The former is an effective method for relatively small characters (characters with a small dot configuration), and the characters are not crushed, and even if they are generated, they can be thinned out to the basic character pattern. High-speed processing is possible. The latter requires a process of drawing an outline with a rasterizer and filling the inside thereof, so that the speed is reduced, but the quality of large characters (characters having a final dot configuration) can be improved.
[0137]
However, with the bitmap font method suitable for generating relatively small characters, a character pattern that is required with a relatively high probability and a character pattern with a low probability are performed with uniform processing from the basic character pattern. There is still room for improvement.
[0138]
In the ninth embodiment, the generation method using the bitmap font is further improved.
[0139]
In the ninth embodiment, an example will be described in which a bitmap font of 20 × 20 dots is resourced, and then a character pattern of 4 × 4 to 20 × 20 is generated.
[0140]
FIG. 39 is a flowchart showing a procedure of character pattern generation processing using a bitmap font in the embodiment.
[0141]
First, in step S1, the requested character code and character size are acquired. In step S 2, the character pattern (20 × 20 dots) of the requested character code is taken out from the ROM 102 or the external storage device 109 and developed in a predetermined area in the RAM 103.
[0142]
In step S3, the number of vertical lines that can be reduced without deformation in one process is calculated. If the requested character size is less than half of the previously acquired character size (20 × 20), the character size is obtained up to half of the character pattern; otherwise, (character size before reduction + 2) / 5 is obtained. . This formula is mainly intended to prevent deformation (bias) by limiting the number of lines to be reduced once to 4 lines or less when limited to character patterns of 20 × 20 dots or less.
[0143]
When the process proceeds to step S4, an actual reduction process is performed. Here, reduction processing for the line obtained in step S3 is performed. At this time, the position where the reduction process is performed is an equal division position obtained by the width of the character pattern / (number of reduction lines + 1). Here, when the number of reduced lines = 2, the denominator becomes an odd number, so that there is a possibility that the equal division cannot be performed correctly and deformation is performed (see FIG. 40). Therefore, correction processing is performed to shift the position by the remaining amount generated from the calculation of the reduction position at the time of the second reduction. This is shown in FIG. Also, when the number of reduction lines = 4, the denominator is an odd number, but when the character pattern before reduction is 20 × 20 dots or less, there is no problem, so no particular processing is performed. In the calculated vertical line, a dot pattern of one line is generated by superimposing (logical sum) processing with the right adjacent line, in other words, by the position of the line to be reduced and the right adjacent line. .
[0144]
In step S5, it is determined whether the reduction result has reached the requested size, and the determination is made based on the difference between the total number of reduced lines and the number of lines reduced in step S4. If the result of determination is that the requested size is not reached, the process returns to step S3 and the reduction process is repeated. If the creation of the requested character pattern is completed, the character pattern generated at the request source is output in step S6.
[0145]
In the above description, the meaning that the number of lines to be reduced in one reduction process is reduced to 4 or less means, for example, when a 12 × 12 pattern is generated from a basic size of 20 × 20 (finally 8 lines). (= 20-12) is reduced) In the first time, instead of reducing all 8 lines, it means that 4 lines are reduced in the first time, and then 4 lines are further reduced. To do. Incidentally, as described above, when reducing by 2 lines, that is, when an 18-line character pattern is generated, there is no problem because the number of reduction lines is 4 or less. However, the correction process described above is performed.
[0146]
In the ninth embodiment, an example of reducing in the horizontal direction has been described. However, reduction in the vertical and vertical directions can be processed in exactly the same way, and further, both vertical and horizontal can be processed. However, the present invention is not limited thereto.
[0147]
In addition, the bitmap to be used is not limited to 20 × 20, and is not particularly limited as long as the processing can be efficiently performed when reducing each size.
[0148]
In addition, multiple bitmap fonts of the minimum size that can be acquired in one process of “(character size before reduction + 2) / 5” such as 20 × 20, 16 × 16, 13 × 13, 10 × 10, etc. are prepared in advance. However, the number of loops in steps S3 to S5 may be reduced and used for improving the quality.
[0149]
As described above, according to the ninth embodiment, a bitmap font is used only for a size (4 × 4 to 20 × 20) that is most likely to be used when the requested character pattern size is the main text creation or the like. It is possible to reduce the character pattern with good performance by simplifying the calculation of the position to be used and the like so as to be most effective for the limited size.
[0150]
<Description of Tenth Embodiment>
The tenth embodiment will be described.
[0151]
In the above embodiment (for example, the eighth embodiment), the file name reflects the data that the file has. Therefore, when the type providing side newly provides a name different from the name supplied in the past, it may be managed to give a different file name. However, if the system user can create a typeface, the supply side cannot manage the file name used by the user. Therefore, there is a case where a typeface with the same information is created, and it is necessary to copy the typeface created after deleting the typeface containing the same information, or after changing the corresponding typeface information of the same information. .
[0152]
In the tenth embodiment, this problem is solved.
[0153]
FIG. 42 shows an example of the file name given to the typeface information file in the embodiment. As shown in the figure, in the tenth embodiment, 8 characters (8 bytes) are used for the file name portion and 3 characters (3 bytes) are used for the extension. In this embodiment, “FG_US” is assumed to be fixed, and “□” shown thereafter is given the same value as the typeface number. However, the method of naming the file is not limited to this.
[0154]
FIG. 43 shows the internal structure of the typeface information file. In this typeface information file, a typeface name indicated by reference numeral 14 and a typeface number indicated by reference numeral 15 are stored. In addition, for example, information such as creation date and version and version is also stored.
[0155]
FIG. 44 shows the structure of a typeface storage information file that manages the storage destinations of the typefaces stored in the external storage device 109, and contains information about all the typefaces stored. In this typeface storage information file, there are a registration number of typeface 1 indicated by reference numeral 16, a typeface information file name of typeface 1 of reference numeral 17, a typeface name of typeface 1 of 18, and a typeface number of typeface 1 of 19. Similarly, the same information is stored for each of the typefaces 2,.
[0156]
A typeface management procedure in the tenth embodiment will be described based on the flowchart of FIG.
[0157]
First, in step S501, the typeface information is acquired from the typeface information file of the copy source (typeface information file managing the typeface data created by the user, see 43). In step S502, typeface information relating to the typeface stored is acquired from a typeface storage information file (see FIG. 44) under the control of the system.
[0158]
In step S503, it is determined from the information acquired in previous steps S501 and S502 whether or not a font with the same font name is stored. If it is determined that a typeface with the same typeface name is already stored in the typeface storage information file, the process proceeds to step S504. If it is determined that the typeface name is not registered in the system, the process proceeds to step S507.
[0159]
Here, it is determined that the same font name is not registered in the system, and in step S507, it is determined whether the same font number as the font number of the font created by the user is registered in the system. If it is determined that there is no same typeface, the process proceeds to steps S512 and S513, and the contents of the typeface information file created by the user are copied to the typeface storage information file storing the typeface information registered in the system. (Add) and update the typeface storage information file.
[0160]
On the other hand, if it is determined in step S503 that a font with the same font name has already been registered, the process proceeds to step S504, where it is determined whether or not they are the same font number.
[0161]
If it is determined that the typeface number is the same, that is, both the typeface name and typeface number are already registered in the system, the process proceeds to steps S505 and S506, and the user enters the corresponding position in the typeface storage information file. Overwrites with the contents of the created font information file and updates the font storage information file.
[0162]
If it is determined “YES” in step S507, that is, if it is not the same typeface name but the same typeface number, the process proceeds to step S508, and the typeface to be newly registered is used. A typeface number that is not present is detected, and the process proceeds to step S509.
[0163]
If the determination in step S504 is “NO”, that is, the same typeface name exists but the typeface number is different, the process proceeds to step S509. In this case, the typeface number will not overlap.
[0164]
In any case, the processing in step S509 is the case where the typeface name is the same and the typeface number is different. The typeface name is important from the user's side. If there are multiple typeface names, it can be confusing. Therefore, in steps S509, S510, and S511, the typeface name file to be registered is changed (for example, “USR” is added to the typeface name), and the changed typeface name is added to the typeface storage information file. In addition, the typeface storage information file is updated by registering with the typeface number.
[0165]
In the above example, the typeface name is used as key information to determine the registration status of the typeface, the typeface number is matched with the file name of the typeface information file, and the typeface containing the same typeface information is copied by changing the typeface number. It becomes possible to manage. In addition, the present invention provides a tool that allows a user to create a typeface, and exhibits a great effect when the typeface created by the tool is used.
[0166]
In the above embodiment, the typeface name is searched for the typeface information and the typeface number is changed. However, the typeface number may be used for the search and the typeface name may be changed. This is not the case for the key information used for and the typeface information to be changed.
[0167]
As described above, according to the tenth embodiment, the typeface information is associated with the file name of the typeface information file, and when a typeface containing the same typeface information is detected, the typeface information is changed and copied (registered). ), It is possible to manage the typeface even when the same typeface information is included.
[0168]
In addition, when the user can create a typeface, even if a typeface with the same information is created, the typeface created after deleting the typeface that contains the same information is copied or the typeface that corresponds to the same information It is possible to reduce the work of copying after changing the information.
[0169]
The present invention is not limited to the first to tenth embodiments, but may be applied to a system constituted by a plurality of devices or an apparatus constituted by one device. Needless to say, the present invention can also be applied to a case where the present invention is achieved by supplying a program to a system or apparatus.
[0170]
【The invention's effect】
As described above, according to the present invention, it is possible to provide a flexible typeface data management method.
[Brief description of the drawings]
FIG. 1 is a system configuration diagram according to an embodiment.
FIG. 2 is a RAM memory map according to the embodiment.
FIG. 3 is a diagram illustrating a configuration example of a character processing device.
FIG. 4 is a diagram illustrating a configuration example of a divided file according to the first embodiment.
FIG. 5A is a diagram showing an example of the contents of a typeface information file in the first embodiment.
FIG. 5B is a diagram showing a configuration example of a typeface file after installation in the first embodiment.
FIG. 6 is a diagram illustrating an example of contents of a typeface management information table according to the first embodiment.
FIG. 7 is a flowchart illustrating a procedure of a typeface management information table creation process in the first embodiment.
FIG. 8 is a flowchart showing a flow of character data acquisition processing in the first embodiment.
FIG. 9 is a diagram illustrating an example of an initial state of a typeface management information table according to the second embodiment.
FIG. 10 is a flowchart showing a flow of character data acquisition processing in the second embodiment.
FIG. 11 is a diagram illustrating an example of an intermediate state of a typeface management information table according to the second embodiment.
FIG. 12 is a diagram illustrating an example of the contents of a typeface information file updated in the second embodiment.
FIG. 13 is a diagram illustrating an example of a state of a typeface management information table when activated with the contents of an updated typeface information file according to the second embodiment.
FIG. 14 is a diagram illustrating a configuration example of a divided typeface file according to a third embodiment.
FIG. 15 is a diagram illustrating an example of the contents of a typeface information file according to the third embodiment.
FIG. 16 is a diagram illustrating a content example of a typeface management information table according to the third embodiment.
FIG. 17 is a flowchart illustrating a flow of processing for creating a typeface management information table according to the third embodiment.
FIG. 18 is a diagram illustrating an example of the contents of a typeface information file according to the fourth embodiment.
FIG. 19 is a diagram illustrating a content example of a typeface management information table according to the fourth embodiment.
FIG. 20 is a diagram illustrating a configuration example of a divided file according to the fifth embodiment.
FIG. 21 is a diagram showing an example of the contents of a typeface file in the fifth embodiment.
FIG. 22 is a diagram illustrating a content example of a typeface management information table according to the fifth embodiment.
FIG. 23 is a diagram illustrating a configuration of a divided typeface file according to the sixth embodiment.
FIG. 24 is a diagram illustrating an example of the contents of a typeface information file according to the sixth embodiment.
FIG. 25 is a diagram illustrating a content example of a typeface management information table according to the sixth embodiment.
FIG. 26 is a diagram illustrating a format of style width weight information according to the seventh embodiment.
FIG. 27 is a flowchart showing a typeface installation procedure in the seventh embodiment;
FIG. 28 is a diagram showing the contents of an installation medium and the contents of an installation data file in the seventh embodiment.
FIG. 29 is a diagram illustrating an example of the contents of a typeface information file according to the seventh embodiment.
FIG. 30 is a diagram showing an example of the contents of a tag file in the seventh embodiment.
FIG. 31 is a diagram illustrating an example of the contents of a typeface file according to the seventh embodiment.
FIG. 32 is a diagram illustrating a character structure used for a file name of a typeface physical file according to the eighth embodiment.
FIG. 33 shows a structure of a file name of a typeface logical data file of typeface data in the eighth embodiment.
FIG. 34 is a diagram showing various character strings representing identification information of a physical typeface in the eighth embodiment.
FIG. 35 is a diagram showing various character strings representing identification information of a typeface logical data file according to the eighth embodiment.
FIG. 36 is a diagram showing the meaning content of style width information in the eighth embodiment.
FIG. 37 is a diagram showing the meaning content of weight information in the eighth embodiment.
FIG. 38 is a diagram showing the relationship between size and support area in the eighth embodiment.
FIG. 39 is a flowchart showing the processing content related to reduced character pattern generation in the ninth embodiment;
FIG. 40 is a diagram illustrating a problem of reduction processing in the ninth embodiment.
FIG. 41 is a diagram illustrating a reduction process after correction in the ninth embodiment.
FIG. 42 is a diagram illustrating a format of a name of a typeface information file according to the tenth embodiment.
FIG. 43 is a diagram illustrating an internal structure of a typeface information file according to the tenth embodiment.
FIG. 44 is a diagram illustrating the structure of a typeface storage information file according to the tenth embodiment.
FIG. 45 is a flowchart illustrating a typeface registration process according to the tenth embodiment;
[Explanation of symbols]
101 CPU
102 ROM
103 RAM
104 Keyboard control unit (KBC)
105 Keyboard (KB)
106 Display Control Unit (CRTC)
107 Display device
108 DKC
109 External storage device
110 Printer control unit
111 printer

Claims (14)

In a typeface data management method for retrieving data about a requested character from a typeface data file,
In the first typeface, among the partial code spaces each consisting of continuous codes, the typeface data file corresponding to any partial code space is held in common with the second typeface, and the typeface management information is held.
When there is a character request including a code in the first typeface, the typeface data is obtained from the commonly used typeface data file if it corresponds to the range of any partial code space based on the typeface management information. A typeface data management method characterized by that. The typeface data file corresponding to any one of the partial code spaces is composed of dot pattern data, and the typeface data file corresponding to the partial code space other than any of the partial code spaces is composed of outline font data. The typeface data management method according to claim 1. 3. The typeface data management method according to claim 1, further comprising registration control means for making the common typeface data file dependent on the first typeface. 4. The typeface data management method according to claim 1, wherein the typeface data file corresponding to the partial code space is managed by a file name. 5. The typeface data management method according to claim 1, wherein any one of the partial codes corresponds to any character set. 6. The typeface data management method according to claim 1, wherein the typeface is a typeface that includes Chinese characters. In a typeface data management method for retrieving data about a requested character from a typeface data file,
Holding typeface management information for using the typeface data of any partial code space of the second typeface for any partial code space consisting of continuous codes in the typeface data file of the first typeface;
When there is a character request including a code in the first typeface, if it is identified as a code included in any of the partial code spaces based on the code for which the character request is made and the typeface management information, the first typeface Acquire typeface data of any continuous partial code space from the typeface data file of two typefaces.
A typeface data management method characterized by that. In a typeface data management device for retrieving data about a requested character from a typeface data file,
Holding means for holding typeface management information for allowing a typeface data file corresponding to any partial code space in the first typeface to be used in common with the second typeface among partial code spaces each consisting of continuous codes When,
When there is a character request including a code in the first typeface, the typeface data is obtained from the commonly used typeface data file if it corresponds to the range of any partial code space based on the typeface management information. A typeface data management apparatus comprising an acquisition means . The typeface data file corresponding to any one of the partial code spaces is composed of dot pattern data, and the typeface data file corresponding to the partial code space other than any of the partial code spaces is composed of outline font data. The typeface data management device according to claim 8. The typeface data management apparatus according to claim 8 or 9, further comprising registration control means for making the typeface data file used in common dependent on the first typeface. The typeface data management apparatus according to any one of claims 8 to 10, wherein the typeface data file corresponding to the partial code space is managed by a file name. 12. The typeface data management apparatus according to claim 8, wherein any one of the partial codes corresponds to any character set. The typeface data management apparatus according to any one of claims 8 to 12, wherein the typeface is a typeface that includes Chinese characters. In a typeface data management device for retrieving data about a requested character from a typeface data file,
Holding means for holding typeface management information for using the typeface data of any partial code space of the second typeface for any partial code space consisting of continuous codes in the typeface data file of the first typeface;
When there is a character request including a code in the first typeface, if it is identified as a code included in any of the partial code spaces based on the code for which the character request is made and the typeface management information, the first typeface Means for obtaining typeface data of any partial code space from a typeface data file of two typefaces;
A typeface data management apparatus comprising:

Images