Patent Application
20080303822
The present invention relates generally to presenting document text. More particularly, this invention relates to handling font metadata.
When a document's text is to be displayed visually, characters are mapped to glyphs in a font. A glyph is the actual artistic representation of an abstract glyph, in some typographic style, in the form of outlines or bitmaps that may be drawn on the screen or paper. Typically, the set of glyphs in a font observe similar attributes, such as design, size, appearance, etc. However, such attributes are mostly implicitly hidden inside glyphs in font data. As such, they are rarely applicable when selecting a font.
Furthermore, additional information produced from font data, such as derived from human knowledge about how a particular font or a set of fonts should be used is completely missing from typical fonts. For example, a font may be designed for an English user but not for a Chinese user, even though a common character presentable with the font may appear in both an English document and a Chinese document. In addition, a collection of fonts intended for writing letters may not be proper for writing business contracts. However, such critical information in determining which font to use is usually not present in font data associated with a font.
As a result, existing font systems are ineffective in providing sufficient information for handling fonts.
An embodiment of the present invention includes a method and apparatus that derive one or more selection criteria to select one or more fonts for presenting character data in an electronic document. The selection criteria may be applied on font metadata to select the fonts. An available font may be determined in place of a selected but unavailable font based on font metadata.
Other features of the present invention will be apparent from the accompanying drawings and from the detailed description that follows.
A method and an apparatus for metadata based font processing are described herein. In the following description, numerous specific details are set forth to provide thorough explanation of embodiments of the present invention. It will be apparent, however, to one skilled in the art, that embodiments of the present invention may be practiced without these specific details. In other instances, well-known components, structures, and techniques have not been shown in detail in order not to obscure the understanding of this description
Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification do not necessarily all refer to the same embodiment.
The processes depicted in the figures that follow, are performed by processing logic that comprises hardware (e.g., circuitry, dedicated logic, etc.), software (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. Although the processes are described below in terms of some sequential operations, it should be appreciated that some of the operations described may be performed in different order. Moreover, some operations may be performed in parallel rather than sequentially.
The term “host” and the term “device” are intended to refer generally to data processing systems rather than specifically to a particular form factor for the host versus a form factor for the device.
In one embodiment, font metadata may add information to a font to facilitate font selection. Font metadata may be based on human knowledge for representing, for example, what an associated font is designed for or intended to be used. A unified scale according to human perception may be applied to font metadata. In one embodiment, font metadata may enable measuring similarity between separate fonts closely approximating how a user would perceive. An automatic font selection and/or substitution may be made possible via similarity measurement based on font metadata. In one embodiment, a collection of fonts making sense to a user may be determined according to font metadata. A list of fonts presented to a user for selection may be pre screened from all available fonts according to font metadata, such as, for example, a list of heading fonts similar to a heading font specified in a document template.
In one embodiment, font metadata may include subjective and/or objective measurements of font attributes, such as a level of boldness, a scale of italic angle, whether a font is a mono space font, whether a font is a cursive font, whether a font is a serif font, a weight measure, a measure of width compression, the target group of users (e.g. English users), the thickness of strokes, an aspect ratio, and/or a level of ornamentation, etc. An attribute for font metadata may be associated with a value (e.g. Boolean, real value, integer value, strings etc.). For example, font metadata for Lucida Grande may include an attribute with a string value including “English” specifying English users as one of a target group of users for Lucida Grande font. In one embodiment, an attribute may be associated with a usage type for a corresponding font, e.g. whether it is a picture font, an artistic font, a fancy font, a font used for writing, a graphic arts font, or a math font etc. An attribute associated with objective measurements may be based on statistically collected levels of similarities among different fonts. In an aspect, metadata may be direct measures or may be measures derived from analysis and processing of statistical measures from psychometric testing of one or many different representative groups of people. In various aspects, font metadata may be used to sort a set of fonts, filter out a certain group of fonts, search for a particular font, or arrange a list of fonts to present to a user, etc. Font metadata may also be used in video for selecting preferential display, e.g. bitmap vs. vector, or for conformance to CCTV close caption standards.
In one embodiment, a context module 119 may determine a context for a document. A context may be related to a type of a document. For example, a business letter may belong to a different context as a document than a wedding invitation. In another embodiment, a context may include selected fonts and/or styles associated with a portion of character data in a document, such as, for example, multiple scripts intermixed within a line, a paragraph or a page of text. In another embodiment, a context may include predetermined relationships and/or constraints on font metadata associated with different parts of a document, such as, for example, type settings for headline text and body text in a document template for business contract. In one embodiment, a context module 119 may include semantic evaluation to automatically determine a context for a document. For example, a semantic evaluation may determine whether a user is working on a business letter or a wedding invitation. Semantic evaluation may be based on mapping semantic data to contexts according to predetermined relationships between document semantics and contexts. Additionally, a context module 119 may determine a context according to a user setting or existing font settings in a document.
In one embodiment, a font selection module 107 may receive a font request for one or more fonts from an interface module 101. An interface module 101 may be associated with a user interface. In one embodiment, an interface module 101 may be directly or indirectly coupled to an Application Programming Interface. A font selection module 107 may determine font selection criteria directly or indirectly from a received font request. In one embodiment, a font selection module 107 may derive selection criteria based on a document context from a context module 119 and/or a system setting stored in settings 117. A system setting may be applicable by default to multiple documents in a system, such as, for example, specifying a default language setting, e.g. “English”, for default font selection.
In one embodiment, a font selection module 107 may select a font from among a plurality of fonts stored in a font storage 103 according to selection criteria determined from a received font request, a context from a context module 119 and/or a system setting from settings 117. A font selection module 107 may match font metadata stored in a font storage 103 against selection criteria. A font may be unavailable if the corresponding font data are not present in a font storage 103. Font metadata for an unavailable font may be available in a font storage 103. If a font associated with matched font metadata is not available in a font storage 103, in one embodiment, a font selection module 107 may select similar fonts from available fonts in a font storage 103 according to similarity measurements in a similarity measurement module 109.
A similarity measurement module 109 may compute a similarity measure (e.g. a number to indicate level of similarity) between two separate fonts based on font metadata. In one embodiment, a similarity measurement module 109 may include correlation data 111 and/or classification data 113. Correlation data 111 may include, for example, statistics correlation relationships between separate fonts according to font metadata. Classification data 113 may include, for example, hierarchical tree-like grouping relationships among multiple fonts according to font metadata. Fonts may be grouped according to scripts, such as Latin script or Han Ideographic script. In one embodiment, a similarity measurement module 109 may perform attribute mapping through a metadata mapping engine 115 to transform one or more metadata attribute values for similarity measurement. Transformed metadata from a metadata mapping engine 115 may include a smaller or larger number of attributes than the original metadata. A similarity measurement module 109 may determine a similarity for a font according to one or more metadata values based on a correlation data 111, a classification data 113 and/or transformed metadata from a metadata mapping engine 115.
The processing logic of process 200 may derive selection criteria according to a font request, system settings, e.g. settings 117 of
At block 203, in one embodiment, the processing logic of process 200 may select one or more fonts according to selection criteria derived at block 201 and font metadata stored in a system. A selected font may be associated with font metadata matching selection criteria. A selected font may be unavailable if the corresponding font data are not stored in a system, such as in a font storage 103 of
In one embodiment, at block 205, when a selected font at block 203 is not available, the processing logic of process 200 may compute a similarity measure between the unavailable selected font with an available font from a font storage, such as font storage 103 of
As shown in
The mass storage 411 is typically a magnetic hard drive or a magnetic optical drive or an optical drive or a DVD RAM or a flash memory or other types of memory systems which maintain data (e.g. large amounts of data) even after power is removed from the system. Typically, the mass storage 411 will also be a random access memory although this is not required. While
Portions of what was described above may be implemented with logic circuitry such as a dedicated logic circuit or with a microcontroller or other form of processing core that executes program code instructions. Thus processes taught by the discussion above may be performed with program code such as machine-executable instructions that cause a machine that executes these instructions to perform certain functions. In this context, a “machine” may be a machine that converts intermediate form (or “abstract”) instructions into processor specific instructions (e.g., an abstract execution environment such as a “virtual machine” (e.g., a Java Virtual Machine), an interpreter, a Common Language Runtime, a high-level language virtual machine, etc.), and/or, electronic circuitry disposed on a semiconductor chip (e.g., “logic circuitry” implemented with transistors) designed to execute instructions such as a general-purpose processor and/or a special-purpose processor. Processes taught by the discussion above may also be performed by (in the alternative to a machine or in combination with a machine) electronic circuitry designed to perform the processes (or a portion thereof) without the execution of program code.
An article of manufacture may be used to store program code. An article of manufacture that stores program code may be embodied as, but is not limited to, one or more memories (e.g., one or more flash memories, random access memories (static, dynamic or other)), optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards or other type of machine-readable media suitable for storing electronic instructions. Program code may also be downloaded from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a propagation medium (e.g., via a communication link (e.g., a network connection)).
The preceding detailed descriptions are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the tools used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be kept in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The present invention also relates to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the required purpose, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), RAMs, EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the operations described. The required structure for a variety of these systems will be evident from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein. The foregoing discussion merely describes some exemplary embodiments of the present invention. One skilled in the art will readily recognize from such discussion, the accompanying drawings and the claims that various modifications can be made without departing from the spirit and scope of the invention.
This application is related to, and claims the benefits of, U.S. Provisional Patent Application No. 60/943,045, filed on Jun. 9, 2007 entitled “META DATA BASED FONT SELECTION,” Julio Gonzalez et al. which is hereby incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60943045 | Jun 2007 | US |
