JPH05233510A - Character data management method - Google Patents

Abstract

(57) [Abstract] [Purpose] By allocating the font cache memory to both the character output request side device and the character image data supply device on the network, character data generation is processed at high speed. [Structure] A dedicated device (font server) that performs processing of generating character image data from outline font original data is connected to a network, and a device that outputs characters on the network is a device that outputs character image data from the font server. Receive supply. Here, both the requesting computer and the font server have a memory area called a font cache for holding character image data, and the contents of the font server's cache memory and the contents of the character requesting computer's cache memory. Is controlled so that the character data once converted into image data is used as repeatedly as possible to reduce the execution of generation processing from outline original data.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a high-speed outline font generation system in a system in which a plurality of personal computers and workstations are connected via a network. Further, the present invention relates to a management system of a memory structure (so-called font cache) that temporarily stores pixels used for font formation.

[0002]

2. Description of the Related Art As a conventional device, Japanese Patent Laid-Open No. 2-5809
There is a device described in 4. In this device configuration,
A character data management device called a font server is connected to a network, and a workstation, a printing device, etc. are connected to this same network. Here, the workstation or the printing device is a client in which an application program (print control program in the case of a printing device) accompanied by character output operates and requests the font server for the character data to be output.
Also, a mechanism called font cache is used. The font cache is an effective mechanism for speeding up the processing when the character shape data is recorded in the outline font format. In the outline font, the original data of the character shape is described as a data string that contains information such as the coefficient term of an appropriate curve (for example, Bezier curve, parabola, etc.) that represents the contour forming the character shape, and specification of the curve type ing. Therefore, display, printing, etc.
When outputting as a character to some output device, the original data must be converted into a set of pixel data according to the size specification. However, this conversion process generally consumes a lot of processing time. In the case of complicated Kanji characters,
This is even more pronounced. Therefore, for character data that has already been converted into pixels, the converted pixel data is temporarily stored in the memory, and when an output request for the same character occurs, without converting from the original data to pixels, The method of using the pixel data already recorded in this memory is adopted. Here, the memory that stores the character shape data converted into pixels is called a font cache. In the device described in Japanese Patent Laid-Open No. 2-58094, a font cache mechanism is realized on the device side (that is, the client side) that outputs characters such as a workstation and a printing device connected to a font server by a network. .. The advantages of such a conventional method are mainly the following three. (1) Since character data can be shared by all devices on the network, resources such as an auxiliary storage device for storing character data can be effectively used.

(2) Since character data can be centrally managed, operations such as changing, adding and deleting character data are easy and maintainability is excellent.

(3) Even if the character data requires special processing, only the font server needs to perform the processing.

On the other hand, the problems of the conventional method are as follows.

(1) The font server is the only source of character data to the client machine, and character output is rate-limited by the font server's ability to supply character data when the local font cache does not work effectively.

If the client machine switches the character type of the display font, the character data currently in the font cache cannot be reused. Therefore, for the subsequent character output, a request is made to the font server for each character for a while. Here, if a plurality of client machines simultaneously change the display character type, requests to the font server will be concentrated.
As described above, in outline fonts and the like, character generation is a heavy load on the processor. Responding to requests from a plurality of devices causes a decrease in processing speed as well as a load on a processing program associated with the network.

The utilization rate of the font cache and the local response on the client machine can be improved by improving the cache management method. For example, as a conventional technique invented for the purpose of improving the efficiency of a font cache management method, there is JP-A-64-88660 "font cache control system". However, in order to improve the processing speed of the font server system for use on the network, it is necessary to solve the bottleneck part, and even if the local response speed on the client machine is improved. However, there was a problem that it did not lead to the final speedup of character output.

[0009]

As described above, in using a font server in a network, it is an object to develop a technique for effectively utilizing the processing speed of the font server as much as possible. One way to solve this is to implement a font cache in the font server as well to further increase the processing speed of the font server. However, when this method is used, how to maintain the relationship between the contents of the local font cache of the client machine such as the workstation and the printing device and the contents of the font cache of the font server becomes a problem. The font cache on the font server is, as it were, a global cache on the network, and it is not necessary to hold the same character data as in the local cache on the client machine side. Rather, it is inconvenient to have the same data in the contents of the local cache and the global cache in view of the limited utilization rate of the cache memory. Therefore, there is a problem of how to keep the contents of the font cache on the font server side and the contents of the font cache of each client machine inconsistent.

[0010]

In order to solve the above problems, the present invention provides a system in which a plurality of devices for performing character output operation and one or more devices having character data resources are connected by a network. For devices that perform character output operations, the data that represents the character type of the character to be output, the character modification specification, the character size specification, and the character shape described by the character code specification is the specified memory area. (Hereinafter referred to as "local font cache"), a means to search for the existence, and a means for passing the character data to the process that generated the character output request if there is data for the character by this search, and this search If there is no corresponding character, the character of the character is sent to the device (hereinafter referred to as font server) that has a predetermined character data resource on the network. , Character modification specified, the character size specified,
It has a means for transmitting a request message prompting to transfer the pixel data representing the shape of the character described by the character code specification, and receiving the character data obtained as a response. The character data obtained as a response is the local data. If you try to register in the font cache and there is no free space in the local font cache, take out the unnecessary character data, create a free space, and register it. A configuration is provided that has a means for adding a request message prompting registration to a specific memory area specified in advance on the device (hereinafter referred to as a global font cache), and transferring it.
Regarding the font server on the network, the characters described by the character type, character modification specification, character size specification, and character code specification from other devices on the network,
The means for receiving the character acquisition request, the means for searching for the data representing the shape of the character received by this means in the specified specific memory area, and the data for the corresponding character by this search If there is, the means for reading this data and passing it to the information device that issued the character output request, and if there is no corresponding character by the search, the pixel data representing the shape of the specified character is extracted from the outline font data. This pixel data is generated by the arithmetic processing and is sent to the device that generated the character acquisition request.
If you have a means to send, and if you receive a message requesting registration of character data from another device on the network, try to register in the global font cache,
When the empty area cannot be obtained, it is characterized in that it has means for deleting the unnecessary character data, creating an empty area, and performing the registration.

[0011]

FIG. 1 is a block diagram of an embodiment of the present invention. The network 3 is a mechanism for establishing bidirectional high-speed communication between a plurality of devices. Each of the plurality of devices connected to the network 3 has a unique network address. Communication between the devices is performed by transferring a data string including network addresses of the transmitting device and the receiving device. This data string is usually called a packet. Each device acquires a packet when the transfer destination address in the data string in the packet is its own address. Also, the address of the device that transmitted the packet is extracted from the data string in the packet, and a response is sent back to the device at that address. As a realization example of these mechanisms, IEEE standard 802 is widely used.

In the configuration of FIG. 1, the device 1 and the device 2 are connected to the network 3. Needless to say, more devices are actually connected to the network 3 and used. Here, the device 1 is a computer that requests character output, and the device 2 is a font server.

(A) Outline of Operation on Character Output Requesting Side First, an outline of the operation of the computer 1 which requests character output will be described.

In the computer 1, the application 1
1 is used. When the application 11 displays a character, the character is represented as a set of pixels generated according to the resolution of the display device. Hereinafter, a set of pixels representing a character shape will be referred to as character image data. Image data of characters used for display is supplied to the application 11 by an application interface prepared by the computer 1. Font management mechanism 1
2 is part of the application interface,
The operation of receiving the character designation record from the application 11 and returning the image data of the character to 11 is performed. Here, the character designation record has a data structure including the following elements.

Name of data structure: Character specification record Element 1: Character code 2 bytes Element 2: Font specification 2 bytes Element 3: Character size specification 2 bytes Element 4: Character modification specification 6 bytes However, for a certain character, When a plurality of character designs are made, it is a name used to specify the difference in character shape. In the above data structure, a numerical value is assigned to this name for use. In addition, the character modification designation is a designation that the shape of the target character is the operation target such as italicized characters and white characters, regardless of the character typeface. The expressions are digitized.

The font management mechanism 12 receives the character designation record and accesses the font cache system 13 in the operation of returning the image data of the character to 11. This operation will be described later.

(B) Outline of Operation on Character Image Data Supply Side The outline of the operation of the font server 2 will be described with reference to the block diagram of FIG.

The other device connected to the network 3 sends to the font server 2 a packet requesting the transfer of character image data. Upon receiving this request, the font server 2 transfers the request to the font management mechanism 16.
The font management mechanism 16 extracts a character designation record from the requested data string, and the image data of the character matching the designation is obtained by the means described later by the font cache system 1.
Check if it exists in 5. If it exists, the character designated record is converted into a key, the image data is obtained by the key designation, and the image data is transferred to the device which issued the request. If the data does not exist, the font generation mechanism 17 is requested to generate the font. Upon receiving this, the font generating mechanism 17 uses the font data reading mechanism 18 to read the font original data from the auxiliary storage device 19. The read font original data describes the font as an outline font. The font generation mechanism 17 generates image data for each character based on this data. The generated image data is sent to the font management mechanism 16 and transferred to the device that has made the request.

(C) Font Management Operation The font management operation will be described below in terms of the relationship between the font server on the network and the device that issues the request.

As a font cache memory management method used by the font management mechanism, there are some known methods. Basically, the cache memory is a finite length memory allocation, and when new image data of a character is to be registered and the free space of the memory cannot be secured, the current registration is updated. That is, unnecessary data (image data of any character here) is deleted from the cache area, and new data is registered. The important management method is to retain the necessary data and delete unnecessary data. However, since there is no ideal method for predicting what kind of character data will be requested in the future, unnecessary data will be determined according to some standard. If this determination is appropriate, the probability that the requested character data will exist in the cache area (hit rate) will improve, leading to an improvement in processing speed. There are the following four typical management methods for determining unnecessary data.

Method 1: It is determined that the earliest registered data in the current data group is unnecessary. So-called Firs
t In First Out (FIFO) method.

Method 2: In the current data group, the data that has not been used for the longest period is judged to be unnecessary. The so-called Least Recently Used (LRU) method.

Method 3: A method in which the data that has not been used for the longest period in the current data group is rather used next, and the recently used data is determined to be unnecessary.

Method 4: It is judged that the least frequently used data in the current data group is unnecessary. So-called Least
Frequently Used (LFU) method.

Among the conventional methods, for example, Japanese Patent Laid-Open No. 64-886.
The 60 "font cache control method" uses a method obtained by improving the method 3 with respect to the method 1. In addition, JP-A-2-
202464 "Printer" uses Method 1.

These management schemes are methods invented for configurations that use a single font cache memory for a single font management mechanism. (To be more precise, the method invented with regard to memory page allocation in the virtual memory system is simply diverted to the management of the font cache.) Therefore, as in this embodiment, the font cache system 13 of the computer 1 is used. , Font server 2
If there are multiple font cache systems 15 of, the algorithm cannot be said to be optimal. As described above, in the present invention, the contents of the font cache on the font server side and the contents of the font cache of each client machine are kept inconsistent.

In this embodiment, the Least Recently Used (LRU) method is used for local management of the cache.

(D) Font cache management method The font cache management method will be described.

(D1) Font Cache System FIG. 2 is a block diagram of the font cache system 13. The configuration of the font cache system 15 is similar to that shown in FIG. However, as described above, since the font server 2 has a different management method, it is distinguished by a different number.

The main components of the font cache system 13 are a cache memory 205 and a cache allocation process 207. The cache memory 205 is a memory having a continuous address arrangement of finite length. Inside is 1
It is a set of management unit memories 201 having a size of 28 bytes. The management unit memory 201 includes a data part 204 having a size of 126 bytes and an index part 203 having a size of 2 bytes. The content of the index unit 203 is an index to the management unit memory that should be continued next. Since the size of the management unit memory 201 is fixed, the value of the real address can be obtained from the index value by a simple calculation. That is, when the index value is ix, the head address of the management unit memory 201 that should be continued next is obtained as the value addr of the following equation.

Needless to say, the value 128 comes from the size of the management unit memory, and this operation is only an example of conversion into a real address. The index unit 203 of the management unit memory 210 is one of the variants of so-called concatenated pointers.

On the other hand, actual character image data is stored by using a sub-number of data units 204 of the management unit memory 201. The content of the stored data is the number of management unit memories 201 used by the first 2 bytes, and the data following this is image data. Further, all the image data consist of a run-length compressed data string.

As is well known, as a memory management method, there is a method of dynamically arranging a variable length data string on a continuous memory. When this method is used, after repeated registration / deletion to / from the cache, a plurality of empty areas having irregular sizes due to unnecessary data strings occur.
In order to reallocate such unnecessary fragmented memory resources and recreate a large continuous free area,
It is necessary to perform processing that takes a long time to execute, including memory block movement. On the other hand, the means for using a plurality of fixed-length management unit memories adopted in the present embodiment is inferior to the dynamic memory management in terms of memory utilization rate because an unused portion occurs in the last-end management unit memory. Is. However, since the management is simple, it can be easily implemented as hardware, and even if the management program is executed by software, high speed processing is excellent.

Next, the cache allocation processing 207 will be described.

Regarding the characters registered in the cache,
The image data is divided and stored in a plurality of management unit memories 201 starting from any management unit memory 201 in the cache memory 205. At this time, the index of the first management unit memory 201 is stored in the address table 208 and used. In this embodiment, the address table 208 is an array composed of 300 elements. Also, one element is made up of two data types, a key value 209 and an index value 210. The cache memory 205 has a size of about 128 kbytes and is a set of 1024 management unit memories 201 described above.
The index of 300 designated in advance in this set is stored in each element of the address management table 208. Here, 300 recorded in the address management table 208
300 management unit memories may be continuously specified from the beginning of the cache memory 205. The contents of the address management table are fixed and do not change during operation.

In this embodiment, up to 300 characters can be registered in the font cache, and in this case, the image data per character is 430 bytes on average.

The cache allocation processing 207 is realized as a processing program in this embodiment. Figure 7
The configuration of the cache allocation processing 207 is shown. The cache allocation process 207 performs the following three operations.

(1) Operation of receiving the value of the key 212 from the outside and returning the image data 206 (reading process 7
01).

(2) An operation of receiving the value of the key 212 and the image data 206 from the outside and registering them in the font cache (writing process 702).

(3) An operation of receiving the value of the key 212 from the outside and deleting the registration from the font cache (connection cancellation processing 703).

In any case, the cache allocation processing 207 determines the address table 208 from the value of the key 212.
, A target index value 210 corresponding to the key value 209 in the table is extracted, converted into a real address by the real address calculation unit 704, and a pointer 21 pointing to the memory
1 is generated. The pointer 211 is used to sequentially specify the contents of the address bus of the cache memory 205 by a method described later, and the image data 20 is transferred from the data bus 706.
6 is taken out or written. The operation of each process will be described below.

(D1-1) Reading of data Cache allocation processing 207 at the time of reading data
Calls the read processing 701 using the received key as an argument. A flow chart of the read process 701 is shown in FIG. The reading process 701 takes out the key (S101).
According to the pointer 211 generated by the address calculation unit 704 (S102) (S103), the head of the character image data storage in the cache memory 205 is found (S10).
4) The character image data 206 is successively read according to the index to the connected management unit memory 201 (S1).
05). As already mentioned, the contents of the stored data are
Since the first 2 bytes are the number of management unit memories 201 to be used, a required number of management unit memories 201 can be connected. Further, the content of the index portion 203 of the management unit memory 201 located at the end of the series of connections is -1 (1
Hexadecimal number FFFF).

(D1-2) Deletion of registration from font cache The management unit memory 201 from which data has been deleted or the management unit memory 201 with blank data has another value because the value of the index portion 203 is 0000. Unit memory 201
Distinguished from. When deleting the image data, the font management mechanism 16 passes the key 212 corresponding to the character data to be deleted to the font cache system 13. In the font cache system 13 side processing, this key 21
2 is transmitted to the cache allocation processing 207. The cache allocation processing 207 calls the connection cancellation processing 703. A flow chart of the connection cancellation processing 703 is shown in FIG.
The connection release processing 703 further calls the address calculation unit 704 (S201). Address calculation unit 704
Searches the address table 208 from the key value 209, and extracts the index value 210 of the first management unit memory 201 in which the character data to be deleted is recorded. Next, the value of this index is converted to a real address by calculation,
A pointer 211 pointing to the memory is generated (S20
2). Thereafter, the connection cancellation processing 703 calculates the real address of the head address of the next management unit memory 201 from the index unit 203 of the management unit memory 201 indicated by this pointer, and replaces the contents of the index unit 203 following it with 0000 one after another. (S
204). This operation is repeated as long as the management unit memory 201 continues to be connected until the content of the index portion 203 reaches the management unit memory 201 (hexadecimal number) FFFF. After this, the index unit 203 of the final management unit memory 201 for connection
Is rewritten from FFFF (in hexadecimal notation) to 0000 (S205).

(D1-3) Registering data in the font cache When registering data in the font cache,
The key 212 and the image data 206 are passed, and the writing process 702 called by the cache allocation process 207 is executed. A flow chart of the write process 702 is shown in FIG. In the writing process 702, the value of the index is set to 2 by extracting the key value from the key 212 (S301) and designating the key value 209 of the address table 208.
Read 10. The address calculation unit 704 converts the index value 210 (S302) into a pointer to the start address of the first management unit memory 201 that can be used for writing image data (S303). Next, the write processing 702 writes the content of an integer value (2 bytes) obtained by dividing the total data size of the image data by "management unit memory size-2" in this management unit memory 201 (S30).
4). This is the management unit memory 201 required for data storage.
Match the total number of. Next, image data up to the size of the data section 204 is written in succession to the 2-byte data (S305). Further, if there is the number of remaining bytes of the image data, the writing process first writes this data in the overflow area 213 (S306), and the unused management unit memory 2 in the cache memory 205.
Search for 01 (S307). If an unused management unit memory 201 can be found, 126 can be retrieved from the overflow area 213.
Byte (this is the data unit 20 of the management unit memory 201)
Data of size 4) is extracted and written (S305). Furthermore, the index unit 203 of the previously accessed management unit memory 201 is set to the current management unit memory 20.
The index to 1 is written and a new bond is generated (S30).
8). If the contents of the overflow area 213 becomes empty,
Repeat until the unused management unit memory 201 is exhausted. When there is no remaining data in the overflow area 213,
The writing process ends normally. In this case, the contents of the index portion 203 of the last-used management unit memory 201 are rewritten to the value FFFF indicating the end of the connection to generate the end of the connection (S309).

On the other hand, when the required number of unused management unit memories 201 cannot be detected and the image data remains in the overflow area 213, the writing process 702 instructs the calling cache allocation process 207 to A write error is returned (S310) and the process is stopped. In this case, it is necessary to remove unnecessary character data from the font cache memory 205, expand the free area, and call the write processing 702 again. This processing is determined and executed by the font management mechanism 12. The processing subordination relationship is a relationship in which the registration processing 602 of the font management mechanism 12 calls the cache allocation processing 207, and the cache allocation processing 207 further calls the writing processing 702.

The overflow area 213 is a memory area of consecutive addresses having a sufficiently large capacity for one character data. However, if image data of a character of a size that does not fit in the overflow area 213 is passed, The writing process 702 returns an overflow area error (S311) and stops the process. In this case, the image data of this character is not registered in the font cache. This is because the characters having particularly large image data have an extremely low occurrence frequency, and even if they are registered in the cache, they do not contribute to the improvement of the processing speed of the system.

(D2) Font management mechanism on the font server side FIG. 8 is a block diagram of the font management mechanism 16 on the font server side.

The font management mechanism 16 receives either the character fetch request 22 or the character registration request 21 from the requesting computer 1 via the network driver 14. As already mentioned, sending data over the network,
Reception is performed in packets according to network specifications. The font server 2 side can extract the network address of the sending computer from the data string of the received packet and specify the computer 1 that issued the request.

When the font server 2 side receives the character fetch request 22 and the character designation record 20, the character image data 2 is read according to the contents of the character designation record 20.
06 is generated, and the request is given to the computer 1.

Character registration request 21, character designation record 2
If you receive 0, character image data 206,
The contents of the character designation record 20 are stored in the font management table 8
05, and the character image data 206 is registered in the font cache system 15.

Each operation will be described below. Also,
The configuration of one element of the font management table 805 is shown in FIG.
Shown in. The contents of the key 808 of the font management table are
In the initial state, it is set so as to match the key content 209 of the address table 208 of the font cache system 15, and is not changed thereafter.

(D2-1) Operation when character fetch request 22 is received Font management mechanism 1 that receives character fetch request 22
6 starts the reading process 801. Read process 8
A flow chart of 01 is shown in FIG. The read processing 801 is
The table search process 804 is called (S401), and it is searched whether the same element as the content of the character designation record 20 is registered in the font management table 805.

First, the case where the same element is detected will be described.

In this case, the access counter 809 is set to +
1 (S402). The access counter 809 is a 48-bit long counter that is cleared when the system is started up and is not cleared thereafter.
Then, when the search target is detected and when there is a newly registered element in the font management table 805, the value is incremented by one. In the use state of this embodiment, no overflow occurs. The value of the access counter 809 is recorded in the registration flag 806 corresponding to the detected element (S40).
3). Since the value of the access counter 809 counts the number of times registration and reading are performed, the larger this number, the more recently accessed element can be determined. Then, the key 808 corresponding to the detected element is read. The reading process 801 passes the key 212 to the font cache system 15 to instruct the reading process (S404), and obtains the character image data 206 as a processing result. The font management mechanism 16 transfers the image data 206 to the image data 206 via the network driver 14.
The process is transferred to the requesting computer 1 (S405), and the process is terminated.

On the other hand, the operation when the character designated by the character designation record 20 is not registered in the font management table 805 will be described.

In this case, the read processing 801 passes the character designation record 20 to the font generation mechanism 17 (S4
06), the image data 206 is acquired as the processing result. The subsequent processing is the same as that described above. The font management mechanism 16 transfers this image data 206 to the requesting computer 1 via the network driver 14 (S405), and ends the processing.

(D2-2) Operation when the character registration request 21 is received When the character registration request 21 is received, the font management mechanism 1
6 activates the registration process 802. A flow chart of the registration process 802 is shown in FIG. The registration process 802 calls the table search process 804 (S501). When the character designated record is searched and the same data is already registered, the process ends immediately. Next, font management table 8
The registration flag 806 of 05 is searched (S502), and the element having the smallest value is extracted. Since the access flag 809 at the time of registration or at the time of reading is written in the registration flag, if this value is small, it can be determined that the character data having the registration flag has not been used recently. In this embodiment, when determining the character to be deleted, the character having the smallest value of the registration flag 806 is selected. This determination method is the above-mentioned Least Recently Used (LRU) method. If the value of the read registration flag 806 is 0, it is determined that the element has not been the object of font registration until now, or has just been deleted. Therefore, the contents of the registration flag 806 are set to hexadecimal FFFF.
Rewrite as FFFFFFFF. This is a temporary flag indicating that it is currently in use. Then, the content of the key 808 corresponding to this element is taken out, the key 212 and the image data 206 are transferred to the font cache system 15, and a writing process is instructed (S503). As a return value of the processing result, from the font cache system 15,
If an overflow area error is returned, nothing is done and the registration process ends. This is because, as described in (d1-3), it is determined that the data is not worth registering. Further, in this case, at the end of the registration process, the registration flag 8
The value of 06 is restored to the value before processing.

When a writing error is returned from the font cache system 15 as the return value of the processing result, the registration processing 802 calls the deletion processing 803 (S5).
04). The deletion process 803 uses the table search process 804, and the registration flag 80 of the font management table 805 is used.
6 is retrieved, and the smallest element having a value other than 0 is extracted.
Next, take out the contents of the key 808 corresponding to this element,
The key 212 is substituted and the font cache system 15 is instructed to delete from the cache. The deletion process 803 ends this process, and returns control to the registration process 802.
As a result of this processing, an empty area is generated in the font cache system 15, so that the registration processing 802 again uses the key 2
12 and the image data 206 are transferred to the font cache system 15, and a writing process is instructed. Furthermore, as a return value of the processing result, the font cache system 1
When the write error is returned from 5, the same processing is repeated. If the image data has a size that does not cause an overflow area error, the registration is completed by repeating the processing at least several times. When the writing ends without any error, the contents of the access counter 809 are incremented by 1 at the end of the registration processing (S505), and this value is written in the registration flag 806 (S506).

In the process of retrieving the registration flag 806 of the font management table 805 (S502) and extracting the element having the smallest flag value, if the flag value is other than 0, the connection elimination process 703 is called (S507). ), The character data is deleted from the font cache system 15, and the writing process is continued from S502. When the registration is completed, the font management mechanism 16 returns a processing result of normal termination, and the font server 2 returns a processing termination message to the requesting computer via the network driver 14.

(D3) Font Management Mechanism of Character Requesting Computer FIG. 6 is a block diagram of the font management mechanism 12 of the character requesting computer (client).

The application 11 passes the character designation record 20 to the font management mechanism 12 and receives character image data 206 as a processing result. On the other hand, the font management mechanism 12 fetches the image data 206 from the font cache system 13 if it is a character registered in the font cache system 13, and otherwise uses the network driver 14 from the font server on the network. The image data 206 is acquired. The details of the operation will be described below.

The main components of the font management mechanism 12 are read processing 601, registration processing 602, and deletion processing 6.
03 and a font management table 605. The operation of each process is as follows. Also, the font management table 60
The configuration of one element of No. 5 is shown in FIG.

(D3-1) Delete Process The delete process 603 is called and used by the registration process 602. A flow chart of this processing is shown in FIG. In the font management mechanism 12 of the computer 1 (that is, the client) on the character output request side, the deletion processing 603 is performed by the deletion processing 803 of the font management mechanism 16 on the font server 2 side.
Is very different from. The deletion process 603 uses the table search process 604 to search the registration flag 606 of the font management table 605 (S601), and takes out the smallest element whose value is other than 0 (S602). Next, the contents of the key 608 corresponding to this element and the contents of the character designation record 607 are read (S603). Subsequently, first, the contents of the key 608 are substituted into the key 212, and the font cache system 13 is instructed to read from the cache (S60
4) The image data 206 is acquired as the processing result (S605). Further, the deletion processing 603 substitutes the content read from the character designation record 607 into the character designation record 20, combines it with the image data 206 read from the font cache system 13, and generates a character registration request 21. It is transmitted to the font server 2 via S14 (S606). After that, the key 212 is designated, and the font cache system 13 is instructed to delete (S607).

(D3-2) Registration Process The registration process 602 is called from the reading process 601 and used with the image data 206 and the character designation record 20 as arguments. A flow chart of this processing is shown in FIG. The registration processing 602 calls the table search processing 604 (S701), searches the registration flag 606 of the font management table 605, and extracts the element having the smallest value (S).
702). At this time, if the value of the registration flag 606 is 0, it is determined that the element has not been the object of font registration until now, or has just been deleted. Therefore, the contents of the registration flag 606 are set to hexadecimal FF.
Rewrite as FFFFFFFFFF. This is a temporary flag indicating that it is currently in use. Then, the content of the key 608 corresponding to this element is taken out, the key 212 and the image data 206 are transferred to the font cache system 13, and a writing process is instructed (S703). As a return value of the processing result, from the font cache system 13,
If an overflow area error is returned, nothing is done and the registration process ends. In this case, at the end of the registration process, the value of the registration flag 606 is restored to the value before the process.

When a write error is returned from the font cache system 13 as the return value of the processing result, the registration processing 602 calls the deletion processing 603 (S7).
04). As a result of this processing, an empty area is generated in the font cache system 13, so the registration processing 602 again transfers the key 212 and the image data 206 to the font cache system 15, and instructs the writing processing. Further, when a writing error is returned from the font cache system 13 as a return value of the processing result, the same processing is repeated and the registration is completed. In this case, the content of the access counter 609 is incremented by 1 at the end of the registration process (S705), and this value is set to the registration flag 606.
(S706).

The registration flag 606 of the font management table 605 is searched and the element having the smallest value is extracted (S7).
02), if this value is not 0, delete processing 603
Is called (S707), an open area is secured, and S702
The following processing is performed.

(D3-3) Read Processing The read processing 601 is the main processing of the font management mechanism 12. A flow chart is shown in FIG. 3 and will be described. The font management mechanism 12 executes the reading process 601 by using the content of the character designation record 20 as an argument. Read processing 601
Calls the table search processing 604 (S801),
It is searched whether the same element as the content of the character designation record 20 is registered in the font management table 605.

First, the case where the same element is detected will be described.

In this case, the content of the access counter 609 is incremented by 1 (S802). The access counter 609 is
The configuration is the same as 809. The value of the access counter 609 is recorded in the registration flag 606 corresponding to the detected element (S803). Then, the key 608 corresponding to the detected element is read (S804). The reading process 601 substitutes the value of the key 608 into the key 212, passes it to the font cache system 13, instructs the reading process (S805), and obtains the character image data 206 as a processing result. The font management mechanism 12 passes the image data 206 to the application 11 and ends the processing.

On the other hand, the operation when the character designated by the character designation record 20 is not registered in the font management table 605 will be described. In this case, the read processing 601 transmits the packet of the character extraction request 22 to the font server 2 on the network (S806).
When a packet including the character image data 206 is received as a response packet (S807), the read processing 601 passes the image data 206 to the application 11. Next, the registration process 602 is called with the character designation record 20 and this image data 206 as an argument (808). The registration processing 602 executes the processing already described, and as a result, the font cache system 13 is updated, and the reading processing 601 ends.

[0071]

According to the present invention, the following effects can be obtained. First, the following points can be pointed out as the effects that result from using a font server on the network.

(1) Since it is not necessary for the requesting device to have font original data, it is possible to effectively use resources such as an auxiliary storage device.

(2) By centrally managing the font original data on the supply device side, it is possible to easily perform processing such as addition of a new character type.

(3) Since the image data of each character is generated by the supply side device, by using the supply side device as a dedicated machine, it is easy to deal with the character data and the like which requires special processing. Is.

Furthermore, the following effects can be pointed out by having a font cache mechanism on the font server (supply device) side.

(4) Even if the hit rate of the local font cache deteriorates in the requesting device due to the change of the character type, various characters are stored in the font cache on the font server due to the operation of other devices. It is registered and there is a high probability that the requested character can be assigned from the global cache.

(5) The processing of the font server is improved by mounting the font cache on the font server side, and as a result, the processing speed of the entire system is improved.

In addition to this, since the present invention performs the operation of keeping the contents of the local font cache on the requesting device and the contents of the global font cache on the font server inconsistent, the following effects can be obtained. ..

(6) In the font cache of the requesting device and the font cache on the font server,
It is possible to efficiently register a large number of characters in a finite cache memory, because the same character is rarely duplicated and registered.

[Brief description of drawings]

FIG. 1 is a schematic configuration diagram of one embodiment.

FIG. 2 is a configuration diagram of a font cache system.

FIG. 3 is a flowchart of a reading process in a requesting device.

FIG. 4 is a flow chart of a character data registration process in the request side device.

FIG. 5 is a flow chart of character data deletion processing in the request side device.

FIG. 6 is an explanatory diagram of a font management mechanism of a requesting device.

FIG. 7 is an explanatory diagram of cache allocation processing.

FIG. 8 is an explanatory diagram of a font management mechanism on the font server side.

FIG. 9 is an explanatory diagram of elements of a font management table.

FIG. 10 is a flowchart of a data read process in the cache management process.

FIG. 11 is a flowchart of connection cancellation processing in cache management processing.

FIG. 12 is a flowchart of a data writing process in the cache management process.

FIG. 13 is a flowchart of a character data reading process in the font server.

FIG. 14 is a flow chart of character data registration processing in the font server.

[Explanation of symbols]

 1 ... Character requesting computer 2 ... Font server 3 ... Network 11 ... Application 12 ... Font management mechanism 13 ... Font cache system 14 ... Network driver 16 ... Font management mechanism (font server side) 17 ... Font generation mechanism 18 ... Font data read Mechanism 19 ... Auxiliary storage device 20 ... Character designation record (variable) 201 ... Management unit memory 203 ... Index part 204 ... Data part 205 ... Cache memory 206 ... Character image data 207 ... Cache management mechanism 208 ... Address table 209 ... Of key Value 210 ... Index value 211 ... Pointer 212 ... Key (variable for storing key value) 601, 801, ... Read processing 602, 802 ... Registration processing 603, 803 ... Delete processing 604, 804 ... Table check Processing 605, 805 ... Font management table 606, 806 ... Registration flag 607, 807 ... Character designation record 608, 808 ... Key 609, 809 ... Access counter 701 ... Read processing 702 ... Write processing 703 ... Concatenation release processing 704 ... Real address operation Part 705 ... Address bus 706 ... Data bus

Claims (1)

[Claims] 1. A plurality of devices performing a character output operation and one or more devices having a character data resource are used in a system connected by a network, and a device performing a character output operation should be output. A means for searching that the data representing the shape of the character described by the character type of the character, the character decoration specification, the character size specification, and the character code specification exists in the specified specific memory area (hereinafter referred to as local font cache). If there is data of the corresponding character by this search, a means for passing the character data to the process that generated the character output request, and if there is no corresponding character by this search, the predetermined character data on the network For a device that has resources (hereinafter referred to as a font server), specify the character type of the character, character modification specification,
It has a means to receive the data of the character obtained as the response by transmitting the request message that prompts the transfer of the pixel data representing the shape of the character described by the character size designation and the character code designation, and For data, try to register it in the local font cache. If there is no free space in the local font cache, take out unnecessary character data, create a free space, and register it.
On the other hand, the character data extracted as unnecessary is added with a request message for prompting the font server to register it in a specific memory area (hereinafter referred to as global font cache) designated in advance on the same device, and has means for transferring. With regard to the font server on the network, the characters described by the character type, character modification specification, character size specification, and character code specification from other devices on the network are
The means for receiving the character acquisition request, the means for searching for the data representing the shape of the character received by this means in the specified specific memory area, and the data for the corresponding character by this search If there is, the means for reading this data and passing it to the information device that issued the character output request, and if there is no corresponding character by the search, the pixel data representing the shape of the specified character is extracted from the outline font data. This pixel data is generated by the arithmetic processing and is sent to the device that generated the character acquisition request.
If you have a means to send, and if you receive a message requesting registration of character data from another device on the network, try to register in the global font cache,
A character data management method characterized in that, when no free space is obtained, unnecessary character data is deleted, a free space is created and the registration is performed.