WO1994024623A1 - Synthetic font generator - Google Patents

Synthetic font generator Download PDF

Info

Publication number
WO1994024623A1
WO1994024623A1 PCT/US1994/004242 US9404242W WO9424623A1 WO 1994024623 A1 WO1994024623 A1 WO 1994024623A1 US 9404242 W US9404242 W US 9404242W WO 9424623 A1 WO9424623 A1 WO 9424623A1
Authority
WO
WIPO (PCT)
Prior art keywords
font
character
file
computer
generic
Prior art date
Application number
PCT/US1994/004242
Other languages
French (fr)
Inventor
Ernest A. Brock
Lawrence G. Applegate
Original Assignee
Ares Software Corp.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ares Software Corp. filed Critical Ares Software Corp.
Priority to AU66368/94A priority Critical patent/AU6636894A/en
Publication of WO1994024623A1 publication Critical patent/WO1994024623A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K15/00—Arrangements for producing a permanent visual presentation of the output data, e.g. computer output printers
    • G06K15/02—Arrangements for producing a permanent visual presentation of the output data, e.g. computer output printers using printers
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/22—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators characterised by the display of characters or indicia using display control signals derived from coded signals representing the characters or indicia, e.g. with a character-code memory
    • G09G5/24—Generation of individual character patterns
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K2215/00—Arrangements for producing a permanent visual presentation of the output data
    • G06K2215/0002—Handling the output data
    • G06K2215/002—Generic data access
    • G06K2215/0028—Generic data access characterised by the format per se
    • G06K2215/0034—Outline coding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K2215/00—Arrangements for producing a permanent visual presentation of the output data
    • G06K2215/0002—Handling the output data
    • G06K2215/004—Generic data transformation
    • G06K2215/0054—Geometric transformations, e.g. on rasterised data

Definitions

  • This invention relates to the field of character and image representation, storage, transmission and generation on a computer output device. More particularly, it relates to a method and apparatus for producing scalable contour data for use in displaying alphanumeric and other characters on a computer screen or printer, as well as to the storage and transmission of text and other collections of characters.
  • a collection of characters (numbers, letters and other symbols) that share common design features is called a "typeface”.
  • a particular instantiation of a typeface design, in a particular medium, is referred to as a "font".
  • font refers to a rendering of a typeface in a single point size and a single weight, but we shall not impose such a limitation herein.
  • fonts were typically rendered in media such as metal slugs or photomasks for phototypesetters. Now, fonts are frequently rendered in digital form, for use in digital computers and digital display devices, such as personal computers and laser printers, to produce output in a par-icular typeface design.
  • fonts in digital form there are several commercially standard formats in widespread use for representing fonts in digital form, such as formats adopted and popularized by Bitstream Inc. cf Cambridge, Massachusetts; Adobe Systems, Inc. of Mountain View, California; Apple Computer, Inc., of Cupertino, California; Microsoft Corporation of Bellevue, Washington; URW of Hamburg, Germany; and Agfa Compugraphic of Wilmington, Massachusetts.
  • Each format has its unique characteristics. They share in common, though, the fact that for a given typeface design, a font has for each character a unique computer program which encodes the unique design of that character.
  • a font is thus a collection of computer programs and data. Each typeface thus is reproduced from its own set of unique character programs. For instance, one set of character programs is used to represent the characters of the typeface Times and another set of character programs is used to represent the typeface Helvetica.
  • the character programs are not universal, but differ with each of the available font-encoding formats.
  • a digital font for a full Roman character set requires about 30-60 kB (kilobytes) of memory (on average, assume 45 kB per font) .
  • a document prepared with a modern word processing or desktop publishing system may typically contain several typefaces. Consequently, when such a document is to be stored or transmitted electronically, it may be necessary to transmit (or store) along with the text data for the document one or more font files of about 45kB each.
  • a document set in four fonts will require about 180kB in font files alone, in addition to the text file for the document.
  • a number of fonts will have to be stored, each at an average of about 45 k3.
  • the size(s) of the font file( ⁇ ) does(do) not scale with document size.
  • the same large font files are needed for a 4k text file as for a 400k text file.
  • different weights of a typeface design may be treated as different fonts, exacerbating the problem.
  • intelligent font scaling algorithms can be used to produce from a single font characters of different sizes, so a font is not needed for each different point size of type to be employed in a document.
  • a “category" of typeface is the term used herein to distinguish from each other alphabets of distinctly different topology: e.g. , Roman type, Cyrillic type, Arabic type, Kanji type and other forms of type.
  • a specific typeface design is represented as a compact enumeration of modifications to be made to its base font. These enumerations are contained in an encoded file which comprises program/data structures of defined arrangement.
  • a descriptor file for a specific typeface design requires only about 2K of data.
  • the generic base font may be made resident in a printer, video terminal or the like. Thus, only the descriptor file(s) for the typefaces in use need be stored or transmitted with a document; the generic base font is essentially part of the environment. Only about 2K additional program/data is needed for each typeface descriptor file which is to be associated with a specific document.
  • descriptor files may be easily modified, thus providing a simple way to alter character programs so as to alter the appearance of type. That is, by modifying an existing descriptor file, it i ⁇ possible to generate a typeface design which is varied, to almost any desired degree and in almost any desired way, from a previously encoded typeface design. Further, the parameters of two or more typeface designs readily can be blended by combining appropriate fields in their descriptor files, according to any desired mathematical algorithm (e.g., by performing a weighted average) . Thus a user can easily blend two or more typeface designs, or otherwise modify a typeface design.
  • a library of typeface designs comprises a library of their descriptor files plus the associated generic base font. Thu ⁇ a library of, say, one hundred fonts at a total of about 4.5MB volume can be replaced by a generic base font of about 200 kB, descriptor files of 200-300 kB and a font generator of about 60 kB. Not only is there a large savings in memory and transmission time, but also there is much enhanced capability given the user.
  • Fig. 1 is a diagrammatic illustration of a synthetic font generation system according to the present invention.
  • Fig. 2 is a diagrammatic illustration of a base font according to the invention.
  • Fig. 3 is a pictorial illustration of two different base design forms for the letter "a" - a Humanist form and a Grotesque form, as an example of a character available in two base design forms;
  • Fig. 4 is a diagrammatic illustration of an exemplary glyph in a base font according to the invention, which glyph represent ⁇ a character stem;
  • Fig. 5 is a diagrammatic illustration of a serifed stem produced by modifying the base stem of Fig. 4.;
  • Fig. 6 is a diagrammatic illu ⁇ tration of a base font data structure, or program, corre ⁇ ponding to the ⁇ tem glyph of Fig. 4;
  • Fig. 7 is a diagrammatic illu ⁇ tration of a font descriptor file according to the invention, which is used with the base font program file of Fig. 6 to produce the ⁇ erifed ⁇ tem de ⁇ ign of Fig. 5;
  • Fig. 8 is a diagrammatic illustration of a character program produced by the generator of the present invention, from the base font data ⁇ tructure of Fig. 6 and the de ⁇ criptor file of Fig. 7;
  • Fig. 9 is a diagrammatic illustration of a font descriptor file used with the base font of Figs. 4 and 6 to generate the output contour of Fig. 10;
  • Fig. 10 is a pictorial illustration of the output contour generated by applying the font descriptor file of Fig. 9 to the ba ⁇ e font of Figs. 4 and 6;
  • Fig. 11 is a diagrammatic illu ⁇ tration of a character program produced by the generator of the present invention, from the base font data ⁇ tructure of Fig. 6 and the descriptor file of Fig. 9;
  • Fig. 12 is a diagrammatic illu ⁇ tration of a de ⁇ criptor file according to the present invention, produced by blending the descriptor file of Fig. 7 with the de ⁇ criptor file of Ficr. 9;
  • Fig. 14 is a pictorial illustration of the output contour generated by applying the font descriptor file of Fig. 12 to the base font of Figs. 4 and 6;
  • Fig. 15 is a pictorial illustration of two weights of a given typeface u ⁇ ed to generate a third, intermediate weight of the typeface, in accordance with this invention.
  • Fig. 16 is a pictorial illustration of two typeface designs, one serifed and one ⁇ an- ⁇ erifed, but otherwi ⁇ e similar, used to generate a third, typeface which is partially ⁇ erifed, in accordance with this invention;
  • Fig. 17 is a pictorial illustration of two width ⁇ of a given typeface u ⁇ ed to generate a third, intermediate width of the typeface, in accordance with thi ⁇ invention
  • Fig. 18 i ⁇ a pictorial illu ⁇ tration of one kind of feature ⁇ tretching according to the invention
  • Fig. 19 i ⁇ a pictorial illu ⁇ tration of another kind of feature ⁇ tretching according to the invention.
  • Fig. 20 i ⁇ a pictorial illu ⁇ tration of the distribution of curve control points according to the invention, for features that are represented as a curve in one typeface design and a straight line in another;
  • Fig. 21 is a diagrammatic representation for a data ⁇ tructure for a file or a portion of a file constituting a Directory of Tables, comprising a directory specifying the addre ⁇ cff ⁇ et to each of the table ⁇ in a font according to the invention;
  • Fig. 22 i a diagrammatic illu ⁇ tration of an exemplary data structure for a table containing information specific to the base font according to the invention
  • Fig. 23 is a diagrammatic illustration for a data structure called Glyph Name Directory herein;
  • Fig. 24 i ⁇ a diagrammatic illu ⁇ tration of a data ⁇ tructure for a table called Glyph Directory herein;
  • Fig. 25 i ⁇ a diagrammatic illustration of a data ⁇ tructure for storing the data for an individual glyph in the Glyph Data Table herein;
  • Fig. 26 is a diagrammatic illustration for a data structure called Font Names Directory according to the invention.
  • Fig. 27 is a diagrammatic illustration of a data structure called Font Directory
  • Fig. 28 i a diagrammatic illustration of a data structure for storing each font descriptor in the Font Descriptor Table according to the invention
  • Fig. 29 i ⁇ a pseudo-code rendering illustrating an algorithm for generating an output font according to the invention, from a ba ⁇ e font and a font de ⁇ criptor;
  • Fig. 31 i a data ⁇ tructure repre ⁇ entation of encoding for each node of the font blend tree of Fig. 30;
  • Fig. 33 i a diagrammatic illustration of a data ⁇ tructure providing an encoded repre ⁇ entation of the exemplary blend tree of Fig. 32;
  • Fig. 34 is a diagrammatic illustration in pseudo code form of an algorithm for converting a blend font descriptor into a font descriptor, which can then be used in the algorithm of Fig. 29 to produce an output font.
  • a complete typeface de ⁇ ign for a Roman character set includes typically about one hundred to several hundred characters - upper and lower ca ⁇ e letters, numerals, punctuation marks and special svmbols.
  • Various techni ⁇ es are in common u ⁇ age for providing digital encoding ⁇ of typeface designs, to allow the reproduction of those design ⁇ on output devices such as video screens and laser printers.
  • the u ⁇ er may require, there have been developed in recent year ⁇ variou ⁇ ⁇ calable font technologie ⁇ (such as Adobe Systems ' Post ⁇ cript outlines, Bitstream's Fontware and Speedo format ⁇ , Agfa' ⁇ Intellifont, Apple Computer ' ⁇ True Type, and other ⁇ ).
  • each character in the typeface i ⁇ represented by a character program which, in turn, represents the character in outline form.
  • the character program comprises a collection of data points, ⁇ ome of which are on the character outline and other ⁇ which are not on the character outline, and in ⁇ tructions as to how to interpret and treat the data points in order to construct therefrom an image of the embodied character.
  • the techniques shown in the aforesaid patents, for example, then are used to produce bit map repre ⁇ entation ⁇ of the character ⁇ at selected (i.e., scaled) sizes and resolution ⁇ .
  • the actual output di ⁇ play i ⁇ provided from these bit map representation ⁇ .
  • a system 10 comprises at least one generic base font 12, one or more font de ⁇ criptor file ⁇ 14 - 1 and a font generator, or "engine,” 16.
  • the generator 16 operate ⁇ in the manner described below, to generate a digital font corresponding to the one or more font de ⁇ criptor file ⁇ which are active at a given time; alternatively, ⁇ ince a font is a collection of character programs, the generator may be ⁇ ai to generate character programs for the font.
  • each generic ba ⁇ e font program 12 include ⁇ a ⁇ et of character de ⁇ criptions, in the form of character programs 22 -
  • each character program contains one or more fields identifying the corresponding character.
  • the character programs may be arranged in a random order, in which ca ⁇ e the first (or ⁇ ome other) field in the program file i ⁇ a character name. Thu ⁇ , if the first character program is for the numeral "8," the first field in the program file may be the word “eight” or a binary code for the character "8. "
  • a design variable can be specific to an individual character program or it can apply to a collection of character program ⁇ .
  • Design feature 24 may be stroke weight, feature 24_ may be letter height, etc.
  • a special character program (the "base character program") is provided for each character in the font.
  • the term "character” is intended to encompass both entire letter form ⁇ , numeral ⁇ and ⁇ ymbols, and component parts thereof, such a ⁇ ⁇ erif ⁇ , stems, and the like. These component parts are ⁇ ometime ⁇ called "glyphs.” Where it is nece ⁇ ary to distinguish the two types of characters, those formed from multiple glyphs will be called “full character ⁇ .” Where multiple glyph ⁇ are involved, instructions must also be included for a ⁇ embling full character ⁇ from the available glyphs. Thus, it will be understood that a "glyph” may comprise a unitary character on a piece of a character.
  • a character i ⁇ encoded into data and in ⁇ truction ⁇ representing the contour ⁇ of the character plu ⁇ a sufficient number of control points to permit replication of a wide range of design characteristic ⁇ , including strokes, serifs and other ornamentation.
  • More than one set of contours may be allocated (or, alternatively, more than one character program may be provided) , for a character which can be drawn with contours and base designs which differ significantly in topology.
  • the lower ca ⁇ e letter "a” may be repre ⁇ ented [in] two different ba ⁇ e de ⁇ ign form ⁇ : in the Humani ⁇ t form 26 and the Grotesque form 28.
  • the character program or program ⁇ for the letter "a” must thus provide for both base forms. Consequently, 22 may corre ⁇ pond to the Humani ⁇ t form of the letter "a” and 22_ may correspond to the Grotesque form.
  • a de ⁇ criptor file for a given font will ⁇ elect the de ⁇ ired form for each character available in multiple form ⁇ , by ⁇ electing appropriate character program ⁇ .
  • Fig ⁇ . 4-8 provide a more ⁇ pecific exemplary illustration of this technique.
  • a character stem may or may not have a serif
  • control points are provided on the ba ⁇ e character contour (i.e., in the ba ⁇ e font character program) to allow for "expansion" to serif form or "contraction" to san ⁇ erif form.
  • control point ⁇ CP1, CP2 and CP3 are provided in association -with the ba ⁇ e coordinates of point 34; and control points CP4, CP5 and CP6 are provided in association with the ba ⁇ e coordinate ⁇ of point 36.
  • control point ⁇ CP1-CP6 may be moved outwardly from their location in the base font to form a serif.
  • the control points of each character contour include numeric data for specifying an initial position in the coordinate ⁇ yste u ⁇ ed for the descriptor files.
  • thi ⁇ is, and usually will be, a Cartesian coordinate plane.
  • the numeric data comprising the control points further includes a list of trajectories. Each trajectory encodes three data: a displacement direction, a displacement magnitude and the design feature number with which the trajectorie ⁇ a ⁇ ociate.
  • Each control point' ⁇ list of trajectories need only include trajectories for the design features that affect it.
  • Trajectorie ⁇ are specified, as well, for controlling feature ⁇ relating to all of the character ⁇ in the font and al ⁇ o for controlling feature ⁇ specific to an individual character.
  • trajectories are specified for controlling the general width of all serifs in the font and for modifying the widths of the serifs in a specific character.
  • Control points are preferably located in the ba ⁇ e font ⁇ o that their trajectorie ⁇ are in "outward" direction ⁇ when another font i ⁇ generated from the ba ⁇ e font.
  • Thi ⁇ produces fewer rounding errors than the alternative: locating the control points on the expanded form of a character and their moving them "inwardly" - e.g., to produce a non-serifed font from a ba ⁇ e ⁇ erifed font.
  • Control point CP1 ⁇ pecified a trajectory to the left a di ⁇ tance "q" to point NPl. (Or to the left a distance q and down a distance "r", depending how the character height is to be adjusted to compensate for the "addition" of the ⁇ erif.)
  • Control point CP2 ⁇ pecified a trajectory to the location of point NP2.
  • Control point CP3 either ⁇ pecified no motion or a vertical trajectory a di ⁇ tance r.
  • Control point ⁇ CP4-CP6 in this example provided mirror image specification ⁇ mapping them to the location ⁇ of point ⁇ NP4-NP6, respectively.
  • the tran ⁇ formation from the generic base ⁇ tem 32 of Fig. 4 to the ⁇ erifed ⁇ tem 32' of Fig. 5 re ⁇ ult ⁇ from u ⁇ e of a descriptor file to operate on the base font, as stated above.
  • Fig. 6 there is shown in diagrammatic form a corresponding base font data structure (or program) 40, or portion of a base font data structure for the stem 32 of Fig. 4.
  • FIG. 7 shows in diagrammatic form a font de ⁇ criptor file 50 which is used by the generator to produce from the generic base font the final serifed ⁇ tem de ⁇ ign of Fig. 5.
  • the generator produces the character (glyph) program 60 for the new contour, listed in Fig. 8.
  • Figs. 4-8 of cour ⁇ e, ⁇ how ⁇ how the present invention works relative to a single feature of a character - in this case, a ⁇ tem.
  • the ⁇ ame method i ⁇ employed to generate an entire character program for outputting the complete character image.
  • the control points in the base font may be processed in the same sequence a ⁇ that in which they are arranged in the ba ⁇ e font, though thi ⁇ method doe ⁇ not require such sequential proces ⁇ ing.
  • a de ⁇ criptor file for a specific font design preferably include ⁇ a ⁇ etting value for each of the ba ⁇ e font' ⁇ de ⁇ ign variable ⁇ (which may involve one or more control points), spacing information for each character and a list of character forms to select for those character ⁇ for which multiple ba ⁇ e form ⁇ are available - e.g., a flag which ⁇ elect ⁇ either the Humani ⁇ t "a” or the grotesque "a".
  • the specification, or descriptor file is very compact compared to the file which encodes the base font.
  • the generator 16 produce ⁇ a contour repre ⁇ entation for a ⁇ pecific typeface by combining the appropriate de ⁇ criptor file with each of the generic base font's character program ⁇ .
  • Thi ⁇ combination proce ⁇ include ⁇ not only the movement of contour control point ⁇ and attendant curve-fitting, but also may involve resolving designs features, reducing the contour representation to the minimum set of point ⁇ needed for each character, and/or a ⁇ signing spacing to each character.
  • the process is illustrated in Fig. 29, which is di ⁇ cus ⁇ ed below. It is useful to note here that for each contour of a glyph, as outlined in Fig.29, three proces ⁇ e ⁇ are executed. Fir ⁇ t, for at lea ⁇ t ⁇ elected area ⁇ of the control point ⁇ of the base character, a computation is performed to yield a displacement by which the control point is mapped to a new location to produce the contour of the ⁇ elected de ⁇ ign.
  • proce ⁇ s 29-1 It i ⁇ not nece ⁇ ary that in proce ⁇ s 29-1 a displacement be computed for each and every control point. Selected control points can be chosen (in proce ⁇ s 29-1 this is indicated by the line "if flag for point specifies that design offsets are used) to be displaced. Then, in proces ⁇ 29-2 for each control point whose displacement was not computed in process 29-1, a displacement value is determined by interpolating between mapped location ⁇ determined for neighboring contol point ⁇ in proce ⁇ 29-1.
  • a "filter” routine may be executed to remove overlapping and non-e ⁇ ential point ⁇ . This is process 29-3.
  • the result is a character program representing, in part, the minimum set of contour points necessary for encoding the selected design.
  • the details of such a filter routine do not form part of this invention and will not be discussed further, to avoid obscuring the description of the invention. It will be appreciated that software developers, knowledgeable about font software, will readily be able to devise suitable filter implementations.
  • each of the thus-generated characters in the output font may then be adjusted horizontally and vertically, and assigned an advance width (i.e., distance to the origin of the next character), u ⁇ ing the font-wide value ⁇ ⁇ pecified in the font de ⁇ criptor file.
  • Horizontal and vertical adjustment is accomplished by simple coordinate translation. Width adjustment may require scaling.
  • the invention further provides the capability of blending two (or more) font descriptor files to create useful intermediate typeface designs. Any two font descriptor files can be combined in a variety of way ⁇ to create a third de ⁇ criptor file. The re ⁇ ulting de ⁇ criptor file can be further combined to yield yet additional descriptor files. Many combinations of the design features and spacing value ⁇ of two de ⁇ criptor file ⁇ re ⁇ ult in intermediate font de ⁇ ign ⁇ that ⁇ hare features of each of the two base typefaces. For instance, with reference to Fig. 15 a blend between a light weight 110 and a heavy weight 112 of a typeface will yield a weight 114 ⁇ omewhere between the heavy and the light. A blend (See Fig.
  • a blend (See Fig. 17) between a narrow width 122 and a wide width 124 may result in an intermediate width typeface design 126, depending on the width weighting ⁇ a ⁇ igned the de ⁇ criptor file ⁇ corresponding to typefaces 122 and 124.
  • Fig. 6 is again the ba ⁇ e character de ⁇ ign program.
  • the generator now u ⁇ ed the descriptor file 70 of Fig. 9, to produce in this ca ⁇ e the output contour 72 of Fig. 10, repre ⁇ ented a ⁇ well in the table 80 of Fig. 11.
  • the generator function ⁇ ⁇ pecified by de ⁇ criptor file 70, for producing the contour data of table 80, is
  • x coordinate a + 0c + 0.5e
  • y coordinate b + Od + 0.5f.
  • a fifty-fifty mix or ⁇ ixty-five-thirty-five, or ⁇ ome other mix) or different operation ⁇ can be performed on different variable ⁇ (e.g., a de ⁇ criptor file can be created which repre ⁇ ent ⁇ 100% the serif from a first descriptor file and a character weight which is a sixty-forty blend of the weights from two de ⁇ criptor files) .
  • variable ⁇ e.g., a de ⁇ criptor file can be created which repre ⁇ ent ⁇ 100% the serif from a first descriptor file and a character weight which is a sixty-forty blend of the weights from two de ⁇ criptor files
  • contour data u ⁇ t contain a ⁇ ufficient number of control points to represent the most complex po ⁇ ible rendering of the character de ⁇ ign.
  • Tho ⁇ e ⁇ killed in digital typography employ a variety of computer-aided de ⁇ ign tools (i.e., computers and computer programs) to as ⁇ ure they have ⁇ elected ⁇ ufficient contour data to repre ⁇ ent a character ⁇ hape to the de ⁇ ired fidelity) .
  • the ⁇ et of control point ⁇ for that feature preferably are di ⁇ tributed initially, in the ba ⁇ e font, at a ⁇ ingle Carte ⁇ ian coordinate.
  • serif ⁇ disappear in san ⁇ erif de ⁇ ign ⁇ .
  • the san serif de ⁇ ign i ⁇ preferably used for a base font. In the base font, therefore, all the control points as ⁇ ociated with the ⁇ erif for a given ⁇ tem preferably are clu ⁇ tered at the corner of the ⁇ tem.
  • Multiple control points will, thu ⁇ , have the same coordinates in the base font, but each point has its own unique identity and can be mapped independently to the output font.
  • the design feature vectors for the serif points are specified such that the point ⁇ separately are moved, by the generator, from the corner of the ⁇ tem to their de ⁇ ired re ⁇ ting positions in the serif.
  • Some character de ⁇ igns are created by stretching a base character design.
  • the stretching process can be achieved by elongating the curves and lines of the base de ⁇ ign. See, for example, Fig. 18, wherein the lower ca ⁇ e letter "h", 136, i ⁇ to be modified by ⁇ tretching the arch from a height t, to a height t 2 a ⁇ ⁇ hown at 138. Thu ⁇ , the increase in height t can be achieved by changing the length of segments 139a, 139b in the left and right stem ⁇ . In other de ⁇ ign ⁇ , ⁇ tretching i ⁇ achieved by introducing additional curve and line ⁇ egment ⁇ to the original de ⁇ ign.
  • the point ⁇ for the additional ⁇ egment ⁇ be placed at a ⁇ ingle point between the ⁇ egments of the base design. See, for example, Fig. 19, wherein a round letter "o", 140, in a base font is to be transformed to a stretched form 150 for an output font.
  • the outer contour 140 may be formed, for example, of four ⁇ egment ⁇ 141-144.
  • the generator 16 may be implemented a ⁇ a digital computer executing an appropriate program to carry out the function ⁇ ⁇ pecified herein.
  • the nece ⁇ ary data structures which would reside in the memory of the computer (main memory or mas ⁇ ⁇ torage), and the operation ⁇ for one exemplary embodiment of thi ⁇ type, are shown in Figs. 19.
  • a ba ⁇ e font may be implemented as a set of tables, each containing data repre ⁇ enting piece ⁇ of the font. That i ⁇ , character ⁇ may be a ⁇ embled from piece ⁇ which ⁇ ee repeated u ⁇ e among various character ⁇ in the font, ⁇ uch a ⁇ ⁇ tem ⁇ , arches, serif ⁇ , and ⁇ o forth. The ⁇ e pieces are referred to a ⁇ "glyph ⁇ .” (Of cour ⁇ e, a ⁇ stated above, a character may be a single glyph.) The base font contains both the data for the individual glyph ⁇ and for the output font descriptions.
  • a typical set of table ⁇ might be the following:
  • the table named Directory of Tables contain ⁇ a directory which specifies the addre ⁇ off ⁇ et to each of the table ⁇ in the font, from an initial addre ⁇ .
  • the Directory of Table ⁇ table may have the ⁇ tructure ⁇ hown in Fig. 21, for example.
  • a ⁇ indicated there, a fir ⁇ t table entry, 180, contain ⁇ the value of the variable "numTables", which represent ⁇ the number of table ⁇ in the font.
  • a ⁇ econd entry 182 i ⁇ itself one or more tables, each composed of numTables pair ⁇ of four-character table name ⁇ 182a and the off ⁇ et 182b from the beginning of the font to that particular table.
  • the table Font Info depicted in Fig. 22, for example, contain ⁇ information ⁇ pecific to thi ⁇ ba ⁇ e font.
  • This information may include, but need not be limited to, the following, for example: the value of a variable fontID, 190, which is a unique identification number for the font; the value of a variable "version", 192, which is the version number for the font; a string 194 containing the name of the font; and a string 196 containing a copyright notice for the font.
  • Each glyph in the base font has a name.
  • the table Glyph Name Directory illustrated in Fig. 23 i ⁇ a cro ⁇ index ⁇ pecifying the off ⁇ et to each glyph name in the Glyph Name ⁇ table.
  • the Glyph Name Directory begin ⁇ with a datum giving the value of the variable "numGlyph ⁇ ", 202, the number of glyph ⁇ in the Glyph Names table.
  • the Glyph Name ⁇ table contain ⁇ , in sequence, a string for the name of each glyph in the font.
  • the table Glyph Directory of Fig. 24 contains a listing of the offset to the data for each glyph in the ba ⁇ e font.
  • the fir ⁇ t entry, 212 contain ⁇ the value of the variable 'numGlyph ⁇ ," which represents the number of glyphs named in the Glyph Data table.
  • the table Glyph Data contains the contour data for all the glyphs in the base font.
  • An initial table entry 222 preferably i ⁇ a character code for the glyph.
  • Thi ⁇ code may, for example, be in the ⁇ o-called Unicode ⁇ tandard or in ⁇ ome other repre ⁇ entational code.
  • designMap which contains a mapping of design feature ⁇ for this glyph to font-wide design features.
  • Thi ⁇ is followed by a datum 226, originPoint, which specifie ⁇ the character origin off ⁇ et, and a datum 228, widthPoint, which specifies the character width.
  • the originPoint, widthPoint and point ⁇ in segments each are represented by a horizontal coordinate, x, and a vertical coordinate, y; further, if the point has a set of design offset ⁇ , they are included in the ⁇ pecification a ⁇ an array horizontalOffsets and an array verticalOffsets . These arrays specify, respectively, the horizontal and vertical di ⁇ placement ⁇ associated with each design feature present in the glyph.
  • design offsets may be stored only for the de ⁇ ign parameter ⁇ associated with the glyph.
  • the de ⁇ ignMap content ⁇ ⁇ pecify how the glyph' ⁇ de ⁇ ign offset ⁇ map onto the font-wide de ⁇ ign parameter ⁇ .
  • the designMap would contain an array ⁇ uch a ⁇ 1,3,5,0 (the final 0 ⁇ ignalling the end of the array) .
  • the horizontalOff ⁇ et ⁇ array and the verticalOff ⁇ et ⁇ array for point ⁇ with de ⁇ ign off ⁇ ets would thus contain only three entries each in this example.
  • the Font Names Directory table i one containing a li ⁇ t of off ⁇ et ⁇ to each of the output font name ⁇ in the Font Names table. It has the structure ⁇ hown in Fig. 26. That i ⁇ , the fir ⁇ t entry, 242, numFontName ⁇ , i ⁇ a variable denoting the number of font names in the FontNames table. Next, there follows an array 246 of offsets to tho ⁇ e name ⁇ .
  • Font Name ⁇ i a table of strings for all the font names defined in the Font Directory.
  • the Font Directory table is a list of offset ⁇ to the output font descriptors in the Font Discription Table.
  • the Font Directory table ha ⁇ the ⁇ tructure ⁇ how in Fig. 27. It fir ⁇ t contain ⁇ the value of the variable numFont ⁇ , which i ⁇ the number of font de ⁇ criptor ⁇ in the Font Descriptor ⁇ table, followed by an array, 252, of all sets to the start of each de ⁇ criptor.
  • Font De ⁇ criptor ⁇ i the table containing the data for all the output fonts.
  • the vector shown in Fig. 28 contains setting ⁇ for each de ⁇ ign parameter encoded in the ba ⁇ e font.
  • Other design parameter ⁇ are freely a ⁇ igned.
  • font ⁇ can be de ⁇ cribed as being combinations of design font ⁇ de ⁇ criptor ⁇ from the ba ⁇ e font.
  • Blend ⁇ of font ⁇ may be compactly de ⁇ cribed, u ⁇ ing the data ⁇ tructure ⁇ hown in Fig. 30.
  • the fir ⁇ t entry, 302 contain ⁇ a identification for the ba ⁇ e font with which this descriptor work ⁇ .
  • string, 304 naming the font family; and a string 306, describing the weight of the font.
  • tnere is a binary tree, 308, describing the blend.
  • each node of the blend tree may be encoded a ⁇ ⁇ hown in Fig. 31.
  • variable "amount”, 310 specifies the numeric amount (i.e., percentage) the related font provides to the blend. Then there is ⁇ pecified the identification of the ba ⁇ e font. Next is a flag which specifie ⁇ that the base font i ⁇ ne ⁇ ted (i.e, derived from ⁇ till another font de ⁇ criptor). Also included is the identification of the blend font or a flag ⁇ pecifying that the blend font it ⁇ elf i ⁇ nested, 312.
  • a blend font that was derived by combining a base font 300 with 30% of a blend font compo ⁇ ed of a ba ⁇ e font, which i ⁇ made up of font 200 blended 75% with blend font 400, which, in turn, i ⁇ blended 50% with blend font 500, would yield a tree ⁇ tructure ⁇ uch a ⁇ ⁇ hown in Fig. 32, and repre ⁇ ented, more particularly, in Fig. 33.
  • the blend font descriptor illustrated in Figs. 30-33 is turned into an output font by first converting the blend font de ⁇ criptor into a font de ⁇ criptor.
  • the re ⁇ ulting font de ⁇ criptor can then serve as input to the generator algorithm of Fig. 29 to produce an output font.
  • blend font descriptors in general, are much smaller than basic font descriptors.
  • glyph ⁇ and character ⁇ are ⁇ ome of those involved for Roman fonts
  • the invention can be used to generate Kanji or other font categories, as well.
  • Other readily conceivable variation ⁇ on the di ⁇ clo ⁇ ed embodiment include parametric naming of fonts. This is, a descriptor file can be built from a vector (i.e., string of data values) which specifies a typeface or font by name or number, u ⁇ ing a table look-up approach. Thi ⁇ may be combined with a taxonomic approach to font naming, ⁇ o that a font name i ⁇ formed by concentrating a number of data filed ⁇ , each of which contains a specific parameter value.
  • Typical parameters might include font width, height, alternative character topology choices, ⁇ eri ⁇ / ⁇ an serif, italic slant, and so forth.
  • the string of numerical values for the parameters constitute ⁇ the typeface name. From thi ⁇ name, a table provide ⁇ a pointer to a corresponding descriptor file.

Abstract

A computer-implemented apparatus and method for generating an output digital font from a base font (12) and one or more font descriptor files (14). The method involves, in an exemplary embodiment, the steps of retrieving from memory a file containing instructions and data for a generic base font; retrieving from memory a font descriptor file (14) containing specifications for operating upon the base font (12) to produce the desired output font; and then generating the output font by performing operations upon the base font (12) in accordance with the specifications contained in the font descriptor file (14), to produce a character program for each character in the base font (12) wherein the data representing the output font is the generic font data as transformed in accordance with said specification. Two or more font descriptor files (14) may be combined, such as by using mathematical weighted averaging of the parameter values of different typographic design features, or otherwise, to create font descriptor files for hybrid typefaces.

Description

SYNTHETIC FONT GENERATOR
Field of the Invention
This invention relates to the field of character and image representation, storage, transmission and generation on a computer output device. More particularly, it relates to a method and apparatus for producing scalable contour data for use in displaying alphanumeric and other characters on a computer screen or printer, as well as to the storage and transmission of text and other collections of characters.
Background of the Invention
A wide range of analog character shapes exist for representing a given alphanumeric character or typographic symbol (i.e., numbers, letters, punctuation marks and dingbats). Each such shape is distinguished by its various design features such as, but not limited to, (Underlying geometry, stroke thickness, character height, serifs, joinery, placement and number of contours and ratio of thin-to-thick strokes. A collection of characters (numbers, letters and other symbols) that share common design features is called a "typeface". A particular instantiation of a typeface design, in a particular medium, is referred to as a "font". Often, the term font refers to a rendering of a typeface in a single point size and a single weight, but we shall not impose such a limitation herein. Until the last several years, fonts were typically rendered in media such as metal slugs or photomasks for phototypesetters. Now, fonts are frequently rendered in digital form, for use in digital computers and digital display devices, such as personal computers and laser printers, to produce output in a par-icular typeface design.
There are several commercially standard formats in widespread use for representing fonts in digital form, such as formats adopted and popularized by Bitstream Inc. cf Cambridge, Massachusetts; Adobe Systems, Inc. of Mountain View, California; Apple Computer, Inc., of Cupertino, California; Microsoft Corporation of Bellevue, Washington; URW of Hamburg, Germany; and Agfa Compugraphic of Wilmington, Massachusetts. Each format has its unique characteristics. They share in common, though, the fact that for a given typeface design, a font has for each character a unique computer program which encodes the unique design of that character. A font is thus a collection of computer programs and data. Each typeface thus is reproduced from its own set of unique character programs. For instance, one set of character programs is used to represent the characters of the typeface Times and another set of character programs is used to represent the typeface Helvetica. The character programs are not universal, but differ with each of the available font-encoding formats.
Typically, a digital font for a full Roman character set (i.e., typeface) requires about 30-60 kB (kilobytes) of memory (on average, assume 45 kB per font) . A document prepared with a modern word processing or desktop publishing system, though, may typically contain several typefaces. Consequently, when such a document is to be stored or transmitted electronically, it may be necessary to transmit (or store) along with the text data for the document one or more font files of about 45kB each. A document set in four fonts will require about 180kB in font files alone, in addition to the text file for the document. Similarly, if a laser printer is to be provided with the capability of printing in a number of resident typefaces, a number of fonts will have to be stored, each at an average of about 45 k3. Moreover, the size(s) of the font file(ε) does(do) not scale with document size. The same large font files are needed for a 4k text file as for a 400k text file. In general, different weights of a typeface design may be treated as different fonts, exacerbating the problem. Fortunately, intelligent font scaling algorithms can be used to produce from a single font characters of different sizes, so a font is not needed for each different point size of type to be employed in a document.
Thus among the most significant drawbacks of such prior digital fonts is their size. Each font consumes a considerable amount of memory and represents a large additional amount of data to be transmitted along with the encoded text of a document to be output using that font (or, more correctly, the typeface represented by the font) . A further restriction inherent in the use of such fonts is that the user must have available, when a document is being output, fonts for all typefaces the user wishes to employ. This means the user is constrained in his or her creativity to use of the typefaces at hand.
Summary of the Invention
These and other drawbacks of the prior art are overcome, and additional advantages achieved, with a unique system employing a single, generic base font from which many specific typeface designs can be derived, a descriptor file for each specific typeface design, and a font generator which creates from the generic base font and one or more descriptor files a character program for each character in the font.
More precisely, instead of a single, generic base font, there may be provided a generic base font for each category of typeface. A "category" of typeface is the term used herein to distinguish from each other alphabets of distinctly different topology: e.g. , Roman type, Cyrillic type, Arabic type, Kanji type and other forms of type.
In its descriptor file, a specific typeface design is represented as a compact enumeration of modifications to be made to its base font. These enumerations are contained in an encoded file which comprises program/data structures of defined arrangement. A descriptor file for a specific typeface design, according to the preferred embodiment disclosed below, requires only about 2K of data. The generic base font may be made resident in a printer, video terminal or the like. Thus, only the descriptor file(s) for the typefaces in use need be stored or transmitted with a document; the generic base font is essentially part of the environment. Only about 2K additional program/data is needed for each typeface descriptor file which is to be associated with a specific document.
Additionally, descriptor files may be easily modified, thus providing a simple way to alter character programs so as to alter the appearance of type. That is, by modifying an existing descriptor file, it iε possible to generate a typeface design which is varied, to almost any desired degree and in almost any desired way, from a previously encoded typeface design. Further, the parameters of two or more typeface designs readily can be blended by combining appropriate fields in their descriptor files, according to any desired mathematical algorithm (e.g., by performing a weighted average) . Thus a user can easily blend two or more typeface designs, or otherwise modify a typeface design.
A library of typeface designs comprises a library of their descriptor files plus the associated generic base font. Thuε a library of, say, one hundred fonts at a total of about 4.5MB volume can be replaced by a generic base font of about 200 kB, descriptor files of 200-300 kB and a font generator of about 60 kB. Not only is there a large savings in memory and transmission time, but also there is much enhanced capability given the user.
The invention will be more fully understood from the detailed description presented below, which should be read in conjunction with the accompanying drawing.
Brief Description of the Drawing
In the drawing,
Fig. 1 is a diagrammatic illustration of a synthetic font generation system according to the present invention; -o-
Fig. 2 is a diagrammatic illustration of a base font according to the invention;
Fig. 3 is a pictorial illustration of two different base design forms for the letter "a" - a Humanist form and a Grotesque form, as an example of a character available in two base design forms;
Fig. 4 is a diagrammatic illustration of an exemplary glyph in a base font according to the invention, which glyph representε a character stem;
Fig. 5 is a diagrammatic illustration of a serifed stem produced by modifying the base stem of Fig. 4.;
Fig. 6 is a diagrammatic illuεtration of a base font data structure, or program, correεponding to the εtem glyph of Fig. 4;
Fig. 7 is a diagrammatic illuεtration of a font descriptor file according to the invention, which is used with the base font program file of Fig. 6 to produce the εerifed εtem deεign of Fig. 5;
Fig. 8 is a diagrammatic illustration of a character program produced by the generator of the present invention, from the base font data εtructure of Fig. 6 and the deεcriptor file of Fig. 7;
Fig. 9 is a diagrammatic illustration of a font descriptor file used with the base font of Figs. 4 and 6 to generate the output contour of Fig. 10;
Fig. 10 is a pictorial illustration of the output contour generated by applying the font descriptor file of Fig. 9 to the baεe font of Figs. 4 and 6;
Fig. 11 is a diagrammatic illuεtration of a character program produced by the generator of the present invention, from the base font data εtructure of Fig. 6 and the descriptor file of Fig. 9;
Fig. 12 is a diagrammatic illuεtration of a deεcriptor file according to the present invention, produced by blending the descriptor file of Fig. 7 with the deεcriptor file of Ficr. 9; Fig. 13 iε a diagrammatic illuεtration of a character program produced by the generator of the present invention, from the base font data structure of Fig. 6 and the descriptor file of Fig. 12;
Fig. 14 is a pictorial illustration of the output contour generated by applying the font descriptor file of Fig. 12 to the base font of Figs. 4 and 6;
Fig. 15 is a pictorial illustration of two weights of a given typeface uεed to generate a third, intermediate weight of the typeface, in accordance with this invention;
Fig. 16 is a pictorial illustration of two typeface designs, one serifed and one εan-εerifed, but otherwiεe similar, used to generate a third, typeface which is partially εerifed, in accordance with this invention;
Fig. 17 is a pictorial illustration of two widthε of a given typeface uεed to generate a third, intermediate width of the typeface, in accordance with thiε invention;
Fig. 18 iε a pictorial illuεtration of one kind of feature εtretching according to the invention;
Fig. 19 iε a pictorial illuεtration of another kind of feature εtretching according to the invention;
Fig. 20 iε a pictorial illuεtration of the distribution of curve control points according to the invention, for features that are represented as a curve in one typeface design and a straight line in another;
Fig. 21 is a diagrammatic representation for a data εtructure for a file or a portion of a file constituting a Directory of Tables, comprising a directory specifying the addreεε cffεet to each of the tableε in a font according to the invention;
Fig. 22 iε a diagrammatic illuεtration of an exemplary data structure for a table containing information specific to the base font according to the invention;
Fig. 23 is a diagrammatic illustration for a data structure called Glyph Name Directory herein; Fig. 24 iε a diagrammatic illuεtration of a data εtructure for a table called Glyph Directory herein;
Fig. 25 iε a diagrammatic illustration of a data εtructure for storing the data for an individual glyph in the Glyph Data Table herein;
Fig. 26 is a diagrammatic illustration for a data structure called Font Names Directory according to the invention;
Fig. 27 is a diagrammatic illustration of a data structure called Font Directory;
Fig. 28 iε a diagrammatic illustration of a data structure for storing each font descriptor in the Font Descriptor Table according to the invention;
Fig. 29 iε a pseudo-code rendering illustrating an algorithm for generating an output font according to the invention, from a baεe font and a font deεcriptor;
Fig. 30 iε an exemplary data εtructure repreεentation for compactly deεcribing blendε of fontε according to the invention;
Fig. 31 iε a data εtructure repreεentation of encoding for each node of the font blend tree of Fig. 30;
Fig. 32 iε a diagrammatic illuεtration of an exemplary blend tree;
Fig. 33 iε a diagrammatic illustration of a data εtructure providing an encoded repreεentation of the exemplary blend tree of Fig. 32; and
Fig. 34 is a diagrammatic illustration in pseudo code form of an algorithm for converting a blend font descriptor into a font descriptor, which can then be used in the algorithm of Fig. 29 to produce an output font.
Detailed Description
A complete typeface deεign for a Roman character set includes typically about one hundred to several hundred characters - upper and lower caεe letters, numerals, punctuation marks and special svmbols. Various techniσ es are in common uεage for providing digital encodingε of typeface designs, to allow the reproduction of those designε on output devices such as video screens and laser printers. In order to avoid having to digitize and store a separate digitization for each point εize the uεer may require, there have been developed in recent yearε variouε εcalable font technologieε (such as Adobe Systems ' Postεcript outlines, Bitstream's Fontware and Speedo formatε, Agfa'ε Intellifont, Apple Computer 'ε True Type, and otherε). These technologies are shown, for example, in U.S. patents numbers 4,675,830, isεued June 23, 1987 to Hawkins; 4,785,391 isεued November 15, 1988 to Apley et al; and 5,099,435, issued March 24, 1992 to Collins et al, which are hereby incorporated by reference for their discloεureε.
According to theεe technologies, within a font each character in the typeface iε represented by a character program which, in turn, represents the character in outline form. The character program comprises a collection of data points, εome of which are on the character outline and otherε which are not on the character outline, and inεtructions as to how to interpret and treat the data points in order to construct therefrom an image of the embodied character. The techniques shown in the aforesaid patents, for example, then are used to produce bit map repreεentationε of the characterε at selected (i.e., scaled) sizes and resolutionε. The actual output diεplay iε provided from these bit map representationε.
Referring to Fig. 1, a system 10 according to the present invention comprises at least one generic base font 12, one or more font deεcriptor fileε 14 - 1 and a font generator, or "engine," 16. The generator 16 operateε in the manner described below, to generate a digital font corresponding to the one or more font deεcriptor fileε which are active at a given time; alternatively, εince a font is a collection of character programs, the generator may be εai to generate character programs for the font. Aε indicated diagrammatically in Fig. 2, each generic baεe font program 12 includeε a εet of character deεcriptions, in the form of character programs 22 -
22n, and a fixed εet of font wide deεign variableε 24,l -
24M (where there iε no inherent relationεhip between "n" and "N"). Either the character programε are arranged in some known sequence or each character program contains one or more fields identifying the corresponding character. For example, if the characters are arranged alphabetically, then numerically, and then followed by symbolε in a known order, the first character might be a lower "a," the second character an upper case "A,", etc. Alternatively, the character programs may be arranged in a random order, in which caεe the first (or εome other) field in the program file iε a character name. Thuε, if the first character program is for the numeral "8," the first field in the program file may be the word "eight" or a binary code for the character "8. "
A design variable can be specific to an individual character program or it can apply to a collection of character programε. Each deεign variable 24. iε aεεigned a unique identifier, which iε or tranεlateε to a numerical value. For inεtance, if the generic font 12 containε one hundred variable deεign featureε, they would be numoered from 1 to 100, or xl to xlOO or the like. Design feature 24 may be stroke weight, feature 24_ may be letter height, etc.
In the base font, a special character program (the "base character program") is provided for each character in the font. (Note that for purpoεeε of this description, the term "character" is intended to encompass both entire letter formε, numeralε and εymbols, and component parts thereof, such aε εerifε, stems, and the like. These component parts are εometimeε called "glyphs." Where it is neceεεary to distinguish the two types of characters, those formed from multiple glyphs will be called "full characterε." Where multiple glyphε are involved, instructions must also be included for aεεembling full characterε from the available glyphs. Thus, it will be understood that a "glyph" may comprise a unitary character on a piece of a character. In a base character program, a character iε encoded into data and inεtructionε representing the contourε of the character pluε a sufficient number of control points to permit replication of a wide range of design characteristicε, including strokes, serifs and other ornamentation.
More than one set of contours may be allocated (or, alternatively, more than one character program may be provided) , for a character which can be drawn with contours and base designs which differ significantly in topology. For example, as shown in Fig. 3, the lower caεe letter "a" may be repreεented [in] two different baεe deεign formε: in the Humaniεt form 26 and the Grotesque form 28. The character program or programε for the letter "a" must thus provide for both base forms. Consequently, 22 may correεpond to the Humaniεt form of the letter "a" and 22_ may correspond to the Grotesque form. A deεcriptor file for a given font will εelect the deεired form for each character available in multiple formε, by εelecting appropriate character programε.
Figε. 4-8 provide a more εpecific exemplary illustration of this technique. In Fig. 4 is shown a portion of a generic contour 32 for the stem of an unspecified letter (i.e., a stem "glyph"). Since a character stem may or may not have a serif, control points are provided on the baεe character contour (i.e., in the baεe font character program) to allow for "expansion" to serif form or "contraction" to san εerif form. To thiε end, control pointε CP1, CP2 and CP3 are provided in association -with the baεe coordinates of point 34; and control points CP4, CP5 and CP6 are provided in association with the baεe coordinateε of point 36. The uεe of theεe control pointε will be explained more fully below; note, however, that the control pointε CP1-CP6 may be moved outwardly from their location in the base font to form a serif. The control points of each character contour include numeric data for specifying an initial position in the coordinate εyste uεed for the descriptor files. In the example, thiε is, and usually will be, a Cartesian coordinate plane. The numeric data comprising the control points further includes a list of trajectories. Each trajectory encodes three data: a displacement direction, a displacement magnitude and the design feature number with which the trajectorieε aεεociate. Each control point'ε list of trajectories need only include trajectories for the design features that affect it. Trajectorieε are specified, as well, for controlling featureε relating to all of the characterε in the font and alεo for controlling featureε specific to an individual character. For example, trajectories are specified for controlling the general width of all serifs in the font and for modifying the widths of the serifs in a specific character.
Control points are preferably located in the baεe font εo that their trajectorieε are in "outward" directionε when another font iε generated from the baεe font. Thiε produces fewer rounding errors than the alternative: locating the control points on the expanded form of a character and their moving them "inwardly" - e.g., to produce a non-serifed font from a baεe εerifed font.
To illustrate the operation of the control points, refer now to Fig. 5, which εhows the base stem 32 of Fig. 4 modified to become a serifed stem 32' . Control point CP1 εpecified a trajectory to the left a diεtance "q" to point NPl. (Or to the left a distance q and down a distance "r", depending how the character height is to be adjusted to compensate for the "addition" of the εerif.) Control point CP2 εpecified a trajectory to the location of point NP2. Control point CP3 either εpecified no motion or a vertical trajectory a diεtance r. Control pointε CP4-CP6 in this example provided mirror image specificationε mapping them to the locationε of pointε NP4-NP6, respectively. The tranεformation from the generic base εtem 32 of Fig. 4 to the εerifed εtem 32' of Fig. 5 reεultε from uεe of a descriptor file to operate on the base font, as stated above. Turning to Fig. 6 there is shown in diagrammatic form a corresponding base font data structure (or program) 40, or portion of a base font data structure for the stem 32 of Fig. 4. Similarly, Fig. 7 shows in diagrammatic form a font deεcriptor file 50 which is used by the generator to produce from the generic base font the final serifed εtem deεign of Fig. 5. Applying the generating tranεformationε x coordinate = a + lc + 0.5e and y coordinate = b + Id + 0.5f, as specified by the descriptor file 50 for stem 32, the generator produces the character (glyph) program 60 for the new contour, listed in Fig. 8.
The example of Figs. 4-8, of courεe, εhowε how the present invention works relative to a single feature of a character - in this case, a εtem. By εimple extenεion to each portion of a character contour in turn, and to each contour of a multiple-contour character, the εame method iε employed to generate an entire character program for outputting the complete character image. For simplicity, the control points in the base font may be processed in the same sequence aε that in which they are arranged in the baεe font, though thiε method doeε not require such sequential procesεing.
A deεcriptor file for a specific font design preferably includeε a εetting value for each of the baεe font' ε deεign variableε (which may involve one or more control points), spacing information for each character and a list of character forms to select for those characterε for which multiple baεe formε are available - e.g., a flag which εelectε either the Humaniεt "a" or the grotesque "a". The specification, or descriptor file, is very compact compared to the file which encodes the base font. The generator 16 produceε a contour repreεentation for a εpecific typeface by combining the appropriate deεcriptor file with each of the generic base font's character programε. Thiε combination proceεε includeε not only the movement of contour control pointε and attendant curve-fitting, but also may involve resolving designs features, reducing the contour representation to the minimum set of pointε needed for each character, and/or aεsigning spacing to each character.
The values, in each entry of the font deεcriptor file, determine how the generator produces, from the individual contour control points in the generic font character programs, final contour repreεentationε which are executable to produce the typeface of the εelected design. The process is illustrated in Fig. 29, which is diεcusεed below. It is useful to note here that for each contour of a glyph, as outlined in Fig.29, three procesεeε are executed. Firεt, for at leaεt εelected areaε of the control pointε of the base character, a computation is performed to yield a displacement by which the control point is mapped to a new location to produce the contour of the εelected deεign. This displacement iε the sum of the trajectory magnitudes, modified by the setting (i.e., original baεe font control point) values. That is, the generator provides output coordinates for a point in the generated font which corresponds to a control point of the base font tranεformed by the computed diεplacement. Thiε iε proceεs 29-1 in Fig. 29. It should be noted that control points may, but need not, be located on a character contour. In one common form of character outline encoding, a cubic Bezier curve representation, some control points (specifically, for curves) explicitly are not on the contour, or curve itεelf.
It iε not neceεεary that in proceεs 29-1 a displacement be computed for each and every control point. Selected control points can be chosen (in proceεs 29-1 this is indicated by the line "if flag for point specifies that design offsets are used) to be displaced. Then, in procesε 29-2 for each control point whose displacement was not computed in process 29-1, a displacement value is determined by interpolating between mapped locationε determined for neighboring contol pointε in proceεε 29-1.
After all the control pointε for the output font have been thuε computed, a "filter" routine may be executed to remove overlapping and non-eεεential pointε. This is process 29-3. The result is a character program representing, in part, the minimum set of contour points necessary for encoding the selected design. The details of such a filter routine do not form part of this invention and will not be discussed further, to avoid obscuring the description of the invention. It will be appreciated that software developers, knowledgeable about font software, will readily be able to devise suitable filter implementations.
The position of each of the thus-generated characters in the output font may then be adjusted horizontally and vertically, and assigned an advance width (i.e., distance to the origin of the next character), uεing the font-wide valueε εpecified in the font deεcriptor file. Horizontal and vertical adjustment is accomplished by simple coordinate translation. Width adjustment may require scaling.
Aε stated above, the invention further provides the capability of blending two (or more) font descriptor files to create useful intermediate typeface designs. Any two font descriptor files can be combined in a variety of wayε to create a third deεcriptor file. The reεulting deεcriptor file can be further combined to yield yet additional descriptor files. Many combinations of the design features and spacing valueε of two deεcriptor fileε reεult in intermediate font deεignε that εhare features of each of the two base typefaces. For instance, with reference to Fig. 15 a blend between a light weight 110 and a heavy weight 112 of a typeface will yield a weight 114 εomewhere between the heavy and the light. A blend (See Fig. 16) between a εe if deεign 116 and a εan εerif deεign 118 may reεult in a εemi-serif design 120, depending on the weightings aεεigned the original designs or their features. A blend (See Fig. 17) between a narrow width 122 and a wide width 124 may result in an intermediate width typeface design 126, depending on the width weightingε aεεigned the deεcriptor fileε corresponding to typefaces 122 and 124.
Consider the example which will now be explained with reference to Figs. 9-14. Fig. 6 is again the baεe character deεign program. However, inεtead of uεing the deεcriptor file 50 of Fig. 7, the generator now uεed the descriptor file 70 of Fig. 9, to produce in this caεe the output contour 72 of Fig. 10, repreεented aε well in the table 80 of Fig. 11. The generator functionε εpecified by deεcriptor file 70, for producing the contour data of table 80, is
x coordinate = a + 0c + 0.5e, y coordinate = b + Od + 0.5f.
This provides a stem 72 of a second design. The goal, however, is to produce a character design (and program) which iε a blend half-way between the character generated from deεcriptor 50 and the character generated from deεcriptor 70. To achieve thiε reεult, the generator executeε the function
blend deεcriptor = deεcriptor 50 + 0.5(descriptor 70
- descriptor 50)
This may be decomposed in the relevant x and y coordinate tranεformationε aε followε:
( x coordinate = a + 0.5c + 0.5e y coordinate = b + 0.5d + 0.5f. The resulting descriptor 90 iε εhown in Fig. 12. From deεcriptor 90, generator 16 produceε the character program fragment 100 (Fig. 13), the corresponding character design 114 being εhown in Fig. 14.
Thiε technique iε quite flexible. Clearly, fewer than all of the variables in a pair of descriptor files can be blended, for example. Thuε combinations of subεetε of the deεign features can be blended to vary specific characteristicε, εuch aε εtroke weight or εerif widthε . The blending function can be the same for all of the variables (e.g. , a fifty-fifty mix or εixty-five-thirty-five, or εome other mix) or different operationε can be performed on different variableε (e.g., a deεcriptor file can be created which repreεentε 100% the serif from a first descriptor file and a character weight which is a sixty-forty blend of the weights from two deεcriptor files) .
There are many posεible repreεentations for the contour data in the generic, base font program. The contour data uεt contain a εufficient number of control points to represent the most complex poεεible rendering of the character deεign. Thoεe εkilled in digital typography employ a variety of computer-aided deεign tools (i.e., computers and computer programs) to asεure they have εelected εufficient contour data to repreεent a character εhape to the deεired fidelity) .
When an optional feature of a character may be omitted entirely for εome final character programε and underlying deεignε, the εet of control pointε for that feature preferably are diεtributed initially, in the baεe font, at a εingle Carteεian coordinate. For instance, serifε disappear in san εerif deεignε. The san serif deεign iε preferably used for a base font. In the base font, therefore, all the control points asεociated with the εerif for a given εtem preferably are cluεtered at the corner of the εtem. (Multiple control points will, thuε, have the same coordinates in the base font, but each point has its own unique identity and can be mapped independently to the output font.) The design feature vectors for the serif points are specified such that the pointε separately are moved, by the generator, from the corner of the εtem to their deεired reεting positions in the serif.
Some character deεigns are created by stretching a base character design. The stretching process can be achieved by elongating the curves and lines of the base deεign. See, for example, Fig. 18, wherein the lower caεe letter "h", 136, iε to be modified by εtretching the arch from a height t, to a height t2 aε εhown at 138. Thuε, the increase in height t can be achieved by changing the length of segments 139a, 139b in the left and right stemε. In other deεignε, εtretching iε achieved by introducing additional curve and line εegmentε to the original deεign. To repreεent theεe additional εegmentε that appear in a stretch deεign and disappear in the compact design, it is recommended that the pointε for the additional εegmentε be placed at a εingle point between the εegments of the base design. See, for example, Fig. 19, wherein a round letter "o", 140, in a base font is to be transformed to a stretched form 150 for an output font. The outer contour 140 may be formed, for example, of four εegmentε 141-144. The elongation of the letter iε obtained by inεerting εegmentε 151 and 152 at pointε 145 (between εegmentε 143, 144) and 146 (between εegments 141, 142). Original points 145 and 146 are expanded into new point pairs 145a, 145b and 146a, 146b, respectively. The inner contour is treated similarly.
Many character deεignε contain featureε that are repreεented as a curve in one design and a straight line in another. The generic repreεentation for theεe features, asεuming uεe of a Bezier repreεentation, iε a curve εegment in which the curve control pointε are diεtributed evenly between and co-linear with the endε of the curve. For example, in Fig. 20, the letter "I" may be repreεented with straiσht line vertical εides 162a, 162b or with curved sides 164a, 164b. Points 165 and 166 are exemplary control points, as they are evenly diεtributed between, and co-linear with, curve end points 167 and 168.
Many character designs contain features that are represented as a curve in one design and a straight line in another. The generic representation for these features, asεuming uεe of a Bezier repreεentation, iε a curve εegment in which the curve control pointε are diεtributed evenly between and co-linear with the endε of the curve. For example, in Fig. 20, the letter "I" may be represented with straight line vertical sides 162a, 162b or with curved sides 164a, 164b. Points 165 and 166 are exemplary control pointε, aε they are evenly diεtributed between, and co-linear with, curve end pointε 167 and 168.
The generator 16 may be implemented aε a digital computer executing an appropriate program to carry out the functionε εpecified herein. The neceεεary data structures which would reside in the memory of the computer (main memory or masε εtorage), and the operationε for one exemplary embodiment of thiε type, are shown in Figs. 19.
A baεe font may be implemented as a set of tables, each containing data repreεenting pieceε of the font. That iε, characterε may be aεεembled from pieceε which εee repeated uεe among various characterε in the font, εuch aε εtemε, arches, serifε, and εo forth. Theεe pieces are referred to aε "glyphε." (Of courεe, aε stated above, a character may be a single glyph.) The base font contains both the data for the individual glyphε and for the output font descriptions. A typical set of tableε might be the following:
Directory of Tableε
Font Info
Glyph Name Directory
Glyph Nameε
Glyph Directory
Glyph Data
Font Nameε Directory Font Names
Font Directory
Font Descriptors The table named Directory of Tables containε a directory which specifies the addreεε offεet to each of the tableε in the font, from an initial addreεε. The Directory of Tableε table may have the εtructure εhown in Fig. 21, for example. Aε indicated there, a firεt table entry, 180, containε the value of the variable "numTables", which representε the number of tableε in the font. A εecond entry 182 iε itself one or more tables, each composed of numTables pairε of four-character table nameε 182a and the offεet 182b from the beginning of the font to that particular table.
The table Font Info, depicted in Fig. 22, for example, containε information εpecific to thiε baεe font. This information may include, but need not be limited to, the following, for example: the value of a variable fontID, 190, which is a unique identification number for the font; the value of a variable "version", 192, which is the version number for the font; a string 194 containing the name of the font; and a string 196 containing a copyright notice for the font.
Each glyph in the base font has a name. The table Glyph Name Directory, illustrated in Fig. 23 iε a croεε index εpecifying the offεet to each glyph name in the Glyph Nameε table. The Glyph Name Directory beginε with a datum giving the value of the variable "numGlyphε", 202, the number of glyphε in the Glyph Names table. Next, there follows an array offset [1..numGlyphε] , 204, containing the offεetε, in glyph order, for the start of each glyph name string.
In turn, the Glyph Nameε table containε, in sequence, a string for the name of each glyph in the font.
The table Glyph Directory of Fig. 24 contains a listing of the offset to the data for each glyph in the baεe font. The firεt entry, 212, containε the value of the variable 'numGlyphε," which represents the number of glyphs named in the Glyph Data table. Next there appears an array offset[l..numGlyphs] , 214, containing the offsets, in glyph order, for the start of each glyph's data.
The table Glyph Data contains the contour data for all the glyphs in the base font. The data for an individual glyph iε εtored aε εhown in Fig. 25. An initial table entry 222 preferably iε a character code for the glyph. Thiε code may, for example, be in the εo-called Unicode εtandard or in εome other repreεentational code. Next there follows an array 224, called designMap, which contains a mapping of design featureε for this glyph to font-wide design features. Thiε is followed by a datum 226, originPoint, which specifieε the character origin offεet, and a datum 228, widthPoint, which specifies the character width. Note that since character width iε variable by εetting a parameter on a fontwide baεiε, aε well aε on a character baεiε, merely by εpecifying deεired character width one can εubεtitute for a font a character of a firεt known width another font or character of the εame width. Next is an entry 232 which gives the value of the variable numContourε, the number of contourε in thiε glyph. Thiε is followed by those contours, 234, with each contour represented aε indicated at 236 in Fig. 25. The originPoint, widthPoint and pointε in segments each are represented by a horizontal coordinate, x, and a vertical coordinate, y; further, if the point has a set of design offsetε, they are included in the εpecification aε an array horizontalOffsets and an array verticalOffsets . These arrays specify, respectively, the horizontal and vertical diεplacementε associated with each design feature present in the glyph. To conserve memory and streamline proceεsing, design offsets may be stored only for the deεign parameterε associated with the glyph. The deεignMap contentε εpecify how the glyph' ε deεign offsetε map onto the font-wide deεign parameterε. For example, if the glyph uεeε only deεign parameterε 1, 3 and 5 from a liεt of 100 poεεible design parameters in the base font, the designMap would contain an array εuch aε 1,3,5,0 (the final 0 εignalling the end of the array) . The horizontalOffεetε array and the verticalOffεetε array for pointε with deεign offεets would thus contain only three entries each in this example.
The Font Names Directory table iε one containing a liεt of offεetε to each of the output font nameε in the Font Names table. It has the structure εhown in Fig. 26. That iε, the firεt entry, 242, numFontNameε, iε a variable denoting the number of font names in the FontNames table. Next, there follows an array 246 of offsets to thoεe nameε.
The table Font Nameε iε a table of strings for all the font names defined in the Font Directory.
The Font Directory table is a list of offsetε to the output font descriptors in the Font Discription Table. The Font Directory table haε the εtructure εhow in Fig. 27. It firεt containε the value of the variable numFontε, which iε the number of font deεcriptorε in the Font Descriptorε table, followed by an array, 252, of all sets to the start of each deεcriptor.
Finally, Font Deεcriptorε iε the table containing the data for all the output fonts. Each font descriptor iε εtored uεing the εtructure εhown in Fig. 28, which will be self-explanatory. The vector shown in Fig. 28 , contains settingε for each deεign parameter encoded in the baεe font. The firεt deεign parameter 262, width class, controls condensing and extending the font. Other design parameterε are freely aεεigned.
Given the font deεcriptor, an output font iε generated, uεing the algorithm εhown in Fig. 29. Aε thiε algorithm iε illuεtrated in a pεeudo-code form, it is fully the equivalent the equivalent of a flow chart and is self-explanatory.
As mentioned above, fontε can be deεcribed as being combinations of design fontε deεcriptorε from the baεe font. Blendε of fontε may be compactly deεcribed, uεing the data εtructure εhown in Fig. 30. The firεt entry, 302, containε a identification for the baεe font with which this descriptor workε. Next, there follows a string, 304, naming the font family; and a string 306, describing the weight of the font. Finally, tnere is a binary tree, 308, describing the blend. In turn, each node of the blend tree may be encoded aε εhown in Fig. 31. There, the variable "amount", 310, specifies the numeric amount (i.e., percentage) the related font provides to the blend. Then there is εpecified the identification of the baεe font. Next is a flag which specifieε that the base font iε neεted (i.e, derived from εtill another font deεcriptor). Also included is the identification of the blend font or a flag εpecifying that the blend font itεelf iε nested, 312. A blend font that was derived by combining a base font 300 with 30% of a blend font compoεed of a baεe font, which iε made up of font 200 blended 75% with blend font 400, which, in turn, iε blended 50% with blend font 500, would yield a tree εtructure εuch aε εhown in Fig. 32, and repreεented, more particularly, in Fig. 33.
The blend font descriptor illustrated in Figs. 30-33 is turned into an output font by first converting the blend font deεcriptor into a font deεcriptor. The reεulting font deεcriptor can then serve as input to the generator algorithm of Fig. 29 to produce an output font. An exemplary algorithm for converting a blend font deεcriptor into a font deεcriptor iε provided in pεeudo-code form in Fig. 34, which iε εeIf-explanatory.
It will be observed that blend font descriptors, in general, are much smaller than basic font descriptors.
While in the exampleε εet forth herein, the glyphε and characterε εhown are εome of those involved for Roman fonts, with other glyphs the invention can be used to generate Kanji or other font categories, as well. Other readily conceivable variationε on the diεcloεed embodiment include parametric naming of fonts. This is, a descriptor file can be built from a vector (i.e., string of data values) which specifies a typeface or font by name or number, uεing a table look-up approach. Thiε may be combined with a taxonomic approach to font naming, εo that a font name iε formed by concentrating a number of data filedε, each of which contains a specific parameter value. Typical parameters might include font width, height, alternative character topology choices, εeriε/εan serif, italic slant, and so forth. The string of numerical values for the parameters constituteε the typeface name. From thiε name, a table provideε a pointer to a corresponding descriptor file.
Having thus described the basic concept of the invention, it will be readily apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented by way of example only, and is not limiting. Various alterations, improvements, and modifications will occur and are intended to those skilled in the art, though not expressly stated herein. Theεe modificationε, alterationε, and improvementε are intended to be εuggeεted hereby, and are within the εpirit and εcope of the invention. Accordingly, the invention iε limited only by the following claimε and equivalentε thereto:
What iε claimed iε:

Claims

CLAI S
1. A computer-implemented method for generating an output digital font, comprising the steps of: retrieving from memory a file containing instructions and data for a generic base font; retrieving from memory a font descriptor file containing specificationε for operating upon the generic baεe font to produce said output font; and generating said output font by performing operationε upon the generic base font in accordance with the εpecificationε contained in the font deεcriptor file, to produce a character program for each character in the generic baεe font wherein the data representing the output font is at least a portion of the data for the generic font aε transformed in accordance with said εpecificationε .
2. A method according to claim 1 wherein the inεtructionε and data in the file for the generic baεe font include a εet of baεe character programε executable by the computer and compriεing for each character in a character εet included in εaid font at leaεt one program for uεe by a computer to produce an image of εaid character, each εaid program including data and inεtructionε representing the contours of a character, a plurality of control points, and for each control point a set of trajectorieε aεεociated therewith, and wherein the specifications in the font descriptor file include a data structure including in determinable locations values for a set of design variables, each specifying a value for a design feature of the typeface which may be generated uεing the font, and εaid method further compriεeε the steps of: operating the computer to retrieve from said base font file the data and instructionε repreεenting the contourε of a εelected character, including the control pointε therein and the εet of trajectories associated with each of said control points; operating the computer to retrieve from said font descriptor file the values for a set of design variableε aεεociated therewith, and wherein the εtep of generating εaid output font includeε the εtep of forming contour points for inclusion in the output font by transforming coordinates of each control point in the base font file in accordance with a trajectory therefor responsive to a design variable value selected from the font descriptor file.
3. The method of claim 2 wherein the step of generating εaid output font further includeε a εtep of removing redundant formed contour points so as to avoid inclusion of redundant formed contour points in a generated character program.
4. A computer-implemented method for generating an output digital font usable to generate text in a typeface whose design is a blend of deεign featureε of firεt and second typefaces, each of said typeface design features being repreεented in a correεponding deεcriptor file, compriεing the εtepε of: retrieving from memory a file containing inεtructionε and data for generating text in a generic baεe font; retrieving from memory firεt and εecond font descriptor files, each containing εpecificationε for operating upon the generic baεe font to produce an output font for, respectively, a first typeface and a second typeface; combining a specification contained in the first font descriptor with a specification contained in the second font descriptor file to create a third font descriptor file containing specifications for a typeface produced by εaid combination; and generating εaid output font by performing operationε upon the generic base font in accordance with the specificationε contained in the third font deεcriptor file, to produce a character program for each character in the base font wherein the data representing the output font is the generic font data as transformed in accordance with said specifications.
5. The method of claim 4 wherein each font descriptor file contains specificationε for a plurality of parameterε for operating upon the generic baεe font and the εtep of combining further compriεeε, for at leaεt one corresponding parameter specification in each of the first and second font descriptor fileε, the steps of: for at least one character of the generic base font, forming an algebraic combination of the values for said parameter εpecification in εaid firεt and second font descriptor files; and placing in the third font descriptor file the value of the algebraic combination, as a value for said parameter specification for εaid character therein, whereby said character in the typeface design generated by the third font descriptor file contains at least one feature corresponding to said combination of the valueε of εaid feature in the typefaceε generated by the firεt and (εecond font deεcriptor fileε.
6. The method of claim 4 wherein each font deεcriptor file ccntainε specifications for a plurality of parameters for operating upon the generic base font and the step of combining further comprises the stepε of: for at leaεt one correεponding parameter εpecification in each of the firεt and εecond font deεcriptor files, forming an algebraic combination of the values for εaid εpecification in εaid firεt and εecond font deεcriptor fileε; and placing in the third font descriptor file the value of the algebraic combination, as a values for said parameter specification therein, whereby the typeface design generated by the third font descriptor file contains at least one feature correεponding to a combination of the valueε of said feature in the typefaces generated by the first and second font descriptor files.
7. The method of claim 6 wherein the algebraic combination iε a weighted average of the εpecification valueε in the firεt and εecond deεcriptor fileε.
8. The method of claim 7 further including the εtepε of accepting aε input valueε for relative weightingε to be uεed in forming εaid weighted average.
9. The method of any of claimε 6-8 wherein the typeface deεign generated by the third font deεcriptor file contains a plurality of features correεponding to a conεistent combination of the values of said feature in the typefaceε generated by the firεt and εecond font deεcriptor fileε.
10. A generic baεe type font, comprising: a computer-readable medium adapted to store a computer-readable file of predetermined size and configuration; εtored on said medium, a computer-readable file containing data and logic instructionε for controlling the operation of the computer which readε the file, εaid file compriεing a εet of base character programs executable by the computer and comprising for each character in a character set included in said font at least one program for use by a computer to produce an image of said character, each said program including data and instructions representing the contours of a character and a plurality of control points, and a data structure including in determinable locations in said file values for a set of deεign variables, each specifying a value for a design feature of the typeface which may be generated using the font.
11. The generic baεe type font of claim 10 wherein each baεe character program further includeε a name for εaid program.
12. A generic base type font according to claim 10, wherein for at least one character, the stored file includes at least two alternative programs for use by the computer to produce an image of said character in at least two different topologies.
13. A generic base type font according to claim 10 wherein the data representing control points includes', for at leaεt εome control points, data representing an initial position for a control point and a list of trajectory information for use by the computer to modify the location of the control point and alter the contour of the character.
14. A generic base type font according to claim 13 wherein each trajectory information list includes a displacement direction, a diεplacement magnitude and an indicia of a deεign feature aεεociated with the control point.
15. A generic baεe type font according to claim 14 wherein the file containε, for at leaεt one glyph, an initial position and a list of trajectory information for use by the computer to modify the location of an associated control point and to alter the contour of the glyph for use in multiple characterε.
16. A computer-readable type font deεcriptor module for use in connection with a digital computer executing a program in accordance with any of claims 1-9, comprising: a computer-readable medium adapted to store a computer-readable file of predetermined configuration; stored cn said medium, a computer-readable file containing data and logic instructions for controlling the operation of the computer which reads the file, m conjunction with the execution of said program, said file comprising in one or mere identifiable locations, data and inεtructionε comprising specifications for use by said program to operate upcn or with said generic base font to produce as output images corresponding to a selected font.
17. A method of providing a compact representation of a type font created by clending features of a first digitally-encoded type font with features of a second digitally-encoded type font, comprising the steps of: recording in a computer-readable file a numeric amount representing the relative weightings to be given tne first and second fonts when blended; recording in said file an m-iicia representing the first font; and recording in said file an indicia representing the second font .
18. A computer-readable module for use in connection with a digital computer executing a program m accordance witn any of claims 1-9 or 16-17, comprising a computer-readable mec u~ having stored therein a first datum representing the relative weightings to be given first and second fonts when blended, a datum comprising an indicia representing the first font, and a datum comprising an indicia representing the second ont.
PCT/US1994/004242 1993-04-16 1994-04-18 Synthetic font generator WO1994024623A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU66368/94A AU6636894A (en) 1993-04-16 1994-04-18 Synthetic font generator

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/048,766 1993-04-16
US08/048,766 US5664086A (en) 1993-04-16 1993-04-16 Method and apparatus for generating digital type font, and resulting fonts using generic font and descriptor file

Publications (1)

Publication Number Publication Date
WO1994024623A1 true WO1994024623A1 (en) 1994-10-27

Family

ID=21956345

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1994/004242 WO1994024623A1 (en) 1993-04-16 1994-04-18 Synthetic font generator

Country Status (3)

Country Link
US (3) US5664086A (en)
AU (1) AU6636894A (en)
WO (1) WO1994024623A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1048456A2 (en) * 1999-02-17 2000-11-02 Adobe Systems Incorporated Generating a glyph
US6678410B1 (en) 1999-02-17 2004-01-13 Adobe Systems Incorporated Generating a glyph

Families Citing this family (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5664086A (en) * 1993-04-16 1997-09-02 Adobe Systems Incorporated Method and apparatus for generating digital type font, and resulting fonts using generic font and descriptor file
CA2125608A1 (en) * 1993-06-30 1994-12-31 George M. Moore Method and system for providing substitute computer fonts
US6911987B1 (en) * 1995-07-05 2005-06-28 Microsoft Corporation Method and system for transmitting data for a shared application
JP3754153B2 (en) * 1996-11-11 2006-03-08 ヒューレット・パッカード・カンパニー Document display system in network
US5870084A (en) * 1996-11-12 1999-02-09 Thomson Consumer Electronics, Inc. System and method for efficiently storing and quickly retrieving glyphs for large character set languages in a set top box
US6025851A (en) * 1997-01-17 2000-02-15 Ductus Incorporated Envolvent approximation using accurate slope information
US6498608B1 (en) * 1998-12-15 2002-12-24 Microsoft Corporation Method and apparatus for variable weight outline emboldening of scalable outline fonts
JP3469492B2 (en) * 1999-02-19 2003-11-25 フーリエ有限会社 Font memory and font data reading method
US6512531B1 (en) 1999-04-09 2003-01-28 Adobe Systems Incorporated Font navigation tool
US7064757B1 (en) 1999-05-07 2006-06-20 Apple Computer, Inc. Automatic synthesis of font tables for character layout
US6563502B1 (en) * 1999-08-19 2003-05-13 Adobe Systems Incorporated Device dependent rendering
US6771267B1 (en) * 2000-03-22 2004-08-03 Adobe Systems Incorporated Merging digital fonts
GB0022084D0 (en) * 2000-09-08 2000-10-25 Univ Aberdeen Treatment of multiply antibiotic-resistant organisms
WO2002025587A2 (en) * 2000-09-19 2002-03-28 Technion Research And Development Foundation Ltd. Method and apparatus for shape deformation and placement
US7598955B1 (en) 2000-12-15 2009-10-06 Adobe Systems Incorporated Hinted stem placement on high-resolution pixel grid
FR2821447A1 (en) * 2001-02-27 2002-08-30 Koninkl Philips Electronics Nv METHOD OF CONTROLLING THE DISPLAY OF A CHARACTER BASED ON DYNAMIC CODE GENERATION
US7418664B2 (en) * 2002-04-03 2008-08-26 Microsoft Corporation Application sharing single document sharing
US7028266B2 (en) 2002-04-05 2006-04-11 Microsoft Corporation Processing occluded windows during application sharing
US8756513B1 (en) 2002-04-23 2014-06-17 Microsoft Corporation Document viewing mechanism for document sharing environment
US7293243B1 (en) * 2002-05-22 2007-11-06 Microsoft Corporation Application sharing viewer presentation
US7356563B1 (en) 2002-06-06 2008-04-08 Microsoft Corporation Methods of annotating a collaborative application display
US7310769B1 (en) 2003-03-12 2007-12-18 Adobe Systems Incorporated Text encoding using dummy font
US7042458B2 (en) * 2003-03-25 2006-05-09 Mitsubishi Electric Research Laboratories, Inc. Methods for generating an adaptively sampled distance field of an object with specialized cells
US7292247B2 (en) * 2004-01-26 2007-11-06 Microsoft Corporation Dynamically determining directions of freedom for control points used to represent graphical objects
US7187382B2 (en) * 2004-01-26 2007-03-06 Microsoft Corporation Iteratively solving constraints in a font-hinting language
US7236174B2 (en) * 2004-01-26 2007-06-26 Microsoft Corporation Adaptively filtering outlines of typographic characters to simplify representative control data
US7136067B2 (en) * 2004-01-26 2006-11-14 Microsoft Corporation Using externally parameterizeable constraints in a font-hinting language to synthesize font variants
US7639258B1 (en) 2004-03-31 2009-12-29 Adobe Systems Incorporated Winding order test for digital fonts
US7580039B2 (en) * 2004-03-31 2009-08-25 Adobe Systems Incorporated Glyph outline adjustment while rendering
US7719536B2 (en) * 2004-03-31 2010-05-18 Adobe Systems Incorporated Glyph adjustment in high resolution raster while rendering
US7602390B2 (en) * 2004-03-31 2009-10-13 Adobe Systems Incorporated Edge detection based stroke adjustment
US7333110B2 (en) * 2004-03-31 2008-02-19 Adobe Systems Incorporated Adjusted stroke rendering
US8253742B2 (en) 2004-05-28 2012-08-28 Microsoft Corporation Rendering stroke pairs for graphical objects
US7256786B2 (en) * 2004-05-28 2007-08-14 Microsoft Corporation Appropriately rendering a graphical object when a corresponding outline has exact or inexact control points
US7292249B2 (en) * 2004-05-28 2007-11-06 Microsoft Corporation Appropriately rendering a graphical object when a corresponding outline has excessive control points
US7005957B2 (en) * 2004-05-29 2006-02-28 Tsung-Mou Yu Mechanism for trip-free of the bimetallic plate of a safety switch device
US7710422B2 (en) * 2004-07-26 2010-05-04 Microsoft Corporation Font representations
US7478325B2 (en) * 2005-04-22 2009-01-13 Microsoft Corporation Methods for providing an accurate visual rendition of a text element formatted with an unavailable font
US7447361B2 (en) * 2005-05-26 2008-11-04 Marvell International, Ltd. System and method for generating a custom font
US20070139412A1 (en) * 2005-12-19 2007-06-21 Microsoft Corporation Automatic font control value determination
US7583267B2 (en) * 2005-12-19 2009-09-01 Microsoft Corporation Stroke contrast in font hinting
US7505040B2 (en) * 2005-12-19 2009-03-17 Microsoft Corporation Composite characters font hinting
US7778492B2 (en) * 2006-04-04 2010-08-17 Oldford Group Limited System and method for scaling digital images
US8520003B2 (en) 2006-05-22 2013-08-27 Raphael L Levien Method and apparatus for interactive curve generation
US8144166B2 (en) * 2006-08-01 2012-03-27 Microsoft Corporation Dynamic pixel snapping
US8497874B2 (en) * 2006-08-01 2013-07-30 Microsoft Corporation Pixel snapping for anti-aliased rendering
US8508552B2 (en) * 2006-09-08 2013-08-13 Microsoft Corporation Pixel snapping with relative guidelines
US20080068383A1 (en) * 2006-09-20 2008-03-20 Adobe Systems Incorporated Rendering and encoding glyphs
US20080304113A1 (en) * 2007-06-06 2008-12-11 Xerox Corporation Space font: using glyphless font for searchable text documents
US9594748B2 (en) * 2007-10-25 2017-03-14 Disney Enterprises, Inc. System and method for localization of assets using dictionary file build
US7982737B2 (en) * 2007-10-31 2011-07-19 Adobe System Incorporated System and method for independent font substitution of string characters
US8239763B1 (en) 2009-01-07 2012-08-07 Brooks Ryan Fiesinger Method and apparatus for using active word fonts
CN102521261A (en) * 2011-11-18 2012-06-27 四川长虹电器股份有限公司 Method for manufacturing dot matrix word stock according to vector word stock
US20130155098A1 (en) * 2011-12-19 2013-06-20 Monotype Imaging Inc. Adjusting Fonts for Visual Consistency
CN103455475B (en) * 2012-06-01 2016-12-14 腾讯科技（深圳）有限公司 Composition method, equipment and system
US9536279B2 (en) 2013-03-11 2017-01-03 Google Technology Holdings LLC Method and apparatus for creating a graphics data representation and scaling a graphic represented thereby
US9547628B2 (en) * 2013-10-31 2017-01-17 Adobe Systems Incorporated Method and apparatus for improving text legibility by automatically adjusting zoom level based on preferred font characteristics including height, weight, and condensation
AU2014277854A1 (en) 2014-12-22 2016-07-07 Canon Kabushiki Kaisha Emboldening of outline fonts
US10503810B2 (en) * 2015-06-18 2019-12-10 International Business Machines Corporation Font personalization
US9875429B2 (en) 2015-10-06 2018-01-23 Adobe Systems Incorporated Font attributes for font recognition and similarity
US10074042B2 (en) 2015-10-06 2018-09-11 Adobe Systems Incorporated Font recognition using text localization
US10007868B2 (en) 2016-09-19 2018-06-26 Adobe Systems Incorporated Font replacement based on visual similarity
US11488053B2 (en) * 2017-10-06 2022-11-01 Adobe Inc. Automatically controlling modifications to typeface designs with machine-learning models
US10983679B2 (en) * 2017-10-06 2021-04-20 Adobe Inc. Selectively enabling trackpad functionality in graphical interfaces
US10339680B2 (en) * 2017-10-06 2019-07-02 Adobe Inc. Graphics control data for performing skeleton-based modifications of a typeface design
US10950017B2 (en) 2019-07-08 2021-03-16 Adobe Inc. Glyph weight modification
US11295181B2 (en) 2019-10-17 2022-04-05 Adobe Inc. Preserving document design using font synthesis
US11610046B2 (en) * 2019-10-29 2023-03-21 Adobe Inc. Automatic generation of responsive font effects based on font elements

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4742344A (en) * 1984-12-20 1988-05-03 International Business Machines Corp. Digital display system with refresh memory for storing character and field attribute data
US4843593A (en) * 1985-08-23 1989-06-27 Sharp Kabushiki Kaisha Word processor with decorative character printer
US5175811A (en) * 1987-05-20 1992-12-29 Hitachi, Ltd. Font data processor using addresses calculated on the basis of access parameters

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4298945A (en) * 1978-05-12 1981-11-03 Eltra Corporation Character generating method and apparatus
GB2048624B (en) * 1979-05-02 1982-12-15 Ibm Graphics display apparatus
US4254468A (en) * 1979-05-03 1981-03-03 Eltra Corporation Typesetter character generating apparatus
USRE30679E (en) * 1979-06-14 1981-07-14 Rockwell International Corporation Character generating method and system
JPS5739963A (en) * 1980-08-22 1982-03-05 Photo Composing Mach Mfg Co Ltd Memorizing method for character, figure and the like and photocomposing device
US4553214A (en) * 1982-07-01 1985-11-12 Sperry Corporation Angle based stroke generator
US4594674A (en) * 1983-02-18 1986-06-10 International Business Machines Corporation Generating and storing electronic fonts
US4675830A (en) * 1984-07-06 1987-06-23 Compugraphic Corporation Method for producing a scaleable typeface data
US4674059A (en) * 1984-09-10 1987-06-16 Allied Corporation Method and apparatus for generating a set of signals representing a curve
US4670841A (en) * 1985-07-23 1987-06-02 Kostopoulos George K Composite character generator
US4959801A (en) * 1986-02-07 1990-09-25 Bitstream Inc. Outline-to-bitmap character generator
US4785391A (en) * 1986-02-07 1988-11-15 Bitstream Inc. Automated bitmap character generation from outlines
US4849746A (en) * 1986-04-07 1989-07-18 Dubner Computer Systems, Inc. Digital video generator
US5579416A (en) * 1986-10-27 1996-11-26 Canon Kabushiki Kaisha Character processing apparatus for selectively modifying a font pattern
US5398311A (en) * 1987-02-25 1995-03-14 Canon Kabushiki Kaisha Character processing apparatus and method for processing character data as an array of coordinate points of contour lines
US4897638A (en) * 1987-02-27 1990-01-30 Hitachi, Ltd. Method for generating character patterns with controlled size and thickness
US4827253A (en) * 1987-05-18 1989-05-02 Dubner Computer Systems, Inc. Video compositing using a software linear keyer
US5280577A (en) * 1988-01-19 1994-01-18 E. I. Du Pont De Nemours & Co., Inc. Character generation using graphical primitives
US5201032A (en) * 1988-06-02 1993-04-06 Ricoh Company, Ltd. Method and apparatus for generating multi-level character
US5233671A (en) * 1989-02-22 1993-08-03 Ricoh Company Ltd. Image coding method for coding characters using a modified Bezier curve
US5099435A (en) * 1989-03-31 1992-03-24 Bitstream, Inc. Method and apparatus for conversion of outline characters to bitmap characters
JP2850979B2 (en) * 1989-04-21 1999-01-27 キヤノン株式会社 Character processing apparatus and method
US4993853A (en) * 1989-08-11 1991-02-19 International Business Machines Corporation Matrix character modification information unique to a given font
JP3021547B2 (en) * 1989-09-29 2000-03-15 セイコーエプソン株式会社 Character pattern generation method
US5150108A (en) * 1989-12-27 1992-09-22 Xerox Corporation Method for slanting a generic font format while inserting corrective pixels to improve print quality
JP2972775B2 (en) * 1990-02-14 1999-11-08 株式会社東芝 Data processing device
US5459828A (en) * 1990-08-01 1995-10-17 Xerox Corporation Optimized scaling and production of raster fonts from contour master fonts
US5142273A (en) * 1990-09-20 1992-08-25 Ampex Corporation System for generating color blended video signal
US5263132A (en) * 1990-09-28 1993-11-16 Michael R. Parker Method of formatting documents using flexible design models providing controlled copyfit and typeface selection
JPH0540463A (en) * 1991-08-08 1993-02-19 Hitachi Ltd Multi-level character generator
JP3164617B2 (en) * 1991-11-07 2001-05-08 株式会社日立製作所 Apparatus and method for deforming character / graphics
US5416898A (en) * 1992-05-12 1995-05-16 Apple Computer, Inc. Apparatus and method for generating textual lines layouts
US5353396A (en) * 1992-06-04 1994-10-04 Altsys Corporation System and method for generating complex calligraphic curves
US5394523A (en) * 1993-01-22 1995-02-28 Taligent, Inc. Polymorphic graphic device
US5664086A (en) * 1993-04-16 1997-09-02 Adobe Systems Incorporated Method and apparatus for generating digital type font, and resulting fonts using generic font and descriptor file

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4742344A (en) * 1984-12-20 1988-05-03 International Business Machines Corp. Digital display system with refresh memory for storing character and field attribute data
US4843593A (en) * 1985-08-23 1989-06-27 Sharp Kabushiki Kaisha Word processor with decorative character printer
US5175811A (en) * 1987-05-20 1992-12-29 Hitachi, Ltd. Font data processor using addresses calculated on the basis of access parameters

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1048456A2 (en) * 1999-02-17 2000-11-02 Adobe Systems Incorporated Generating a glyph
EP1048456A3 (en) * 1999-02-17 2002-08-28 Adobe Systems Incorporated Generating a glyph
US6678410B1 (en) 1999-02-17 2004-01-13 Adobe Systems Incorporated Generating a glyph
US6760029B1 (en) 1999-02-17 2004-07-06 Adobe Systems Incorporated Generating a glyph

Also Published As

Publication number Publication date
US5664086A (en) 1997-09-02
US6600490B1 (en) 2003-07-29
US5949435A (en) 1999-09-07
AU6636894A (en) 1994-11-08

Similar Documents

Publication Publication Date Title
WO1994024623A1 (en) Synthetic font generator
EP0167838B1 (en) Method for producing a scaleable typeface data
EP0534622B1 (en) Intelligent font rendering co-processor
US6760029B1 (en) Generating a glyph
US5295238A (en) System, method, and font for printing cursive character strings
JPH04500130A (en) Method and apparatus for converting outline characters to bitmap characters
KR100209455B1 (en) Character generating method and apparatus thereof
EP0284980B1 (en) Method for generating character images for dot printing
DE3515471A1 (en) NAVIGATION SYSTEM FOR SELF-DRIVEN VEHICLES
JPS5936778B2 (en) data printing device
US5995086A (en) Method of generating multiple-master typefaces
CN100397480C (en) Character-picture generator, character generating method and storage medium thereof
US5850228A (en) Character generation with extracted and transformed skeleton data
JP3330277B2 (en) Character pattern generator
US5609427A (en) Kerning method and a typographic apparatus utilizing same
US5519412A (en) Pattern processing method
US5668934A (en) Interface to sophisticated printers
US5150108A (en) Method for slanting a generic font format while inserting corrective pixels to improve print quality
EP0438246B1 (en) Method and device for outputting multicolor document
JPH10143134A (en) Method for forming and storing characters and apparatus therefor
JPH0934434A (en) Character generating device
JPS62204956A (en) Document processing system
US6034702A (en) Character forming apparatus
JPH025095A (en) Character output system
AU669696B2 (en) Object based graphics using quadratic polynomial fragments

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AT AU BB BG BR BY CA CH CN CZ DE DK ES FI GB GE HU JP KG KP KR KZ LK LU LV MD MG MN MW NL NO NZ PL PT RO RU SD SE SI SK TJ TT UA UZ VN

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA