JP2012155681A - Font server - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a font server by which a client terminal can use various fonts for display even when font data is accumulated neither in a creator terminal nor in the client terminal.SOLUTION: A font server 20 comprises: character string reception means 21 for receiving a character string and its style from a client terminal 10: font file creation means for reading the font of the character string of the received style, creating and storing a font file 23; and URL response means 22 for returning a URL of the font file to the client terminal 10.

Description

  The present invention relates to a font server that can use font data that is not stored in a client terminal for display in a network environment.

  Conventionally, font processing that can be used to display fonts that the client terminal does not have by storing all the font data necessary for document display in the creator terminal and downloading it to the client terminal that requests display An apparatus is known (for example, refer to Patent Document 1).

JP-A-10-124030

  However, according to the above-described known example, each creator terminal must accumulate fonts necessary for display, and when viewed from the entire network environment, each creator terminal accumulates font data redundantly. Is not efficient.

  SUMMARY OF THE INVENTION In view of the above problems, the present invention has an object to provide a font server in which a client terminal can use various fonts for display without storing font data in a creator terminal or a client terminal. To do.

  A font server according to the present invention includes a character string receiving unit that receives a character string and its style from a client terminal, a font file creating unit that reads out a font of the received character string of the style, creates a font file, and stores the font file. URL reply means for replying the URL of the file to the client terminal is provided.

  Further, the font server of the present invention includes a character string receiving unit that receives a character string and its style from a creator terminal, a font file creating unit that reads out a font of the received character string of the style, creates a font file, and stores it. URL reply means for replying the URL of the font file to the creator terminal.

  According to the present invention, the client terminal can use various fonts for display without storing font data in either the creator terminal or the client terminal.

It is a figure which shows the structure of the font server by Example 1. FIG. It is a figure explaining operation | movement of the font server by Example 1. FIG.

  DESCRIPTION OF EMBODIMENTS Hereinafter, embodiments for carrying out the present invention will be described in detail with reference to the accompanying drawings.

  FIG. 1 is a diagram illustrating a configuration of a font server 20 according to the first embodiment. Here, in a network environment using WWW (world wide web), a client terminal 10 operated by a general user and a creator terminal 30 provided by a company or an individual to provide a home page are shown. The font server 20 includes a receiver 21, a transmitter 22, a font file 23, and a font DB (database) 24.

  The receiver 21 and the transmitter 22 are general receivers and transmitters. The font file 23 is a file for temporarily storing font data described with reference to FIG. The font DB 24 stores various font data and can be read out as necessary. For example, Mincho, Gothic, and brushstrokes are stored for about 10,000 JIS kanji codes, about 21,000 characters using Juki Net, and about 56,000 characters using family registers. In addition, special fonts that are valuable as creative works of hiragana, and fonts of external characters are also accumulated. These font data are accumulated for each style (typeface), and can be read by designating the style and character code. If necessary, the external characters are stored for each creator terminal 30 together with the creator terminal ID, and may be read by designating the creator terminal ID.

FIG. 2 is a diagram for explaining the operation of the font server 20 according to the first embodiment. First, the general user operates the client terminal 20 to access the creator terminal 30 that provides the home page to be displayed by the client terminal 20 (step S1). Then, a document provided by the creator terminal 30 is recorded, and a URL (Uniform Resource Locator) designation file stored in the creator terminal 30 is read (step S2). Since the read URL designation file records the style together with the character code for displaying the document, the character string is sorted for each style, de-duplication is performed, and the character string for each style is acquired. (Step S3). For example,

At that time, Junichi had just returned from school. (22 characters)
Mimi Mimi Migo Momo Momi Mimi Mimi Mimi Mimi Mimi However, Mi: Mincho
Go: Gothic
Mo: Brush brush

For a 22-character document

Mi: It ’s a bit of a sword. (14 characters)
Go: Ichigo (3 characters)
Mo: School (2 characters)

As such, the character string for each style is acquired. Due to the elimination of duplication, the total number of characters is less than the 22 characters of the document. For the fonts not held by the client terminal 10, these character strings and styles are transmitted to the font server 20 to request the font data (step S4). For example, if you have a Mincho style and a Gothic style but do not have a brush style, you will need font data for the two letters “School” and “School”. Note that it is not necessary to sort and eliminate duplication up to a style that has its own font data.

  The font server 20 receives the character string and its style from the client terminal 10 by the receiver 21 (step S5), specifies the style and character string, and reads the font data from the font DB 24 (step S6). Then, a font file recording the font data of the style and character string is created from the read font data (step S7), stored as the font file 23, and the URL of the file is returned to the client terminal 10 (step S7). S8).

  The client terminal 10 accesses the returned URL and reads the font file 23 (step S9). In the font file 23, the style is a brush and the font data of “Study” and “School” are recorded. Therefore, the client terminal 10 can obtain the font data. Therefore, the fonts of “study” and “school” of the cursive body in the document to be displayed are rewritten to the obtained font (step S10) and displayed (step S11). If there is only one style to be provided, it is not necessary to record the style in the font file 23.

  In addition, communication of character strings is performed by character codes, but when the character codes are external character codes, external character fonts are provided. In this case, the original font of the font server 20 may be used, or the font unique to the creator terminal 30 may be used. When the font server 20 is the original, it is not always necessary to specify the style. If the font is unique to the creator terminal 30, the ID of the creator terminal 30 can be used as a style.

  According to the first embodiment, font data that the client terminal 10 and the creator terminal 30 do not have can be displayed on the client terminal 10. Further, since the font data read by the client terminal 10 is only the font data corresponding to the number of character strings necessary for display, the communication time for obtaining the font data is short. Also, even if the font data is valuable and has a literary property and is charged for use, the font user can use it at a minimum charge according to the number of characters. In addition, since font vendors do not provide full-set font data (for example, all JIS kanji codes), they can be used as a copyrighted work, preventing theft and charging each time they are used. Can be managed. Furthermore, what is transmitted to the font server 20 is a character string obtained by sorting and deduplicating the characters of the document, not the document itself. Therefore, even if the document is highly confidential, the content is stored in the font server 20. Font data can be obtained without being known.

  In the first embodiment, the font server 20 creates the font file 23 in response to a request from the client terminal 10, but in the second embodiment, the font server 20 creates a font file 23 in response to a request from the creator terminal 30. It can also be configured to. In this case, the creator terminal 30 executes steps S3 and S4 for the document file to be provided. The creator terminal 30 receives the URL of the font file 23 from the font server 20 and links it to the document file, and waits for access from the client terminal 10.

When the client terminal 10 accesses the creator terminal 30, the document file is read together with the URL of the font file 23, and the URL is further accessed to read the font file and obtain font data.
In addition, this invention is not limited to the said Example.

10 Client terminal 20 Font server 21 Receiver 22 Transmitter 23 Font file 24 Font DB
30 Creator terminal

Claims (2)

A character string receiving means for receiving a character string and its style from a client terminal;
Font file creation means that reads out the font of the received character string of the style, creates a font file, and saves it;
A font server comprising URL reply means for replying the URL of the font file to the client terminal. A character string receiving means for receiving a character string and its style from the creator terminal;
Font file creation means that reads out the font of the received character string of the style, creates a font file, and saves it;
A font server comprising URL reply means for replying the URL of the font file to the creator terminal.

Images