Patent Publication Number: US-2020279415-A1

Title: Efficiently Computed Distance Fields

Description:
BACKGROUND 
     This description relates to employing various techniques to optimize the production of distance field representations to efficiency prepare textual content for presentation. 
     The astronomical growth of available textual content on the Internet has lead users to demand more variety in expressing this content. Correspondingly, the number of available fonts that can represent this textual content has grown. Along with the many different types of fonts, each font is typically presentable with different typographical emphasis (e.g., bold, italic, etc.). Due to all these font variations, interest is growing to quickly and efficiently prepare fonts for presentation on an end user device. 
     SUMMARY 
     The systems and techniques described below employ one or multiple optimization techniques to efficiently produce distance fields. By allowing a user to limit the number of points (e.g., pixels) being represented in a distance field, less operations need to be executed (e.g., some pixels can be automatically assigned visual properties rather than calculating a distance field value for mapping visual properties to the pixels). Also, the separation between a distance field point (e.g., pixel) and a character outline contour can be used to further limit executed operations. By grouping similar types of points (e.g., pixels that are horizontally closest to the outline contour), additional operations do not need to be executed thereby generating a distance field in an efficient manner while conserving computation resources (e.g., processing time, memory, etc.). 
     In one aspect, a computing device implemented method includes receiving a collection of line segments representing a glyph space. For each line segment in the collection, the method includes determining if each side of the line segment is located within an interior or an exterior of the glyph shape. The method includes determining one or more intersections of the line segments in the collection and an array of points of a grid. Each intersection represents a location that the respective line segment crosses a vertical or horizontal centerline of a point included in the points of the array. For each point included in the points of the array and along the centerline of the respective point, the method includes determining a distance between the respective point and one of the one or more intersections. For each point in the array of points, the method includes assigning a distance field value based on a distance that represents a minimum distance between the respective point and a nearest line segment of the line segment collection. The distance field value also represents whether the point is located within the interior or the exterior of the glyph shape. 
     Implementations may include one or more of the following features. The method may further include rendering the distance field values into a distance field image. Assigning the distance field value may be based on an externally specified distance. The distance may be along a first coordinate axis and limits the use of points along a second coordinate axis, which is orthogonal to the first coordinate axis, to reduce computations. The distance field values may be determined by grouping points that are closer to the collection of line segments along a coordinate axis and grouping points that are closer to the collection of line segments along an orthogonal coordinate axis. Non-crossing vectors associated with grouped points may be used to reduce computations. The coordinate axis may be a horizontal axis and the orthogonal coordinate axis may be a vertical axis. Each point in the grid may represent a pixel or a subpixel component. The method may further include assigning a visual property to each distance field value. Determining the collection of line segments to represent the glyph may use a recursive binary subdivision technique. Each point of the grid may represent a subpixel component of a pixel arranged horizontally. Each point of the grid may be represent a subpixel component of a pixel arranged vertically. Each point in the grid may represent a subpixel component of a pixel arranged diagonally. Each point in the grid may represent a subpixel component of a pixel, and an array of subpixels are aligned along an axis and another array of subpixels are aligned along an orthogonal axis. 
     A system includes a computing device that includes a memory configured to store instructions. The system also includes a processor to execute the instructions to perform operations that include receiving a collection of line segments representing a glyph space. For each line segment in the collection, operations include determining if each side of the line segment is located within an interior or an exterior of the glyph shape. Operations include determining one or more intersections of the line segments in the collection and an array of points of a grid. Each intersection represents a location that the respective line segment crosses a vertical or horizontal centerline of a point included in the points of the array. For each point included in the points of the array and along the centerline of the respective point, operations include determining a distance between the respective point and one of the one or more intersections. For each point in the array of points, operations include assigning a distance field value based on a distance that represents a minimum distance between the respective point and a nearest line segment of the line segment collection. The distance field value also represents whether the point is located within the interior or the exterior of the glyph shape. 
     Implementations may include one or more of the following features. Operations may further include rendering the distance field values into a distance field image. Assigning the distance field value may be based on an externally specified distance. The distance may be along a first coordinate axis and limits the use of points along a second coordinate axis, which is orthogonal to the first coordinate axis, to reduce computations. The distance field values may be determined by grouping points that are closer to the collection of line segments along a coordinate axis and grouping points that are closer to the collection of line segments along an orthogonal coordinate axis. Non-crossing vectors associated with grouped points may be used to reduce computations. The coordinate axis may be a horizontal axis and the orthogonal coordinate axis may be a vertical axis. Each point in the grid may represent a pixel or a subpixel component. Operations may further include assigning a visual property to each distance field value. Determining the collection of line segments to represent the glyph may use a recursive binary subdivision technique. Each point of the grid may represent a subpixel component of a pixel arranged horizontally. Each point of the grid may be represent a subpixel component of a pixel arranged vertically. Each point in the grid may represent a subpixel component of a pixel arranged diagonally. Each point in the grid may represent a subpixel component of a pixel, and an array of subpixels are aligned along an axis and another array of subpixels are aligned along an orthogonal axis. 
     In another aspect, a system includes a computing device that includes a memory configured to store instructions. The system also includes a processor to execute the instructions to perform operations that include receiving a collection of line segments representing a glyph space. For each line segment in the collection, operations include determining if each side of the line segment is located within an interior or an exterior of the glyph shape. Operations include determining one or more intersections of the line segments in the collection and an array of points of a grid. Each intersection represents a location that the respective line segment crosses a vertical or horizontal centerline of a point included in the points of the array. For each point included in the points of the array and along the centerline of the respective point, operations include determining a distance between the respective point and one of the one or more intersections. For each point in the array of points, operations include assigning a distance field value based on a distance that represents a minimum distance between the respective point and a nearest line segment of the line segment collection. The distance field value also represents whether the point is located within the interior or the exterior of the glyph shape. 
     Implementations may include one or more of the following features. Operations may further include rendering the distance field values into a distance field image. Assigning the distance field value may be based on an externally specified distance. The distance may along a first coordinate axis and limits the use of points along a second coordinate axis, which is orthogonal to the first coordinate axis, to reduce computations. The distance field values may be determined by grouping points that are closer to the collection of line segments along a coordinate axis and grouping points that are closer to the collection of line segments along an orthogonal coordinate axis. Non-crossing vectors associated with grouped points may be used to reduce computations. The coordinate axis may be a horizontal axis and the orthogonal coordinate axis may be a vertical axis. Each point in the grid may represent a pixel or a subpixel component. Operations may further include assigning a visual property to each distance field value. Determining the collection of line segments to represent the glyph may use a recursive binary subdivision technique. Each point of the grid may represent a subpixel component of a pixel arranged horizontally. Each point of the grid may be represent a subpixel component of a pixel arranged vertically. Each point in the grid may represent a subpixel component of a pixel arranged diagonally. Each point in the grid may represent a subpixel component of a pixel, and an array of subpixels are aligned along an axis and another array of subpixels are aligned along an orthogonal axis. 
     These and other aspects, features, and various combinations may be expressed as methods, apparatus, systems, means for performing functions, program products, etc. 
     Other features and advantages will be apparent from the description and the claims. 
    
    
     
       DESCRIPTION OF DRAWINGS 
         FIG. 1  illustrates a computer system presenting a font editing manager interface. 
         FIG. 2  illustrates an outline of a glyph being represented by lines and curves. 
         FIG. 3  illustrates a glyph outline fill rule based on non-zero winding number. 
         FIG. 4  is a block diagram of a font rendering engine and a data storage archive. 
         FIG. 5  illustrates curves being represented with line segments and recursive subdivision of a curve. 
         FIG. 6  illustrates a set of line intersections between lines representing the glyph shape and horizontal pixel centers. 
         FIG. 7  illustrates a set of line intersections between lines representing the glyph shape and vertical pixel centers. 
         FIG. 8  illustrates distance values determined along horizontal pixel rows. 
         FIG. 9  illustrates distance values determined along vertical pixel columns. 
         FIGS. 10A-B ,  11 A-E, and  12 A-B illustrate determining the minimum distance between a point and the nearest point on the glyph shape. 
         FIG. 13  illustrates reducing distance field computations based on pixel position. 
         FIG. 14  illustrates grouping pixels based on the vertical or horizontal closeness to a glyph outline contour. 
         FIG. 15  illustrates reducing distance field computations based on vectors to the nearest font outline contour that do not cross. 
         FIG. 16  illustrates visual properties assigned to distance field values. 
         FIG. 17  illustrates a flow chart of operations executed by a distance field generator. 
         FIG. 18  illustrates an example of a computing device and a mobile computing device that can be used to implement the techniques described here. 
     
    
    
     DETAILED DESCRIPTION 
     Rendering text on a screen in a timely fashion can be considerably important to viewers. Typically the rendering process calls for associating a stream of encoded numbers representing units of text, for example Unicode code points or another standard, with a representation of the corresponding text shape and producing an image of the shape which can then be imprinted on a display screen. Glyphs can be considered as the representation of a text unit&#39;s shape and this shape can be described in a number of ways. For two-dimensional glyphs, the glyph shape is often described as a collection of lines and curves. The curves can be, for example, quadratic or cubic Bezier curves since they are relatively easy to create and control, and their properties facilitate compact representations. The process of converting this collection of geometric objects into an image for subsequent display is referred to as rendering and numerous techniques have been developed for rendering a glyph representation to an image. 
     In one technique, distance fields are used to represent glyph shapes for rendering text. Techniques described herein provide efficient generation of distance field images from representations of glyph outlines. By reducing computational operations to produce such distance fields, both the time and computational burden can be reduced for rendering anti-aliased text with high quality at multiple aspect sizes. 
     To provide some context on text representations and rendering, typically a graphic artist will draw representations of glyphs in some media and these representations will be encoded into a set of geometric objects such as lines and curves. The drawings may be created with pen and paper and scanned or they may begin as digital drawings that use control points to specify the properties of the geometric objects. Generally the artist will produce a sufficient number of glyph representations to fully portray a writing system, such as Latin or Arabic or Chinese. Scripts, consisting of a number of glyphs, fully describe the text elements required for a writing system. A particular element of a script may be represented in a number of forms as long as a reader of the writing system can recognize the element. Thus, there is a wide latitude of artistic freedom in representing a script. The method of representing glyphs must accommodate such artistic latitude and the rendering system must be capable of faithfully conveying the resultant glyph images. 
     Quite often collections of glyph representations are grouped together into font families according to their common appearance. Thus a font family can consist of glyphs organized by weight (thin, regular, bold, etc.), width (condensed, regular, extended, etc.), slant angle (regular, italic, etc.), or style (serif, sans serif, etc.). Font families are generally stylistically consistent so as to convey a sense of unity and purpose of design and give the reader a consistent reading experience. 
     Referring to  FIG. 1 , a computing device (e.g., computer system  100 ) includes a display  102  that presents a graphical user interface (GUI)  104  of a font editing manager  106  that is being executed by the computing device. In this example, the GUI  104  allows such graphic artists to review, develop, etc. various types of fonts, glyph shapes within a font family, etc. The font editing manager  106  may provide other types of functionality such as allowing users to review and adjust font family members. For example, different typographical emphasis of a font (e.g., a normal version of the font  108 , a bold version of the font  110 , an italic version of the font  112 , a bold italic version of the font  114 , etc.) can be presented for potential adjustments. 
     Referring to  FIG. 2 , a glyph outline  202  can be represented by using lines (e.g., line  204 ) and curves (e.g., curve  206 ), such as polynomial Bezier curves. The characteristics of such curves are determined by control points in space that may be either on-curve (as represented by point  208 ) or off-curve (as represented by point  210 ). This collection of joined lines and curves is used to represent the boundary between the exterior and interior regions of the glyph shape. A distance field generator  200  (e.g., included in the font editing manager  106 ) uses a collection of lines and curves to determine the distance to the nearest curve location at each point in space based on rules for how to fill the glyph shape. Referring to  FIG. 3 , in one arrangement, a fill rule is established for a glyph  300  that specifies how an interior  320  of the glyph is distinguished from an exterior  322  of the glyph so that the glyph shape may be filled (e.g., with a color, shade, etc.). The fill region may represent where to apply ink in a printing process, where to color a pixel on a screen (or apply any type of visual property to the pixel). One fill rule technique is the so-called “nonzero winding rule” used in the OpenType specification for fonts. In this rule, a glyph outline is an ordered, directed set of lines and curves (e.g., such as curves  302 ,  304  for glyph  300  or curves  332 ,  334  for glyph  302 ). Beginning outside the glyph shape, a winding number  306  for glyph  300  (or winding number  336  for glyph  301 ) is considered to be zero. If one scans across the glyph outline in any direction, typically horizontally or vertically, the winding number is computed based on the number of glyph outlines crossed. Outline crossings in one direction (e.g., direction  308  for glyph  300  and direction  338  for glyph  301 ) increase the winding number (e.g., winding number  310  for glyph  300  and winding number  340  for glyph  301 ) by 1. If the next outline crossing is in the opposite direction, the winding number is decreased by 1 (e.g., winding number  314  for glyph  300  is decreased by 1). If the next outline crossing is in the same direction, then the winding number is increased by 1 (e.g., winding number of glyph  301  is increased by 1). The process continues until the winding number is once again zero (e.g., winding number  316  for glyph  300  returns to 1, winding number  346  returns to  1 ). As such, in general, outlines of a particular direction increase the winding number and outlines of the opposite direction decrease the winding number. Regions that have a non-zero winding number (e.g., region  320  for glyph  300  and region  350  for glyph  301 ) are considered interior regions and are to be filled. Interior regions associated with a zero winding number are not filled (e.g., zero winding number  314  causes region  322  not to be filled). Interior regions that have a non-zero winding number are filled (e.g., winding number  344  with a values of “2” cause interior region  352  of glyph  301  to be filled). The exact amount of the winding number, other than zero, is generally not important to the fill process. From the process, the sides of a line segment being located within an interior or exterior of a glyph can be determined. 
     When displaying text to a screen, the glyph outline is often first scaled to a particular size relative to the pixels of the screen. The glyph fill rule determines how particular pixels are assigned a visual property (e.g., a color, grey scale, etc.), for example, by controlling the mixing between the foreground text color and the background color. Fully interior pixels are generally assigned the full amount of foreground text color. Pixels along the edge are assigned a partial mixture of foreground and background color in order to smooth the transition between the two and present a more pleasing and readable contrast. This procedure is commonly called anti-aliasing in reference to concepts from digital sampling theory. 
     Anti-aliasing of digital text on a screen can be achieved in numerous ways. One approach is to assign a foreground/background mixing value based on the total area of the pixel covered within the interior of the glyph outline. The rendering process determines this area based on the outline boundary as it crosses the pixel. Distance fields can also be used to determine the foreground/background mixing value by mapping the pixel&#39;s distance field value to a corresponding mixing value (or other type of visual property). A two-dimensional (2D) distance field specifies the minimum distance to an outline at every point in space. A signed 2D distance field assigns a positive or negative sign to the minimum distance based on some convention. For example, in a typical signed distance field, interior locations may be assigned positive values and exterior locations may be assigned negative values. The reverse convention (or other types of conventions) may also be applied. In both cases, a distance of zero is considered exactly on the outline boundary. Similarly, the convention may specify that distances above a certain value are considered interior and distances below a certain value are exterior while distances at exactly that value are exactly on the outline boundary. 
     Various degrees of anti-aliasing can be achieved by mapping a distance field value to a visual property such as a foreground/background mixing value. This mapping can take many forms, including linear and non-linear mappings, and the mapping is generally limited in space relative to the outline boundary. For digitally rendered text the nature of the mapping controls the appearance of the glyphs and their edge characteristics. For example, if the mapping describes a gradual transition from background to foreground over a larger distance, then the edge of the rendered glyph appears softer and less definitive. If the transition occurs over a smaller distance range, the glyph appearance is sharper and more definitive, trending toward being discrete or binary. 
     Equidistant contours within the distance field represent self-similar representations of the glyph outline. Using these contours as the basis for the anti-aliasing mapping can result in glyph appearances that are smaller, e.g., with thinner stems, or larger, e.g., with thicker stems. The location of the glyph outline is effectively shifted uniformly to an equidistant location. At the same time the transition from background to foreground can change nature. The combination of the two adjustments in glyph rendering can lead to a wide range of rendered glyph appearances from a single glyph outline. 
     A digitally sampled, signed 2D distance field is an image in which each pixel represents the minimum distance to the glyph outline and in which the sign of the value represents whether the pixel center is inside or outside the glyph outline, in accordance with the fill rule that is applicable to the outline. In this case the continuous values of the distance field are sampled and encoded as values in the distance field image. Note that the digital sampling does not have to correspond to a particular screen representation nor does it have to be uniform or rectangular in nature. Various discrete sampling schemes can be used and these affect the mapping between a sampled distance value and a visual property (e.g., a screen mixing value). 
     Similar to pixels, such techniques can also be employed for other types of points used to define distance fields. For example, sub pixels can be used as distance field points. Digital screens often use sub pixel color channels to represent a perceived color of the pixel. Typically these are red, green, and blue channels that when combined can map out a wide range of colors. These subpixel elements may consist of various topologies such as horizontal bars, vertical bars, diagonally arranged, hexagonal regions, etc. with the constraint that they uniformly cover the screen and are sufficiently small so as to not be individually perceived. Distance field values can be computed for each subpixel element and a mapping between distance field value and subpixel intensity can be established. Controlling subpixel intensities relative to the glyph outline results in a more faithful perceived representation of the glyph shape. 
     A common use of digitally sampled, signed 2D distance fields is to encode the distance field image into a texture map and then map that texture onto a set of vertices in 2D or three dimensional (3D) space. In doing so the texture map and distance values may be interpolated. One or more interpolation schemes may be applied. One interpolation scheme that can be employed is bilinear interpolation in which the values of four adjacent pixels are combined in each pixel. Bi-cubic interpolation is another employable technique to combine distance field values encoded into a texture map in order to more faithfully represent the underlying non-sampled distance field. 
     Following interpolation, the resulting distance value for a given fragment in 2D or 3D space is mapped to a visual property (e.g., a foreground/background mixing value) for the screen. Applying the mapping to interpolated distance values results in non-pixelated edges at a wide variety of scaling&#39;s between the underlying world space and screen space. This allows a distance field that has been sampled using one sampling scheme to be used as the basis for rendering text at a wide variety of text to screen size ratios, without loss of quality due to pixelization at high zoom values. Conversely, at small zoom levels, the glyph rendering appears consistent across pixel boundaries and aliasing effects due to sampling the glyph outline are minimized. These are considerable benefits of using distance fields to render text in 2D and 3D graphical applications. 
     Determining a sampled 2D signed distance field value can be considered a non-trivial operation, particularly when attempting to conserve computational resources. For some techniques, a set of cells are used to enclose the outline of a glyph object. Distance values for sampled pixels are reconstructed from the cells and interior/exterior regions are determined relative to the cells to determine a signed distance. However, when different parts of the glyph outline overlap each other, erroneous results may be produced in the distance field. Since overlapping contours occur in a number of fonts, such errors can frequently occur. By consolidating the overlapping region, the erroneous results can be addressed, but through a computationally expensive process. 
     Referring to  FIG. 4 , a distance field generator  200  is included in a font rendering engine  402  (e.g., contained in the font editing manager  106 ) that is executed by a computer system  404  that is connected to a storage device  406 . The distance field generator  200  generates signed distance fields in an optimized and efficient manner. Further the operations of the distance field generator  200  address overlapping contours within a glyph outline. The distance field generator  200  produces accurate distance field values that can be used (e.g., assigned visual properties) and stored (e.g., in a distance field database  408  included in the storage device  406 ). The techniques used by the distance field generator  200  may be applied to various type of distance field points; for example, operations be executed on pixels, subpixels, etc. that are assigned signed distance field values which can be mapped to one or more visual properties (e.g., colors, grey scale levels, etc.). Other types of computational architectures may be employed, for example distributed processing techniques can be used in which distance fields are computed across multiple computing devices (e.g., servers, user devices, etc.). 
     Referring briefly back to  FIG. 2 , a graphical representation of glyph shape outline  202  is provided to the distance field generator  200 . The glyph shape outline  202  (e.g., of a dollar sign character) includes contours made up of various lines and curves that are scaled to a desired size relative to a set of pixels in the final distance field image. One or more techniques may be used to represent the glyph shape outline  202 , for example, one or more geometric objects can be used to describe a portion or multiple portions of the outline. Additionally, the geometric objects can describe boundaries between interior and exterior regions of the glyph, etc. 
     In general, the distance field generator  200  employs a heuristic approach to reduce the number of unneeded computations of distance field values. For example, the distance field generator  200  attempts to compute distance field values that will actually be used while attempting to not compute distance field values that will not be used (or are simply not needed). The output of the distance field generator  200  is a signed distance field image that corresponds to the scaled outline, and the distance field values may be encoded to the image by using one or more techniques. 
     To initiate the creation of the distance field for outline  202 , the size of output distance field image is allocated (e.g., a scale is selected by the user). In general, the contours of the outline  202  can be considered a collection of lines, curves, etc. such as quadratic Bezier curves or cubic Bezier curves. Other types of curves can be also used by the distance field generator  200  as long as the curves can be mathematically represented. As illustrated in the figure, the outline  202  includes a number of curves (e.g., curve  206 ) to represent the glyph (e.g., of the dollar sign character). 
     Referring to  FIG. 5 , a curve is specified by on-curve control points  502  and  506  with the degree of curvature controlled by off-curve point  504 . The distance field generator  200  evaluates the curves of the outline  202  into line segments (e.g., line segment  508 ) that approximate the curve (within a tolerance level). One or more techniques may be employed to approximate the curves with line segments, and these techniques may depend upon the type or types of curves to represent the outline. For example, for quadratic Bezier curves or cubic Bezier curves, the distance field generator may employ recursive bisection using a technique such as De Casteljau&#39;s technique to efficiently generate lines segments from these Bezier curves. Such techniques (e.g., a recursive binary subdivision technique) are described in U.S. patent application Ser. No. 14/993,424, titled “Converting Font Contour Curves”, and filed on 12 Jan. 2016, and U.S. patent application Ser. No. 15/850,853, titled “Harmonizing Font Contours”, and filed on 21 Dec. 2017, the content of both being incorporated by reference herein. Typically, by increasing the number of line segments to represent a curve, the line segments more closely track the shape of the curve. In some arrangements a tolerance value can be set (e.g., set by the user for the font rendering engine  402 ) to control the number of line segments produced for approximating the shape of a curve. In some arrangements the selected tolerance can cause different numbers of line segments to be produced in different areas of an outline. For example, in areas of a glyph outline where a high degree of curvature is present (e.g., area  206  shown in  FIG. 2 ) more line segments may be needed to approximate the curve, while in areas of lower curvature (e.g., area  204  also shown in  FIG. 2 ), fewer line segments may be needed. 
     Once the line segments have been produced to appropriately represent the curves of the outline (based on the tolerance), the distance field generator  200  performs calculations based upon the rows of pixels and columns of pixels that are used to represent the distance field image of the glyph outline. In this example, operations associated with the pixel rows are first executed; however, operations associated with pixel columns may be initially executed. In this example, for each line segment in a set of line segments that approximate a contour of the outline, the distance field generator  200  calculates the line segment&#39;s horizontal intersection or intersections  600  (shown in  FIG. 6 ) with each row of points (e.g., pixels) and adds the results to a representation of all intersections for a given row of pixels. Typically these data are stored, for example, in the distance field database  408  (shown in  FIG. 4 ). 
     Referring to  FIG. 7 , similar operations are executed by the distance field generator  200  for vertical intersections with pixel columns. In this figure an outline  700  of another glyph (e.g., an ampersand character) is presented and is processed by the distance field generator  200 . Similar to the rows of points (e.g., pixels) with respect to  FIG. 6 , for each line segment in a set of line segments that approximate a contour of the outline  700 , the distance field generator  200  calculates the line segment&#39;s vertical intersection or intersections with each column of points (e.g., pixels) and adds the results to produce a representation of all the intersections for a given column of pixels. Also, similar to the data associated with the pixel rows, the distance field generator  200  stores the pixel column data in the distance field database  408  on the storage device  406 . 
     Once pixel row and pixel column data has been calculated and stored, the distance field generator  200  executes operations to produce a distance field. For example, the distance field generator  200  produces a 2D data grid to store the horizontal distance from each corresponding pixel to the closest contour of the outline. The extent of this 2D data grid is the same as the final distance field image produced by the distance field generator  200  based on the outline extents and the distance limit supplied. 
     With the 2D data grid produced, the distance field generator  200  executes operations for each row of horizontal intersections calculated and stored. In particular, the horizontal intersections are sorted from low to high. Next any intersections that do not represent a change in winding direction are removed. By executing this operation, the distance field generator  200  accounts for overlapping contours of the outline. Stepping through each row of pixels, the distance field generator  200  assigns each pixel the square of the distance from the pixel to the nearest intersection. The distance field generator  200  also tracks whether the pixel is inside or outside the contour. From these operations, a set of distances are measured horizontally for each pixel center to the nearest boundary of the outline. Referring to  FIG. 8 , a representation  800  represents the horizontal distance data. 
     The distance field generator  200  also executes similar operations for the stored vertical data. In particular, for each column of vertical intersections, the distance field generator  200  sorts the vertical intersections from low to high. The distance field generator  200  also removes any intersections that do not represent a change in winding direction. From this operation, the distance field generator also accounts for overlapping contours. Stepping through each column of pixels, the distance field generator  200  assigns each pixel the square of the distance from the pixel to nearest intersection. From these operations, a set of distances are measured vertically for each pixel center to the nearest boundary of the outline. Referring to  FIG. 9 , a representation  900  presents the vertical distance data. 
     Referring to  FIGS. 10, 11, and 12 , a series of graphical illustrations are presented that represent operations of the distance field generator  200  for efficiently calculating the final distances for a distance field. By executing these operations, the distance field generator  200  determines the minimum distance from a given point (e.g., pixel, subpixel, etc.) to the closest contour of the glyph outline. To determine the distance, the distance field generator  200  uses Pythagoras&#39; theorem that states the square of the hypotenuse of a right triangle is the sum of the squares of the other two sides of the right triangle. Considering the distance from a pixel to the contour as being the hypotenuse of a right triangle, the minimum distance between the pixel and the contour (again the hypotenuse of the right triangle) can be found by determining the minimum of the sum of the square of the other two sides (of the right triangle). One of the other sides of the triangle is the horizontal distance from the pixel to the contour, and the second of the other sides (of the triangle) is the integer distance (vertically stepping up or down) to the next pixel (e.g., a pixel directly above, two pixels directly above, a pixel directly below, two pixels directly below, etc.). From the minimum sum (of the squared distances) for the other sides, the squared minimum distance to the contour is similarly determined. Further, rather than computing the square root of each distance (which involves executing inefficient operations), squared distances are used along with efficiently executed summing operations. Once the squared minimum distance is efficiently determined, then a single square can be executed, thereby conserving computational resources. 
     Referring to  FIG. 10A , a two dimensional pixel grid  1000  presents an outline contour  1002  (e.g., of a glyph) that has a relatively simple closed shaped geometry. For demonstrative purposes, a single pixel  1004  is highlighted in the 2D pixel grid  1000 . By executing operations, the distance field generator  200  efficiently determines the minimum distance from the pixel  1004  to the closest portion of the outline contour. Referring to  FIG. 10B , operations of the distance field generator  200  start by determining the horizontal distance from the center of the pixel  1004  to a point  1006  where a centerline  1008  (from the pixel center) intersects the outline contour  1002 . Referring to  FIG. 11A , the distance field generator  200  next steps in the vertical direction to form a vertical side  1100  of a right triangle while a previously determined horizontal distance (from a pixel vertically adjacent to pixel  1004  to the intersection point with the outline contour) provides a horizontal side  1102  of the right triangle. In this particular example, the generator  200  steps up one pixel in the vertical direction to form the vertical side  1100 . As such, the vertical distance is an integer number of pixels (in this case one pixel) and the horizontal distance has been previously determined. The squared length of a hypotenuse  1104  of the right triangle can be determined from the sum of the squared lengths of the two sides  1100  and  1102 . By further stepping vertically from the pixel, the squared length of the hypotenuse of the next formed right triangle can be determined. Referring to  FIG. 11B , the vertical side is incremented by another pixel so a two pixel offset is the length of a vertical side  1106 . The previously determined horizontal distance from this offset pixel to the intersection point with the outline contour  1002  provides the length of a horizontal side  1108  of the right triangle. From these squared lengths, the squared length of the hypotenuse  1110  can be calculated to provide a measure of the distance from the pixel to the outline contour at a point  1112 . Referring to  FIG. 11C, 11D, and 11E , the distance field generator  200  continues to increment the vertical offset (e.g., a 3-pixel vertical offset in  FIG. 11C , a 4-pixel vertical offset in  FIG. 11D , and a 5-pixel vertical offset in  FIG. 11E ). For each increment increase, the squared length of a hypotenuse is calculated that represents the distance between the pixel and a point on the outline contour (e.g., a hypotenuse  1114  provides a distance to point  1116  for a 3-pixel offset, a hypotenuse  1118  provides a distance to a point  1120  for a 4-pixel offset, and a hypotenuse  1122  provides a distance to a point  1124  for a 5-pixel offset). The distance field generator  200  continues to increment the vertical offset to determine additional distances. 
     In a similar manner the generator also increments in the other vertical direction (e.g., below the pixel  1004 ) to determine the squared length of corresponding hypotenuses. Referring to  FIG. 12A , for a one-pixel offset below the pixel  1004 , a vertical side  1200  is formed. From the previously determined horizontal distance to the contour outline, a horizontal side  1202  is determined and the squared length of a hypotenuse  1204  can be calculated. Referring to  FIG. 12B , the downward pixel offset is incremented once more (for a two-pixel offset) to produce a vertical side  1206 . Extending beyond the lower vertical limit of the contour  1002 , no horizontal distance was previously determined, and a hypotenuse cannot be calculated for this pixel increment. By incrementing above and below a pixel (e.g., pixel  1004 ), the distance field generator  200  can determine the minimum distance between the pixel and the outline contour (e.g., calculating the square root of the minimum squared distance value). 
     In order to determine the minimum distance for each pixel, the distance field generator  200  would need to execute a considerable number of operations given the number of vertical offsets for each pixel. For example, probing an entire column of pixels containing the initial pixel  1004 , the performance of the generator would be slow, perhaps having a performance of O(N 2 ). However, one or more techniques may be implemented in the distance field generator  200  to improve the performance of the distance field calculations. For example, three optimizing techniques may be used individually or in concert by the distance field generator  200  to improve performance. 
     For one technique, one or more conditions may be applied to limit the number of pixels for which a distance is determined (for the distance field). By reducing the number of pixels, less operations are executed by the distance field generator  200  and the distance field can be computed in a more efficient manner. For one example, the distance field values may not be calculated for field points (e.g., pixels) that are positioned at particular locations. The visual property of pixels sufficiently outside the outline may saturate to a uniform color (e.g. a color such as white), once beyond this limit, distance calculations are redundant. Similarly, pixels located inside the outline may similarly be assigned visual property (e.g., a color such as black) without needing to calculate a distance value. As such, conditions can be defined to limit the pixels for which distance field values are calculated. In some arrangements, the conditions can be user selected; for example, upper, lower, left, and right limits (e.g., thresholds) can be selected by a user (e.g., externally specified) and distance field values are not calculated for pixels located outside these limits. Similarly a user can select limits on the interior of a contour (e.g., the interior of the character “O”) for which distance field values are not calculated (and visual properties may automatically be assigned). In one arrangement, a graphical user interface (GUI) may be employed to allow a user to graphically select limits with a pointing device (e.g., select an upper pixel row and a lower pixel row with a mouse) for which distance field values are not calculated. Setting such limits (e.g., thresholds), the number of computations executed by the distance field generator  200  may be reduced and thereby increase the efficiency for generating distance fields. 
     Referring to  FIG. 13 , a graphical representation is presented that illustrates a second technique to improve distance field computational efficiency. Probing a vertical distance that is greater than the original horizontal distance (separating a pixel and a contour) cannot produce a squared sum (e.g., a hypotenuse of a right triangle) that is smaller than the squared sum (e.g., hypotenuse) for vertical distances less or equal to the horizontal distance. So a distance along a coordinate axis (e.g., a distance along the horizontal axis from a pixel to a contour) limits operations executed along an orthogonal axis (e.g., the vertical axis). As shown in the figure, a pixel  1300  is selected for determining the minimum distance to a contour  1302  (for a distance field value). As represented by a horizontal line  1304 , the pixel  1300  is located a particular horizontal distance (e.g., eight pixel widths) from an intersection point  1306  on the contour  1302 . Based upon this horizontal distance (e.g., eight pixel widths), the number of vertical steps is limited for computing the sums of squared right triangle sides (and corresponding, the hypotenuse of the right triangle). In this example, since the horizontal separation distance between the pixel  1300  and the contour intersection point  1306  is eight pixel widths, computations (to sum right triangle squared sides) are only executed for eight upward increments (above the pixel  1300 ) and for eight downward increments (below the pixel  1300 ). In the figure, the eight upward increments (above the pixel  1300 ) are illustrated. In particular, right triangle  1308  includes one side with a vertical length of one pixel (from the pixel  1300 ) and a horizontal length that horizontally extends from this vertical height to an intersection point  1310 . Stepping up the entire eight pixels, a right triangle  1312  includes a side that with a vertical length that is eight pixels (from the pixel  1300 ) and a horizontal length that extends from this higher vertical height to the an intersection point  1314 . As such, squared sides are summed by the distance field generator  200  for eight right triangles that extend vertically upward from the pixel  1000 . In a similar manner, the distance field generator  200  also sums the squared sides of eight right triangles that extend vertically downward below the pixel  1300  (through these right triangles are not illustrated in the figure). By limiting the upward and downward vertical stepping from each pixel (e.g., eight increments up and eight increments down) for summing the squared sides of right triangles, a considerable number of computations are not executed by the distance field generator  200 , thereby saving considerable resources (e.g., computational time, memory, etc.). Further, by reducing the number of computations, the efficiency of producing a distance field is improved. 
     Referring to  FIG. 14 , another graphical representation is presented that illustrates a third optimization technique to improve the operations of the distance field generator  200 . In general, pixels that are horizontally closest or vertically closest to a contour tend to be located in groups based on the shape of the contour. In this illustrated example, a glyph outline  1400  for a dollar sign character is illustrated and pixels that are horizontally closest to the contour (e.g., along a coordinate axis—the horizontal axis) are shown in one shade (e.g., grey) and pixels that are vertically closest to the contour (e.g., along an orthogonal axis—the vertical axis) are shown in another shade (e.g., white). Based upon the shape of the outline  1400 , the pixels appear in groups; for example, pixel groups  1402 ,  1404 ,  1406 ,  1408 ,  1410 ,  1412 ,  1414 , and  1416  represent pixels that are vertically closest to the outline  1400  and pixel groups  1418 ,  1420 ,  1422 , and  1424  are horizontally closest to the outline  1400 . Based upon these groupings, the distance field generator  200  can perform operations for pixels in a common group in a computationally efficient manner. For example, a row of pixels, which are each identified as being horizontally closest to the outline  1400 , can be processed together, or a column of pixels that are identified as being vertically closest to the outline  202  can be processed together. Processed in this manner, further gains can be achieved due the nature of adjacent pixels of similar type (e.g., pixel that are vertically closest to the outline or pixels that are horizontally closest to the outline). For example, vectors that represent the minimum distance to the outline for similar pixel types typically do not cross each other (non-crossing vectors). As such, a vector representing the minimum distance for pixel can be used to limit the computations needed to calculate the minimum distance (to the outline) for an adjacent pixel. Identifying such limits can further reduce the operations executed by the distance field generator  200  and further improve the efficiency of distance field generation. 
     Referring to  FIG. 15 , a series of pixels are illustrated along with lines that represent the minimum distance value from a corresponding pixel to a contour  1500 . In particular, pixels  1502 ,  1504 ,  1506 ,  1508 ,  1510 ,  1512 ,  1514 , and  1516  are presented along with corresponding lines  1518 ,  1520 ,  1522 ,  1524 ,  1526 ,  1528 ,  1530 , and  1532 . As mentioned above, for pixels of the similar type (e.g., pixels horizontally closest to a contour) the vectors of minimum distances (from the pixels to the contour) generally don&#39;t cross. As such the minimum distance vector for a pixel can be used to limit calculations performed (by the distance field generator  200 ) for an adjacent pixel. For example, for the pixel  1506  the line  1522  represents the minimum distance to the contour  1500 . Considering that line  1522  intersects the contour  1500  at point  1534 , the computations to determine the minimum distance between the pixel  1508  and the contour  1500  can be reduced. For example, since the minimum distance line for pixel  1508  cannot cross line  1522 , the intersection point  1534  (of line  1522 ) can be used as a lower limit for calculating the minimum distance line for pixel  1508 . Being the lower limit, computations regarding pixel  1508  only need to be executed that involve intersection points located at positions above intersection point  1534  (since the resulting minimum distance line  1524  cannot cross the minimum distance line  1522 ). In this example, the intersection point  1534  is located at a vertical position that is three pixels above pixel  1506  (and two pixels above pixel  1508 ). Thus, computations to determine the minimum distance for the pixel  1508  can start at a vertical position that is three pixels above pixel  1508  since the minimum distance line  1524  (for the pixel  1508 ) cannot cross the minimum distance line  1522  (for the adjacent pixel  1506 ). By setting the lower limit for computations, additional operations of the distance field generator  200  may be reduced to further improve efficiency. Similar operations can be employed for vertical fields, again operations are performed on squared distance values to determine the squared minimum distance (e.g., the squared length of a right triangle hypotenuse). For efficiency, once the final squared distance field values are determined, then the distance field generator  200  can perform square root operations to determine the distance values. While such square roots are relatively inefficient, these operations are executed towards the end of the process to minimize their effects on the overall operations of the distance field generator  200 . Referring to  FIG. 16 , once the final distance field values are determined, the distance field generator  200  can assign a visual property to each value to produce a distance field image  1300 . For example, a color, grey scale value (e.g., between white and black), etc. can be assigned based upon the determined distance values for presentation of the glyph (e.g., a dollar sign character represented by the distance field image  1600 ). 
     While the example illustrated in  FIGS. 13, 15, and 16  used pixels to generate a distance field, the described technique can also be employed for other type of points used to define a distance field. For example, the technique may be applied to the generation of subpixel distance fields in an analogous fashion. Resulting subpixel distance field values can similarly be stored in a distance field image. The subpixel components of this image may be arranged in a various ways, depending on the application. For example, to compute horizontally arranged subpixels, three distance field values are computed per each pixel. Horizontal distances are computed to each subpixel center along the vertical centerline of the row of pixels. The sum of the square of the distances for each subpixel component is then computed in a similar manner as described above for pixel centers. Likewise, if the subpixel components are arranged vertically within the pixel, the square of the distance to each vertical subpixel component is computed along the horizontal line from the component to where it intersects the nearest glyph outline line segment. Vertical distances from this subpixel component are then computed and the minimum distance to the outline from the subpixel component is found. 
     Referring to  FIG. 17 , a flowchart  1700  represents operations of the distance field generator  200  included in the font rendering engine  402  (shown in  FIG. 4 ). Operations of the distance field generator  200  are typically executed by a single computing device (e.g., the computer  404 ); however, operations of the generator may be executed by multiple computing devices. Along with being executed at a single site, execution of operations may be distributed among two or more locations. 
     Operations of the distance field generator include receiving  1702  data representing a glyph. For example, data that represents curves of a glyph contour (e.g., quadratic Bezier curves, cubic Bezier curves, etc.) may be received for processing. Operations also include determining  1704  a collection of line segments to represent the shape of the glyph. For example, a recursive bisection using a De Casteljau&#39;s technique can be used to efficiently generate lines segments from these Bezier curves. Operations also include determining  1706  regions (e.g., interior and exterior regions) of the glyph by using the line segments and according to a fill rule. For example, a winding number can be determined and used to identify one or more regions to be filled or not filled (e.g., sides of line segments located interior or exterior to a glyph). Operations also include determining  1708  a set of line intersections between the line segments that represent the glyph shape and a linear sequence (e.g., array) of points (e.g., pixels). For example, a set of line intersections can be determined between the line segments that represent the glyph shape and center lines of horizontal rows of pixels. Similarly a set of line intersections can be determined between the line segments that represent the glyph shape and center lines of vertical columns of points (e.g., pixels). Operations also include determining  1710  a two-dimensional field of points by determining a minimum squared distance from each field point to the nearest line segment. For example, distance field a distance field for a horizontal two-dimensional field of points is generated by determining a minimum squared distance from each point in the horizontal rows of points (e.g., pixels) to nearest line segment, the minimum squared distance being determined from the respective point and the intersection point of the nearest line segment along the center line of the horizontal row of points (e.g., pixels). Similarly, a distance field for a vertical two-dimensional field of points is generated by determining a minimum squared distance from each point in the vertical column of points (e.g., pixels) to the nearest line segment, the minimum squared distance being determined from the respective point and the intersection point of the nearest line segment along the center line of the vertical column of points (e.g., pixels). In some arrangements, these operations can be considered as determining a minimum squared distance from each point in a two-dimensional field of points to a collection of line segments, the minimum squared distance being determined from the respective point to the nearest line segment (of the collection of line segments) along a coordinate axis. The distance horizontally separating a point (e.g., pixel) from a contour can limit the operations to find the minimum distance to the contour (e.g., limit the number vertical steps above and below the pixel for calculating distances). Similarly, the distance vertically separating a point (e.g., pixel) from a contour can limit the operations to find the minimum distance to the contour (e.g., limit the number horizontal steps left and right of the pixel for calculating distances). 
     Operations to determine the distance field also include applying  1712  one or more conditions that reduce the size of the portion of the two-dimensional field of points. For example, a user can select (e.g., graphically with a pointing device) one more limits, thresholds, etc. (e.g., an upper limit, a lower limit, and interior limit) for which minimum distances need not be computed for pixels that exceed the limits. Operations to determine the distance field also include grouping  1714  points that are closer to the collection of line segments along the coordinate axis and grouping points that are closer to the collection of line segments along an orthogonal coordinate axis. For example, pixels that are horizontally closest to the contour can be grouped and processed together, and similarly pixels that are vertically closest to the contour can be grouped and processed together. Operations of the distance field generator also include determining  1716  the square root of each minimum squared distance of each point in the portion of the two-dimensional field. For example, relatively inefficient square root operations can be executed for each pixel only after the squared minimum distances are efficiently calculated for these considerable number of pixels by using summing operations (associated with right triangles). 
       FIG. 18  shows an example of example computer device  1800  and example mobile computer device  1850 , which can be used to implement the techniques described herein. For example, a portion or all of the operations of the distance field generator  200  (shown in  FIG. 2 ) may be executed by the computer device  1800  and/or the mobile computer device  1850 . Computing device  1800  is intended to represent various forms of digital computers, including, e.g., laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Computing device  1850  is intended to represent various forms of mobile devices, including, e.g., personal digital assistants, tablet computing devices, cellular telephones, smartphones, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the techniques described and/or claimed in this document. 
     Computing device  1800  includes processor  1802 , memory  1804 , storage device  1806 , high-speed interface  1808  connecting to memory  1804  and high-speed expansion ports  1810 , and low speed interface  1812  connecting to low speed bus  1814  and storage device  1806 . Each of components  1802 ,  1804 ,  1806 ,  1808 ,  1810 , and  1812 , are interconnected using various busses, and can be mounted on a common motherboard or in other manners as appropriate. Processor  1802  can process instructions for execution within computing device  1800 , including instructions stored in memory  1804  or on storage device  1806  to display graphical data for a GUI on an external input/output device, including, e.g., display  1816  coupled to high speed interface  1508 . In other implementations, multiple processors and/or multiple busses can be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices  1800  can be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system). 
     Memory  1804  stores data within computing device  1800 . In one implementation, memory  1804  is a volatile memory unit or units. In another implementation, memory  1804  is a non-volatile memory unit or units. Memory  1804  also can be another form of computer-readable medium (e.g., a magnetic or optical disk. Memory  1804  may be non-transitory.) 
     Storage device  1806  is capable of providing mass storage for computing device  1400 . In one implementation, storage device  1806  can be or contain a computer-readable medium (e.g., a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, such as devices in a storage area network or other configurations.) A computer program product can be tangibly embodied in a data carrier. The computer program product also can contain instructions that, when executed, perform one or more methods (e.g., those described above.) The data carrier is a computer- or machine-readable medium, (e.g., memory  1804 , storage device  1806 , memory on processor  1802 , and the like.) 
     High-speed controller  1808  manages bandwidth-intensive operations for computing device  1800 , while low speed controller  1812  manages lower bandwidth-intensive operations. Such allocation of functions is an example only. In one implementation, high-speed controller  1708  is coupled to memory  1804 , display  1816  (e.g., through a graphics processor or accelerator), and to high-speed expansion ports  1810 , which can accept various expansion cards (not shown). In the implementation, low-speed controller  1812  is coupled to storage device  1806  and low-speed expansion port  1814 . The low-speed expansion port, which can include various communication ports (e.g., USB, Bluetooth®, Ethernet, wireless Ethernet), can be coupled to one or more input/output devices, (e.g., a keyboard, a pointing device, a scanner, or a networking device including a switch or router, e.g., through a network adapter.) 
     Computing device  1800  can be implemented in a number of different forms, as shown in the figure. For example, it can be implemented as standard server  1820 , or multiple times in a group of such servers. It also can be implemented as part of rack server system  1824 . In addition or as an alternative, it can be implemented in a personal computer (e.g., laptop computer  1822 .) In some examples, components from computing device  1800  can be combined with other components in a mobile device (not shown), e.g., device  1850 . Each of such devices can contain one or more of computing device  1800 ,  1850 , and an entire system can be made up of multiple computing devices  1500 ,  1550  communicating with each other. 
     Computing device  1850  includes processor  1852 , memory  1864 , an input/output device (e.g., display  1854 , communication interface  1866 , and transceiver  1868 ) among other components. Device  1850  also can be provided with a storage device, (e.g., a microdrive or other device) to provide additional storage. Each of components  1850 ,  1852 ,  1864 ,  1854 ,  1866 , and  1868 , are interconnected using various buses, and several of the components can be mounted on a common motherboard or in other manners as appropriate. 
     Processor  1852  can execute instructions within computing device  1850 , including instructions stored in memory  1864 . The processor can be implemented as a chipset of chips that include separate and multiple analog and digital processors. The processor can provide, for example, for coordination of the other components of device  1850 , e.g., control of user interfaces, applications run by device  1850 , and wireless communication by device  1850 . 
     Processor  1852  can communicate with a user through control interface  1858  and display interface  1856  coupled to display  1854 . Display  1854  can be, for example, a TFT LCD (Thin-Film-Transistor Liquid Crystal Display) or an OLED (Organic Light Emitting Diode) display, or other appropriate display technology. Display interface  1856  can comprise appropriate circuitry for driving display  1854  to present graphical and other data to a user. Control interface  1858  can receive commands from a user and convert them for submission to processor  1852 . In addition, external interface  1862  can communicate with processor  1842 , so as to enable near area communication of device  1850  with other devices. External interface  1862  can provide, for example, for wired communication in some implementations, or for wireless communication in other implementations, and multiple interfaces also can be used. 
     Memory  1864  stores data within computing device  1850 . Memory  1864  can be implemented as one or more of a computer-readable medium or media, a volatile memory unit or units, or a non-volatile memory unit or units. Expansion memory  1874  also can be provided and connected to device  1850  through expansion interface  1872 , which can include, for example, a SIMM (Single In Line Memory Module) card interface. Such expansion memory  1874  can provide extra storage space for device  1850 , or also can store applications or other data for device  1850 . Specifically, expansion memory  1874  can include instructions to carry out or supplement the processes described above, and can include secure data also. Thus, for example, expansion memory  1874  can be provided as a security module for device  1850 , and can be programmed with instructions that permit secure use of device  1850 . In addition, secure applications can be provided through the SIMM cards, along with additional data, (e.g., placing identifying data on the SIMM card in a non-hackable manner.) 
     The memory can include, for example, flash memory and/or NVRAM memory, as discussed below. In one implementation, a computer program product is tangibly embodied in a data carrier. The computer program product contains instructions that, when executed, perform one or more methods, e.g., those described above. The data carrier is a computer- or machine-readable medium (e.g., memory  1864 , expansion memory  1874 , and/or memory on processor  1852 ), which can be received, for example, over transceiver  1868  or external interface  1862 . 
     Device  1850  can communicate wirelessly through communication interface  1866 , which can include digital signal processing circuitry where necessary. Communication interface  1866  can provide for communications under various modes or protocols (e.g., GSM voice calls, SMS, EMS, or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others.) Such communication can occur, for example, through radio-frequency transceiver  1868 . In addition, short-range communication can occur, e.g., using a Bluetooth®, WiFi, or other such transceiver (not shown). In addition, GPS (Global Positioning System) receiver module  1870  can provide additional navigation- and location-related wireless data to device  1850 , which can be used as appropriate by applications running on device  1850 . Sensors and modules such as cameras, microphones, compasses, accelerators (for orientation sensing), etc. may be included in the device. 
     Device  1850  also can communicate audibly using audio codec  1860 , which can receive spoken data from a user and convert it to usable digital data. Audio codec  1860  can likewise generate audible sound for a user, (e.g., through a speaker in a handset of device  1850 .) Such sound can include sound from voice telephone calls, can include recorded sound (e.g., voice messages, music files, and the like) and also can include sound generated by applications operating on device  1850 . 
     Computing device  1850  can be implemented in a number of different forms, as shown in the figure. For example, it can be implemented as cellular telephone  1880 . It also can be implemented as part of smartphone  1882 , personal digital assistant, or other similar mobile device. 
     Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor. The programmable processor can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device. 
     These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms machine-readable medium and computer-readable medium refer to a computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions. 
     To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a device for displaying data to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor), and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be a form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in a form, including acoustic, speech, or tactile input. 
     The systems and techniques described here can be implemented in a computing system that includes a backend component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a frontend component (e.g., a client computer having a user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or a combination of such back end, middleware, or frontend components. The components of the system can be interconnected by a form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet. 
     The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. 
     In some implementations, the engines described herein can be separated, combined or incorporated into a single or combined engine. The engines depicted in the figures are not intended to limit the systems described here to the software architectures shown in the figures. 
     A number of embodiments have been described. Nevertheless, it will be understood that various modifications can be made without departing from the spirit and scope of the processes and techniques described herein. In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps can be provided, or steps can be eliminated, from the described flows, and other components can be added to, or removed from, the described systems. Accordingly, other embodiments are within the scope of the following claims.