Serving Font Glyphs

A computer-implemented method for obtaining a font for a document includes determining each glyph of a font that is specified in contents of an electronic document, the determination identifying a subset of multiple glyphs included in the font, the subset determined on a first device that does not have the font stored thereon. The method includes generating on the first device a request to a second device based on the determination, the request identifying the subset to the second device. The method includes receiving, at the first device, information sent from the second device in response to the request and defining the subset of the multiple glyphs, the information not defining a remainder of the multiple glyphs other than the subset. The method includes generating on the first device a presentation of the electronic document using the received information, the presentation including the subset of the multiple glyphs.

DETAILED DESCRIPTION

FIG. 1shows an example graphical user interface100that can be used for creating an electronic document. In some implementations, a document creator such as an advertisement designer uses the interface100to create a document (e.g., an ad) for review by and/or display to one or more other people (e.g., an ad editor or an ad recipient). For example, the interface100can allow the creator to use one or more fonts (such as an existing font or a custom font defined by the creator) in the document; the system or application receiving the created document can retrieve, from a designated font server, as much of the font as necessary for displaying the document.

The interface100can include a preview area102. The preview area102can include one or more content portions such as images, graphics, text, links or any other content that the creator chooses to include in the document. Here, the preview area102currently includes text portions104A-C, among others. The interface100can include one or more areas106dedicated to formatting content for the document. In some implementations, formatting can be applied on a portion-by-portion basis for the included content. For example, the area106A can be used to choose one or more formatting aspects for the portion104A, and the area106B similarly for the portion104B, and so on. In some implementations, the creator can enter a text content of the portion, choose a font for the portion, and/or select a color for the portion using the area106. For example, the text portion104A here includes the content “Headline” written using the font Felt Tip Roman Bold in the color identified as “#000000”.

As such, the created document, such as an ad, will contain content portions that may require use of one or more fonts for display. That is, when the document is forwarded to another user, such as to an editor or final recipient, the receiving system will use part or all of the font(s). The required font can be embedded in the electronic document or otherwise stored in the receiving system. If so, the receiving system can retrieve the font from that location and display the document. As another example, the font may be available from a dynamic font server and the receiving system can request the font from the font server for use with the particular document. In some implementations, only as much of the font as is necessary for the display is requested and/or transferred. For example, if the receiving system only needs, say, about10% of the glyphs of the font, the system can indicate this in the request and the font server can package and return that subset in response to the request.

FIG. 2shows an example system200that can serve part or all of a font. The system200can include a computer system202that can include predefined and/or custom fonts in a font database204. The computer system202can include any kind of computer device including, but not limited to, a server device. The font database204includes information that defines at least one font comprising multiple glyphs, such as any or all glyphs of the font Felt Tip Roman Bold mentioned in the above example. The computer system202can be connected to any kind of network206, such as to a local network and/or to the internet. Through the network206, the computer system202can communicate with one or more other systems, such as with an editing system208and/or with an end user system210. For example, the computer system202can serve one or more glyphs for use by the system208and/or210in presenting an electronic document such as an ad.

In some implementations, the font database204can contain any or all of the following font information items: a font identifier, a font name, a font language, a font script, font available Unicode characters, an image preview of the font, a user identifier (e.g., for a custom defined font), base font file bytes, and/or base font file hash. In some implementations, a font name can be localized, such as by having one font name for English, another font name for Chinese, and so on. A local font name can be used in presenting available fonts to users in different locales. Upon a font being uploaded to the font database204(such as a custom font), basic registration for the font can be performed (in some implementations including language and/or script determination). The font database204can interface with one or more components, for example to provide functionality for the following use cases. A document creator can be shown a list of relevant fonts while editing. For example, language information for each font can be used, such as to allow user selection. For example, information about available glyphs for each font can be used, such as for user feedback when a specified character cannot be rendered. For example, information about font ownership can be maintained, such as for showing a particular account's custom fonts. A custom font can be uploaded. For example, the owner of the custom font can be registered. For example, information about the font can be registered, such as available characters. For example, a unique font identifier can be generated. For example, a quota per account can be established and tracked. Access to original font file bytes can be granted, such as for copying to local file caches.

The computer system202can include a font packager212. The font packager212can include the necessary infrastructure for dividing any font into a subset containing the glyph(s) needed for a particular document and compiling the glyph(s) into a file, such as a .swf file. In some implementations, the font packager212can receive a request from a device such as the system208and/or210. The request can be generated because the system needs a certain font to display or otherwise present an electronic document. For example, the request can identify the glyph(s) of a particular font that the system208and/or210needs. In response to the request, the system202can forward information obtained from the font database204. In some implementations, such information can define a subset of the multiple glyphs identified in the request and not a remainder of the multiple glyphs other than the subset. For example, the information in the response can include only the specified glyph(s) of a particular font. Fonts and/or glyphs can be defined using any suitable structure of information. For example, the font can identified by a font identifier in the electronic document and one or more glyphs can be specified using a codepoint in the electronic document.

In some implementations, the font packager212can create the requested package using a labeled font subset that includes a font identifier for the font in the font database204and an accompanying base file, a label including a font name by which the subset can be referred, and a set of codepoints (e.g., a Unicode set) to be packaged.

The document creator can use a frontend application214in one or more aspects of managing the electronic document. In some implementations, the frontend application214can generate the interface100(FIG. 1) and/or can be used for creating a document such as an ad. The font database204can provide font availability information216to the frontend application216, for example such that one or more available fonts can be identified in the area(s)106(FIG. 1). The frontend application214can provide one or more uploaded fonts218to the font database204, for example a custom font that the document creator provides to the database. A custom font can be defined in any suitable way, such as by creating definitions for vector graphics such that font glyphs can be generated in more than one font size and/or style (e.g., in boldface). For example, a font can be defined using any suitable font format, such as in form of a TrueType font, an OpenType font, or a Type1font, to name just a few examples.

The frontend application214can take one or more actions with regard to the packaged font222. For example, the frontend application can forward the packaged font222to the system208and/or210for use in displaying or otherwise presenting an electronic document. As another example, the frontend application can use the packaged font222in creating a version of the electronic document (e.g., by replacing codepoints and/or other glyph placeholders in the document with the actual glyph chosen by the creator). Such a created version of an electronic document can be stored in a static content server224. In some implementations, image(s) of a created document can be stored in the server224and thereafter provided to one or more viewers. For example, a created advertisement using a particular font can be stored in the server224and be served to any or all of the end user systems210upon a predefined event, such as that the user enters a particular search query or visits a certain page or site.

It was mentioned above that the electronic document can be stored, such as in the server224. As another example, the packaged font can be stored. In some implementations, this can allow multiple documents to refer to, and use, the packaged font. For example, an advertisement document can exist in different size variations that all include the same text, or some variations can use only a subset of the supported text of another variation. A stored font package, such as a font .swf file, can allow multiple variations to use a common file.

The editing system208can be used for editing an electronic document226. For example, the document226may have been created on the system202by an ad creator using the frontend application214. Then, an ad editor can make selected changes in the document226using the same application214or another application. Accordingly, one user can create the electronic document226on one device and another user can modify the electronic document226on another device. The other device (e.g., the system208and/or210) can determine what glyph(s) the electronic document226requires, for example by reading each codepoint defined in the document. The other device can then generate a request to the system202based on such a determination. For example, the request can identify the subset of glyphs that is needed. In some implementations, the font includes a non-Latin script (such as, but not limited to, those used in the Chinese, Japanese and Korean languages). For example, each of the multiple glyphs requested for the electronic document226can be a non-Latin glyph. Thus, the electronic document226can be presented using the system208and/or210such that the document includes the glyph(s) requested and received from the font database204.

Further editing of the electronic document226can be performed. In some implementations, the system208and/or210can detect whether the editor enters one or more glyphs not already used in the document, and if necessary request and receive any such glyph(s) from the font database204. The document226can be updated when a requested glyph has been received. In some implementations, a determination that the revised document includes at least another glyph not already stored on the local device can be performed upon a predetermined event, such as an explicit refresh command from the user or a period of user inactivity. For example, assume that the editor is working on a revision of the electronic document226. After the user makes a change in the document and a certain time passes without further input from the user, the system can automatically determine whether the revised document requires any additional glyph(s) not already present. If so, the required glyph(s) can be requested. This and/or other functionality on the requesting device can be provided by execution of instructions in any form of script, such as by Javascript code.

More glyphs than currently required can be requested. For example, the glyphs requested from the font packager212and received in response need not only contain the glyphs entered in the document to that point. In some implementations, the application214and/or the system where it is implemented can be configured for making one or more assumptions and/or extrapolations based on likely use, and request the corresponding glyph(s) based thereon. For example, if a user enters the characters “abc” from the Latin alphabet, the entire range of characters a-z can be requested, in anticipation of further user input of Latin text.

In some implementations, an exception can be generated upon a condition being met, such as if a requested font does not exist in the font database214. In contrast, one or more issues may be explicitly ignored. In some implementations, no exception may be generated for an invalid font range. For example, if a request is made for a font subset that includes one or more characters not present in the base font, the character(s) will be omitted/ignored in responding to the request.

The glyph(s) can be requested using an address of the font database204. For example, each font covered by the font availability information can be identified by a font identifier. The sought glyph(s) can then be requested by contacting the font packager212with the identities of the font and the specific glyph(s). In some implementations, the necessary information for where to obtain fonts that are not embedded in the electronic document and not otherwise available to the receiving system can be included in the document226. For example, the document226can include information that identifies the computer system202and/or the font package212as the resource for requesting a font for a document. In some implementations, the necessary information for obtaining fonts can be included in the applicable program handling the document, such as in a browser and/or in the frontend application214. For example, the frontend application214can be installed both on the device where the document is created (e.g., on the system202) and on the device where the document is to be edited (e.g., on the system208). The program214can then use its internal identification of the computer system202and/or the font package212to seek and obtain the necessary font(s).

The end user system210can be used for accessing or editing one or more electronic documents. In some implementations, the end user system can include any kind of computer device, such as a personal computer, mobile device or a telephone. For example, an ad using a predefined font (such as a custom font) can be displayed on a device operated by a consumer.

FIG. 3shows an example system300that includes a font server302. Components that in some implementations can correspond to those of the system200(FIG. 2) are identified using corresponding reference numbers. In some implementations, the server302implements the same interface as the font packager212and acts as a wrapper to block calls to a server. For example, an implementation that uses a standard client-server framework can allow a reduction or minimization of code dependencies in the frontend program214.

A static font database304can be included in the system300. In some implementations, the database304can allow only queries for available fonts. For example, the database304can be encapsulated in the server302, such as to avoid application dependency (e.g., by the application214) on the font data directly.

For example, a packaged font can be provided by the server302for receipt by the frontend application214, such as for direct receipt by an end user system or an editor, or for placement in the server224.

FIG. 4shows a table400with example compile times and file sizes. Here, a font column402indicates which font is implicated by a particular character or characters. An antialiasing column404indicates whether advanced antialiasing is provided for the font identified in column402. A character column406indicates which characters are defined using the identified font in each example. A compile time column408indicates the median compile time in milliseconds. A file size column410indicates a size in Bytes of a .swf file generated for the characters identified in the column406.

FIG. 5shows a flowchart of an example method500for obtaining a font for a document. In some implementations, the method500can be performed by a processor executing instructions in a computer-readable medium, for example in system200and/or300. In some implementations, more or fewer steps can be performed; as another example, one or more steps can be performed in another order.

In step510, each glyph of a font that is specified in contents of an electronic document is determined. The determination identifies a subset of multiple glyphs included in the font. The subset is determined on a first device that does not have the font stored thereon. For example, the system208and/210can determine the glyph(s) of the electronic document226for which the system does not have the corresponding font.

In step520, a request is generated to a second device based on the determination. The request identifies the subset to the second device. For example, the system208and/or210can generate a request to the system202and/or the font packager212.

In step530, information is received at the first device. The information is sent from the second device in response to the request and defines the subset of the multiple glyphs. The information does not define a remainder of the multiple glyphs other than the subset. For example, the system208and/or210can receive from the font packager212a .swf file with only those glyphs of the font that the system208/210needs for presenting the document. If the document is subsequently revised, another request can be generated for any additional glyph(s) not covered by the first request.

In step540, a presentation of the electronic document is generated using the received information. The presentation includes the subset of the multiple glyphs. For example, the system208/210can display, print or otherwise visualize the electronic document226, such as in an editing program where a user can make document changes.

FIG. 6shows a flowchart of an example method for providing a custom font for a document. In some implementations, the method600can be performed by a processor executing instructions in a computer-readable medium, for example in system200and/or300. In some implementations, more or fewer steps can be performed; as another example, one or more steps can be performed in another order.

In step610, a first input is received in a first device. The first input specifies a subset of multiple glyphs of a custom font to form contents of an electronic document. For example, a document creator can use the frontend application214to define the electronic document226, such as an advertisement, to include characters of the font Felt Tip Roman Bold.

In step620, a second input is received in the first device. The second input includes information defining the multiple glyphs of the custom font. For example, the creator can define the Felt Tip Roman Bold font using the frontend application214. In step630, the information is forwarded to a second device configured to provide the information upon request from a recipient of the electronic document. For example, the custom font can be uploaded to the font database204and/or to the font packager212.

In step640, the electronic document is forwarded to a third device that does not have the custom font stored thereon. The third device can request the information from the second device. For example, the system202can forward the electronic document226to the system208/210, which can request the necessary glyph(s) from the font database204and/or from the font packager212.

FIG. 7is a schematic diagram of a generic computer system700. The system700can be used for the operations described in association with any of the computer-implement methods described previously, according to one implementation. The system700includes a processor710, a memory720, a storage device730, and an input/output device740. Each of the components710,720,730, and740are interconnected using a system bus750. The processor710is capable of processing instructions for execution within the system700. In one implementation, the processor710is a single-threaded processor. In another implementation, the processor710is a multi-threaded processor. The processor710is capable of processing instructions stored in the memory720or on the storage device730to display graphical information for a user interface on the input/output device740.

The memory720stores information within the system700. In some implementations, the memory720is a computer-readable medium. The memory720is a volatile memory unit in some implementations and is a non-volatile memory unit in other implementations.

The storage device730is capable of providing mass storage for the system700. In one implementation, the storage device730is a computer-readable medium. In various different implementations, the storage device730may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.

The input/output device740provides input/output operations for the system700. In one implementation, the input/output device740includes a keyboard and/or pointing device. In another implementation, the input/output device740includes a display unit for displaying graphical user interfaces.

A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of this disclosure. Accordingly, other implementations are within the scope of the following claims.