JPH03203781A - font server - Google Patents

Abstract

(57) [Summary] This bulletin contains application data before electronic filing, so abstract data is not recorded.

Description

[Detailed Description of the Invention] [Industrial Application Field] The present invention relates to a font server, and particularly to a LAN (Local
lAreaNetwork) WAN(WideAr
The present invention relates to a font server that connects to a network such as eaNetwork and provides a wide variety of large-capacity font services.

[Prior Art] Today, as the functionality of text processing devices (word processors, etc.) improves, various languages are being processed, not just Japanese and English.

[Problem to be solved by the invention] However, since conventional text processing devices perform text processing in a stand-alone manner, the types of fonts used,
There were restrictions on capacity, etc.

The present invention eliminates the above-mentioned drawbacks of the prior art, and its purpose is to provide a font server that efficiently provides a wide variety of large-capacity font information resources.

[Means and operations for solving the problems] In order to achieve the above object, the font server of the present invention includes a storage means for storing font information, a data communication means for performing data communication with other devices, and , font service means for searching font information in the storage means based on information received from another device via the data communication means and sending the searched font information to the other device via the data communication means; The outline is to prepare.

This allows a large number of text processing devices to efficiently utilize a wide variety of large-capacity font information resources via data lines.

[Description of Embodiments] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

FIG. 1 is a functional block diagram of a font server according to an embodiment. In the figure, reference numeral 100 denotes a control unit, which controls various services related to the provision of font information in response to requests from a plurality of text processing devices (not shown, such as word processors). Reference numeral 200 denotes an auxiliary storage device that stores a large amount of font information of various types. 300 is a local area network (LAN) consisting of data transmission media (coaxial cables, optical cables, etc.) for communicating with other text processing devices.

In the control unit 100, al is a file management unit,
The information stored in the auxiliary storage device 200 is handled as a file. A2 is a font processing unit that executes various service processes related to font information (font processing start, font acquisition, font processing end, etc.). The font processing unit a2 is composed of font processing units a2+ to a2n, each of which specializes in various service processes. a3 is a font processing control unit, which receives and receives processing request packets sent from other text processing devices via the LAN 300, analyzes the contents of the packets, and controls the corresponding font processing units az+~ based on the analysis results. Activate or deactivate either a2n. a4 is a communication control unit, and in this embodiment, OS I (Open Systems Interco
(4 layer control unit 841) based on the
~A44 is centrally controlled. a41 is a physical layer control unit, which is based on the IEEE802.3 standard. a4□ is a data link layer control unit, which is based on the IEEE802.2 standard (
. a43 is a network layer control unit, so-called I
P (Internet Prot.

-cot) part. a44 is a transport layer control unit, here TCP (Transmission
n ControlProtocol ).

In the auxiliary storage device 200, bl is a font management file that stores management information of various font information. b2 is a font file section that stores various font information files b21 to bzn.

FIG. 2 is a block diagram of the font server of the embodiment. Parts equivalent to those in Figure 1 are given the same numbers. Control unit 10
0, 1 is a CPU, which realizes the main control and processing of the control unit lOO (various control units a1 to a1 in FIG. 1, etc.). 2 is a memory, for example, the ninth
The control programs shown in Figures (A) to (C) are stored. 3 is L
This is a communication interface (LAN iF) for the AN 300, and controls data communication with other text processing devices. 4 is the console section, which contains the CRT, keyboard (KBD), and printer (
PRN). AB is the CPUI address bus, D
Similarly, B is a data bus.

FIG. 3(A) is a diagram showing the types of fonts serviced by the font server of the embodiment. In the figure, fl is a bitmap font (or dot font or rask font), and one bit of the bitmap font corresponds to one dot of the printer or CRT. f2 is a Hefta font, and the characters are framed (
f3 is an outline font, and is structured to draw the outer frame of characters (strokes).
vector font f2
and outline font f3 are each made up of coordinate information for drawing a straight line between two points and coordinate information for drawing a curved line between three points.

FIG. 3(B) is a diagram illustrating the relationship between the font and the base point of the embodiment. Each character font is designed based on a base point, and this server sends base point position information along with font data.

FIG. 4 is a diagram of a packet format adopted by the font server of the embodiment. In the figure, PK is a 2-byte area where a function code is set, for example 0000.
(H)=font processing start, 0001 (H)=font acquisition, 0002(H)=font processing end.

PK2 is a 1-byte area in which a code of the processing result by this server is set; for example, 00 (H) = normal end, 01-FF (H) = abnormal end. Note that this area is only reserved on the service requesting side (another text processing device). PK3 is a 4-byte area for setting the packet length, and sets the total number of bytes of areas PK to PK4 in binary. PK4 is a variable length area in which function auxiliary information is set, and may have a variable length for each area PK receiving function and for each transmitted/received packet.

FIG. 5(A) is a diagram showing the packet format of a request to this server to start font processing. In the figure,
PK+-o~PK3- are PK in Figure 4, ~
It is the same as PK. pK,.

sets the requested font type (font id)2
This is a part-time job area, such as ooo.

(H) 2-bit map font, 0001 (H) = stroke font, 0002 (H) = outline font. PK4-02 sets language id2
This is a byte area, and for example, 0000 (H) = Japanese, 0001 (H) = English, etc. PK, -03 is a 4-byte area to set the typeface, for example...0000 (H) = Mincho,...0001
(H)=Gothic, etc. PK4-04 is a 1-byte area for setting the output format, for example 00 (H
)=landscape, 0f(H)=portrait. PK4-as is a 1-byte area to set the style, for example, 00 (H) = italic, 01 (H)
= Upright. P K 4-oa is a 1-byte area for setting the character pitch ID, for example OO(
H)=fixed pitch, 01(H)=proportional. P K is a 1-byte area for setting the stroke (character thickness), for example, 00 (H) = bold, 0f (H) = decibold, 02 (H) = regular, 03 (H) = light. be. PK4-a
s is a 2-byte area that sets the vertical size of the character font in binary dots. This area is set when the font ID is a bitmap font. P
K,,-,.

is a 2-byte area that sets the horizontal size of the character font in binary dots. This area is font i
d is a bitmap font and character pitch id
Set if is a fixed pitch. In this way, as functional auxiliary information, in the case of stroke fonts or outline fonts, PK4. ,,,-PK,o
, and if the bitmap font is variable length (proportional), set PK, , ~PK 4-,, and if the bitmap font is fixed length, set PK.
4-01~P K , , is set.

FIG. 5(B) is a diagram showing the format of a response packet from this server in response to a request to start font processing. In the figure, PK, ..., ~PK3-oR are the same as PK and ~PKa in Figure 4, respectively.

PK4-ORI is a 2-byte area where the communication ID is set, and this server uses 0000 (
)() to FFFF (H) code is returned to the requester. Thereafter, when requesting font acquisition or completion of font processing, the requester stores this communication ID in each packet and sends it. PK4-0R2 is an area where the base point information explained in FIG. 3(B) is set.

FIG. 5(C) is a diagram showing the format of a font acquisition packet sent by the requester to this server.

When the requester who requested the start of font processing receives a response packet indicating normal completion from this server, it sends a font acquisition packet. In the figure, P K +-.

~PK x-o are the same as PK and ~PK in FIG. 4, respectively. PK 4. , , is an area where a communication ID is set, and the same value as the communication ID of area PK, -08, in FIG. 5(B) is set. P K , -, , is a 2-byte area in which a character code is set. Furthermore, 1
When setting a byte code, align it to the right, and set Nul 1 (00 (H)) to the empty byte on the left.

FIG. 5(D) is a diagram showing the format of a response packet returned from this server to the request source in response to a font acquisition request.

PK, -6R" PK 3-GR are the PK in Figure 4, respectively.
, ~PK, is the same. Furthermore, PK, -0R1 communication i
The character codes of d, P K 4-, and R□ are set to the same values as P K , , and PK , - in FIG. 5(C), respectively. PK4-0113 and pK4-OR
The vertical and horizontal sizes of the character font are set in 4.

For example, for a 2-byte code bitmap font, (16x16) (24X24) (32X32) (40
The vertical and horizontal sizes of (48x48) or (56x56) are set. In addition, in the case of 1-byte code (16
X8) (24X12) (32X16) (40X20)
(48x24) or (56x28) (the horizontal size is halved. Stroke fonts and outline fonts are uniquely designed assuming vertical and horizontal (768x768) xy coordinates.

PK4-Gl? 6 is an area for setting a font pattern, and is an area of variable length depending on the font pattern. Details of the storage mode will be described later with reference to FIGS. 7(D) to (F) and FIGS. 8(A) and (B).

FIG. 5(E) is a diagram showing the packet format of a font processing termination request from the request source. This packet is sent when the request source declares to this server that font processing is complete. PK, -6 to PK 3-c are the PK in Figure 4, respectively.
, ~ Same as PK3.

P K +-c is an area for setting the communication ID,
Set the same content as the communication ID of area PK4-ORI in FIG. 5(B).

FIG. 5(F) is a diagram showing the format of a response packet returned from this server to the request source in response to a font processing termination request. In the figure, P K 1-cR to P K-c
R is the same as PK1 to PK3 in FIG. 4, respectively.

FIG. 6 is a list diagram showing details of functional auxiliary information of the embodiment. When declaring the start of font processing in FIG. 5(A), necessary information is selected from these and set in the font processing start request packet.

FIG. 7(A) is a diagram showing the storage structure of the font management file b1 in the auxiliary storage device 200 of the embodiment. Note that the index section is not shown. The contents of the font processing start request packet shown in FIG. 5A are referenced to the contents of the font management file b+, and the corresponding font registration file name is extracted.

In the figure, the font registration file name is 13 bytes, the base point is 2 bytes (binary), and the character pitch id
is 1 byte (fixed pitch/proportional), the horizontal size is 2 bytes (the number of horizontal dots), the vertical size is 2 bytes (the number of vertical dots), and the font size is 2 bytes (font size length per code).

FIG. 7(B) is a diagram showing the storage structure of the font file b2. Each font file bz+ to b2n is called by a font registration file name, and the file consists of a font code search data section and a font storage section.

FIG. 7(C) is a diagram showing the storage structure of the font code search data section. In the figure, the code part consists of 2 bytes, and if it is a 1-byte code, the beginning is Null.
Padded with (00(H)). The pointer section consists of 4 bytes, and the storage address of each font corresponding to the code of the code section is stored as address O (relative address), which is the first address of the font storage section in FIG. 7(B).

FIG. 7(D) is a diagram showing the storage structure of a bitmap font with a fixed pitch.

The dot pattern font f shown in FIG. 3(A) is stored here as is.

FIG. 7(E) is a diagram showing the storage structure of a fixed pitch font, which is a stroke font or an outline font. In the figure, the font pattern length is 2 bytes, and the size of the font pattern is set here in byte length.

The font pattern is variable length, details are shown in Figure 8 (A)
, (B) will be described later.

FIG. 7(F) is a diagram showing the storage structure of a proportional font, which is a bitmap, stroke or outline font. In the figure, the font pattern length is 2 bytes, and the size of the font pattern is shown in byte length. The horizontal size is 2 bytes and indicates the horizontal size of the character design. For example, a bitmap font is 0-56, and an outline or stroke font is 0-768. The font pattern has a variable length, and if it is a bitmap font, it is stored in the dot pattern format f+ as shown in FIG. 3(A).

For outline or stroke fonts, see Figure 8 (
A) and (B) are stored.

FIGS. 8(A) and 8(B) are diagrams showing the font pattern storage format of a stroke font or an outline font, and FIG. 8(A) is a diagram showing the storage structure of a linear element font. The linear element font consists of a total of 9 bytes, with a straight line fd=oo (H) consisting of 1 byte, and each 4
Two-point coordinates of the tool (X+ + y+) + (X2
+3'2). Both coordinate values of X13' do not exceed 768.

FIG. 8(B) is a diagram showing the storage structure of a curved element font. The curve element font consists of a total of 13 bytes, 1
i d = 01 (H) of the curve consisting of bytes, and the 3-point coordinates of each 4 bytes (x+ + 3'+) (X2 + y
a)+(x3+ys).

Both x and y coordinate values do not exceed 768.

FIG. 8(C) is a diagram showing termination request codes for linear element or curved element fonts. The termination request code consists of 1 byte FF (H), and with this termination request code,
Indicates that the font for the linear element or curved element has ended.

FIG. 9(A) is a flowchart of font processing start processing according to the embodiment. The font processing control unit a3 is connected to the LAN3
Upon receiving a font processing start request packet from another text processing device via 00 and OS Ia 4,
Control is passed to this font processing section a2.

In step Sll, P of the received packet (Fig. 5(A))
The font management file b1 is searched using the values of K4-o, to PK4-os as index data, and if the search is successfully performed, the process advances to step SL2.

In step S12, internal management table processing is performed, and the corresponding [font registration file name] is extracted from the data group of FIG. If it is performed normally, the process advances to step S13. In step S13, data 00 (H) indicating normal termination is set in PKz-oR of the response packet (Fig. 5 (B)), and further PK, -8R is set.
1 and set the value assigned in step SL2 as the communication ID, and further retrieved in step Sll as shown in Fig. 7 (A).
The base point data of Figure 5 (B) is PK,,R□
Set to .

Further, if an error occurs in the processing of step Sll or S12, the process advances to step S14, and the corresponding error code is written as shown in FIG.
Set P K , , R in B).

In step S15, the total packet length is set in PK3-, R in FIG. 5(B), and the font processing control unit a3 is requested to return this reply packet to the service requester.

FIG. 9(B) is a flowchart of font acquisition processing according to the embodiment. The input to this process is also the same as in the case of FIG. 9(A). In step S21, the communication ID of PK4-o of the received packet (FIG. 5(C)) is
A search is made to see if it is the value in the internal management table allocated in step S12, and if the search is successfully performed, the process advances to step S22. In step S22, the font code search data portion of the corresponding file in FIG. 7(B) is searched using the character code of PK4-62 in FIG.

In step S23, P of the reply packet (FIG. 5(D))
In order to create the parts K4-OR3 to PK4-aRs, the seventh
The data in the corresponding format among the data shown in FIGS. 7(D) to 7(F) is set in the corresponding area in the reply packet.

Further, if an error occurs in the process of step S21 or S22, the process advances to step S24, and the corresponding error code is written in FIG.
D) area P K , .

In step S25, P of the reply packet (FIG. 5(D))
The packet length is set in Kz-aR, and the font processing control unit a is requested to return the return packet to the request source.

FIG. 9(C) is a flowchart of the font processing termination process of the embodiment. Similarly, in step S31, the communication ID of P K 4-c of the received packet (FIG. 5(E)) is
is the value in the internal management table allocated in step S12 above, and if the search is normal, step S3
Proceed to step 2. In step S32, the answer packet (Fig. 5 (
Normal completion code 00 (H) in PK2-CR of F))
and close the corresponding file.

If there is an error in step S31, the process advances to step S33, and an error code corresponding to PK2-CR of the reply packet (FIG. 5(F)) is set.

In step S34, P of the reply packet (FIG. 5(F))
The font processing control unit a3 sets the total packet length in Ks-an and sends this reply packet back to the request source.
request.

Incidentally, in the above embodiment, a LAN is used as a data communication means, but the present invention is not limited to this. Alternatively, a public telephone line, high-speed digital line, packet line, 15DN, etc. may be used.

Further, in the above embodiment, the font server is provided with the console 4, but the present invention is not limited to this. The functions of the console may be realized by a console on another text processing device connected to this server.

Further, although not shown, a session layer a46, a presentation layer a46, and an application layer a47 may be provided in stages above the transport layer a44 in FIG. 1, or all of them may be provided.

In addition, some of the packet formats in the above embodiments have the same format parts for transmission and reception, but in order to reduce the communication overhead, the packet formats for each transmission and response are shorter than in this embodiment. You can think about it.

[Effects of the Invention] As described above (according to the present invention), many text processing devices can receive a wide variety of large-capacity font services from a font server simply by having an appropriate communication means.

[Brief explanation of drawings]

FIG. 1 is a functional block diagram of the font server of the embodiment, FIG. 2 is a block configuration diagram of the font server of the embodiment, and FIG. 3(A) is a diagram showing the types of fonts serviced by the font server of the embodiment. Figure 3 (B) is a diagram explaining the relationship between the font of the embodiment and the base point, Figure 4 is a diagram of the packet format adopted by the font server of the embodiment, and Figure 5 (A) is the font for this server. Figure 5 (B) is a diagram showing the format of a packet format of a request to start processing. Figure 5 (B) is a diagram showing the format of a response packet from this server in response to a request to start processing fonts. Figure 5 (C) is a diagram showing the format of a response packet from this server to a request to start processing fonts. Figure 5 (D) is a diagram showing the packet format returned from this server to the requester in response to a font acquisition request, Figure 5 (E) is a diagram showing the packet format of a font processing end request, Figure 5 (F) is a diagram showing the packet format returned from this server to the requester in response to a font processing termination request, Figure 6 is a list diagram showing details of functional auxiliary information of the embodiment, and Figure 7 (A) is FIG. 7(B) is a diagram showing the storage configuration of the font management file b in the auxiliary storage device 200 of the embodiment. FIG. 7(C) is a diagram showing the storage configuration of the font file b2. Figure 7 (D) is a diagram showing the memory structure of a bitmap font with a fixed pitch. Figure 7 (E) is a diagram showing the memory structure of a fixed pitch font with a stroke font or an outline font. Figure 7 (F) is a diagram showing the storage structure of a proportional font, which is a bitmap, stroke, or outline font. Figures 8 (A) and (B) show the font pattern storage format of a stroke font or an outline font. Figure 8(C) is a diagram showing the termination request code for a linear element or curved element font, Figure 9(A) is a flowchart of the font processing start process of the embodiment, and Figure 9(B) is a diagram of the embodiment. Flowchart of Font Acquisition Processing FIG. 9(C) is a flowchart of font processing termination processing in the embodiment. In the figure, 100...control unit, 200...auxiliary storage device, 300...local area network (LAN)
, 1...CPU, 2...Memory, 3...Communication interface (LAN iF), 4...Console section, AB...Address bus, DB...Data bus.

Claims (1)

[Scope of Claims] Storage means for storing font information; data communication means for performing data communication with another device; and said storage means based on information received from the other device via said data communication means. A font server characterized in that the font server comprises font service means for searching for font information and sending the searched font information to the other device via the data communication means.