Patent Publication Number: US-2015074522-A1

Title: Font Management for Editing Electronic Documents

Description:
BACKGROUND 
     This description relates to managing the delivery of fonts and related information to imaging devices such as printers, computing devices, etc. 
     In the ever-expanding connectivity provided by computer networks such as the Internet, various types of content such as text, graphics, audio, video, etc. may be included in assets (e.g., documents, presentations, websites, webpages, etc.) for presenting to individuals using a computing device or broadcast to a multitude. Incorporating such content into assets may provide viewers with a more enjoyable viewing experience while assisting with a more efficient transfer of information. However, technology does not always allow such a rapid expansion of different types and dramatic layouts of content to occur without being somewhat constrained. Device functionality, operating systems, driver software, etc. may impede presentation and limit a viewer&#39;s ability to view the originally authored content. 
     SUMMARY 
     The systems and techniques described here relate to identifying appropriate information that is not present at a computing device (e.g., a computer system, smart phone, etc.) for presenting one or more editable electronic documents (e.g., an Adobe .pdf file, a Photoshop PSD, an MS-Word document etc.). For example, one or more fonts may not be available at the computing device and are identified as being needed to present (e.g., render) an electronic document or documents as originally intended. Once identified, the needed font information is provided in response to a request sent from the device absent user input, in response to a copy of the electronic being provided, etc. By providing such font information in a seamless manner, the viewer is not distracted or frustrated by having to assist with the computing device being delivered appropriate font information. Further, by not being distracted by the process, the viewer&#39;s experience may be improved along with the viewer&#39;s interest in the content being presented. 
     In one aspect, a computing device implemented method includes receiving a request indicating that the computing device is unable to present textual content of an editable electronic document. The request includes one or more attributes of the textual content of the editable electronic document. The method also includes identifying appropriate font information for the computing device to present the textual content of the editable electronic document from the one or more attributes. The method also includes providing the identified font information to the computing device for presenting the editable electronic document. 
     Implementations may include one or more of the following features. The one or more attributes may be provided by a copy of the editable electronic document included with the request. The one or more attributes may identify one or more fonts absent at the computing device. Receiving the request may be triggered by the computing device attempting to access the editable electronic document. Receiving the request may be triggered by attempting to access the editable electronic document remote from the computing device. Receiving the request may be triggered by scanning the editable electronic document in an autonomous manner at the computing device or remote from the computing device. Receiving the request may be triggered by a user selection. The one or more attributes of the textual content of the editable electronic document may identify one or more fonts used by the electronic document. The one or more attributes of the textual content may identify one or more characters present in the editable electronic document. Identifying the appropriate font information may include scanning the editable electronic document to identify fonts included in the electronic document. The scanning of the electronic document may be executed by the computing device. The scanning of the electronic document may be performed by an agent executed by the computing device. The scanning of the electronic document may be executed at a font service provider. Providing the identified font information to the computing device may include sending the editable electronic document and the identified font information to the computing device. 
     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 request indicating that the computing device is unable to present textual content of an editable electronic document. The request includes one or more attributes of the textual content of the editable electronic document. Operations also include identifying appropriate font information for the computing device to present the textual content of the editable electronic document from the one or more attributes. Operations also include providing the identified font information to the computing device for presenting the editable electronic document. 
     Implementations may include one or more of the following features. The one or more attributes may be provided by a copy of the editable electronic document included with the request. The one or more attributes may identify one or more fonts absent at the computing device. Receiving the request may be triggered by the computing device attempting to access the editable electronic document. Receiving the request may be triggered by attempting to access the editable electronic document remote from the computing device. Receiving the request may be triggered by scanning the editable electronic document in an autonomous manner at the computing device or remote from the computing device. Receiving the request may be triggered by a user selection. The one or more attributes of the textual content of the editable electronic document may identify one or more fonts used by the electronic document. The one or more attributes of the textual content may identify one or more characters present in the editable electronic document. Identifying the appropriate font information may include scanning the editable electronic document to identify fonts included in the electronic document. The scanning of the electronic document may be executed by the computing device. The scanning of the electronic document may be performed by an agent executed by the computing device. The scanning of the electronic document may be executed at a font service provider. Providing the identified font information to the computing device may include sending the editable electronic document and the identified font information to the computing device. 
     In another aspect, one or more computer readable media storing instructions that are executable by a processing device, and upon such execution cause the processing device to perform operations that include receiving a request indicating that the computing device is unable to present textual content of an editable electronic document. The request includes one or more attributes of the textual content of the editable electronic document. Operations also include identifying appropriate font information for the computing device to present the textual content of the editable electronic document from the one or more attributes. Operations also include providing the identified font information to the computing device for presenting the editable electronic document. 
     Implementations may include one or more of the following features. The one or more attributes may be provided by a copy of the editable electronic document included with the request. The one or more attributes may identify one or more fonts absent at the computing device. Receiving the request may be triggered by the computing device attempting to access the editable electronic document. Receiving the request may be triggered by attempting to access the editable electronic document remote from the computing device. Receiving the request may be triggered by scanning the editable electronic document in an autonomous manner at the computing device or remote from the computing device. Receiving the request may be triggered by a user selection. The one or more attributes of the textual content of the editable electronic document may identify one or more fonts used by the electronic document. The one or more attributes of the textual content may identify one or more characters present in the editable electronic document. Identifying the appropriate font information may include scanning the editable electronic document to identify fonts included in the electronic document. The scanning of the electronic document may be executed by the computing device. The scanning of the electronic document may be performed by an agent executed by the computing device. The scanning of the electronic document may be executed at a font service provider. Providing the identified font information to the computing device may include sending the editable electronic document and the identified font information to the computing device. 
     These and other aspects and features and various combinations of them may be expressed as methods, apparatus, systems, and means for performing functions, program products, and in other ways. 
     Other features and advantages will be apparent from the description and the claims. 
    
    
     
       DESCRIPTION OF DRAWINGS 
         FIG. 1  illustrates exemplary content that may be provided to imaging devices for presentation. 
         FIG. 2  is a block diagram of an Internet based computer network. 
         FIGS. 3 and 4  illustrate imaging devices sending information to a font service provider for font management. 
         FIG. 5  illustrates requesting and delivering a software agent and font information from a font service provider. 
         FIG. 6  is an exemplary file for producing a web asset. 
         FIGS. 7 ,  8  and  9  illustrate examples of code instructions. 
         FIG. 10  is an example flow chart of operations of a font service manager. 
         FIG. 11  is an example flow chart of operations of a software agent. 
         FIG. 12  illustrates requesting and delivering a software agent and font information from a font service provider. 
         FIG. 13  illustrates providing an electronic document to a font service provider for identifying font information. 
         FIGS. 14-17  illustrate graphical interfaces for user interactions with a font service provider. 
         FIG. 18  is an example flow chart of operations of a font service manager. 
         FIG. 19  is a block diagram showing an example of a system for providing hosted storage and accessing the hosted storage from a client device. 
         FIG. 20  illustrates an example of a computing device and a mobile computing device that can be used to implement the techniques described here. 
     
    
    
     DETAILED DESCRIPTION 
     Referring to  FIG. 1 , various types of assets may be produced for presentation. For example, assets such as documents, presentations, etc. may be produced locally or remotely by a computing device (e.g., a computer system, smart telephone, etc.), or, assets such as a web asset (e.g., a webpage  100 ) may also be remotely produced and may be accessible through the Internet (or other type of computer network). Such web assets (e.g., a web page, website, etc.) like webpage  100  may be accessed by providing appropriate identifying information (e.g., a uniform resource locator (URL)) to a web browser or other type of asset presenter. For example, once accessed, the web asset may be packaged and sent from a corresponding asset provider to an imaging device (e.g., a computing device, printer, etc.) for presentation. In the illustrated example, the content of the webpage  100  is a birthday party invitation that includes text and graphics and may be accessed from a particular URL (i.e., www.invite.com). To provide an eye-catching invitation, multiple fonts are used that provide different typefaces, each of which can be considered as providing stylistic characters or glyphs. In general, for presenting such text and similar graphics, various types of font families (e.g., Times New Roman, Arial, etc.) may be used that typically include a set of fonts, e.g., regular, italic, bold, bold italic, etc. Each font generally includes a set of individual character shapes called glyphs and the glyphs generally share various design features (e.g., geometry, stroke thickness, serifs, size, etc.) associated with the font. One or more techniques may be utilized for representing such fonts; for example, outline-based representations may be adopted in which lines and curves are used to define the borders of glyphs. Such fonts may be scalable for a variety of sizes (e.g., for presenting by various imaging devices) and may be represented in one or more formats. For example, scalable outline fonts may be represented in a format that includes data structures capable of supporting a variety of typographic visual symbols of many languages. 
     Once produced, assets (e.g., electronic documents, presentations, etc.) may be provided to imaging devices for presentation. For example, one or more electronic documents (e.g., an MS-Word document, MS-PowerPoint presentation, MS-Excel file, a portable document format (PDF) file, an Adobe Photoshop file (a .PSD file), etc.) may be provided (e.g., directly sent from a local computing device, sent remotely using one or more protocols such as electronic mail protocols, etc.) to an imaging device (e.g., a printer) or produced at the device (e.g., a PDF file created by a computing device). Produced assets may also be accessed from remote. For example, once accessed, a content provider may use one or more techniques to provide the content of the webpage  100  to an imaging device. In this arrangement, the webpage  100  may be represented in one or more asset files  102  that may employ one or more techniques. For example, the asset files  102  may include a hypertext markup language (HTML) file that includes instructions for presenting the asset and a cascading style sheet (CSS) file that provides presentation semantics for the asset being presented by the HTML file. Standards such as the World Wide Web Consortium (W3C) standards for HTML, CSS, XML and other standards may be implemented so the webpage  100  can be properly rendered on various types of imaging devices capable of displaying electronic content (e.g. computer systems, tablet computing device, smart phones, personal digital assistants (PDAs), handheld computers, set-top boxes, heads up display (HUD), Internet appliances, etc.). Along using with displaying electronic content, other types of imaging devices may be used for content presentation. For example, printers (e.g., for hard copy presentations) and other types of devices may be used for presenting the content of the webpage  100 . 
     Along with providing graphics (e.g., a graphic of a birthday cake in this instance), the one or more asset files may reference one or more fonts used to render text on the webpage. For illustration, five different fonts are used in the webpage  100  to provide information associated with the invitation (e.g., time, date, location, event description, and menu). As such, the asset file(s)  102  calls out each font such that the recipient imaging device is aware which font corresponds to each portion of textual information (e.g., present the date in a “Times New Roman” font). Upon receiving and executing the instructions included in the asset file(s)  102 , the recipient imaging device may locally retrieve the fonts needed to present the text. However, considerable numbers of imaging devices (e.g., printers, computer systems, etc.) may be unable to locally store all the characters of each font that could be needed to render the webpage. Limited resources (e.g., memory) and the constant creation of new font types can limit each type of imaging device from being ready to display text in any and all fonts. Fonts associated with different languages amplify the issue that many imaging devices may be unable to provide all font types. Languages such as Chinese, Japanese, Korean, etc. use alphabets of characters that may number in the tens of thousands (e.g., over 10,000 characters) and call for 1 MB to 20 MB of memory to store the characters of a single language. Such memory needs are impractical, especially for imaging devices with less robust onboard memory (e.g., printers, cellular telephones, etc.). From some devices, font substitution techniques may be employed for presenting content. For example, a device may substitute the nearest equivalent font (based upon appearance, one or more rules, etc.) for a font included in an asset but not residing at the device. 
     Following the logic of having every potential font type locally stored at an imaging device; storing complete character sets for even a few fonts may be inefficient if only a few characters are needed from a set (e.g., to present a particular webpage or other type of asset). Referring to the illustrated example, a relatively small number of “Times New Roman” font characters are needed to present the event date (e.g., “A”, “p”, “r”, “i”, “1”, “2”, “0”, “t” and “h”) and storing the complete font character set may be considered an unwise use of memory of an imaging device, certainly if a complete character set is stored for each possible user language (e.g., English, Chinese, Japanese, etc.). Further, the time needed for transferring fonts along with bandwidth consumption may also introduce concern. For example, transferring complete character sets of fonts associated with languages such as Chinese, Japanese and Korean may need considerable bandwidth and transfer time. 
     To conserve the use of local memory, some conventional techniques provide complete font sets with the received asset (e.g., an HTML file) or initiate the retrieval of the complete character sets of needed fonts upon receipt of the file associated with the webpage. However, such techniques may still cause computing device memory to be filled with collections of font characters when only a few characters are actually being used by the webpage. For example, as illustrated in the figure, to present the webpage  100  with an imaging device, complete font character sets  104 ,  106 ,  108 ,  110 ,  112  are provided along with the asset file(s)  102 . As such, each possible character of the five fonts used by the webpage  100  is provided to the imaging device, thereby consuming a considerable amount of memory of the imaging device. While some devices may have the capacity to store and process the complete font sets, other devices may simply not have the memory. For example, provided all of this data, a tablet computing device  114  may or may not have the memory or processing power to present the webpage  100 . 
     In some situations font sets may not be provided with asset files and the device may use locally residing fonts to present the asset. For example, provided the asset file(s)  102 , a printer  116  may substitute for any font identified in the asset file(s) that is not present in the printer. By substituting each non-present font with the closest matching font, the printer may attempt to present the asset. However, while similar information may be presented the overall look and style of the asset may be sacrificed. In this particular example, the printer  116  produces a printout  118  of the asset that includes local font characters (stored on the printer) substituted for the originally selected fonts in the webpage  100 . In this instance the printout used that same substitute font (Times New Roman) for each of line of text presented in the printout  118 . As such, the printout  118  is absent the overall look and style of the original web page  100 . 
     One or more techniques may be implemented to provide appropriate font information that may be absent from an imaging device. For example, based upon the asset delivered a determination could be executed that identities the particular font or fonts that are needed to present the asset and which of the font or fonts is absent from the imaging device. To identify the absent font(s), attributes of the missing font(s) may be identified and used to attain the appropriate font information and providing the information to the imaging device. Such attributes could include the name of the font, one or more metrics associated with the missing font(s) (e.g., footprint on page, height, width, etc.). Information associated with the asset may also be used for identifying the missing font(s), for example, typographical information of the asset (e.g., number of lines in the document, spacing, number of paragraphs in the web page, page breaks, number of characters per line, etc.) could be used for font identification. Device information such as device type and model, functionality and capacity of the device, software executed by the device (e.g., operating system, web browser, etc.) may be used for font identification. 
     Environmental attributes may also be used for font identification. For example, one or more techniques may be used to reduce the file transfer time, bandwidth consumption and needed memory space for preparing to present assets such as webpage  100 . For example, rather than providing complete character sets for each font, font subsets may be provided that include only the characters that appear in the asset (e.g., the webpage  100 ). As such, file transfer time and bandwidth needs may be reduced and device memory is conserved while an appropriate set of font characters is provided for asset presentation. Referring to the illustrated example, each of the font character sets  104 - 112  may be replaced with significantly smaller font subsets that can be provided with the asset file(s)  102  or relatively soon after receipt of the file. Similar to reducing transfer time and bandwidth needs based on font subsets for the stylistic appearance of characters, reductions may also be achieved for providing font subsets associated with different languages. For example, if a webpage contains only three hundred Chinese characters, it may be more efficient to provide a font subset that is restricted to only include the three hundred characters, which may reduce the size of the transferred font data from approximately 10 MB to 50 KB. In some situations while subsets may be produced for some font character sets (e.g., the Chinese language character set), other font character sets may be sent as complete sets. For example, due to the relatively small number of characters included in a complete font set (e.g., the Latin language character set), creating and transferring a subset may not significantly reduce the bandwidth or time needed to transfer the entire character set. Along with reducing the size of font character sets provided to a computing device to present a webpage or other types of asset, one or more techniques may be implemented to efficiently provide such font subsets to imaging devices (e.g., the tablet computing device  114 , the printer  116 , etc.). For example, along with presenting the webpage, the user&#39;s computing device may be used for identifying the appropriate font subsets and subsequently request the identified subsets. 
     Other attributes that may assist in font identification may include information associated with the source of the asset to be presented, information regarding the delivery recipient of the asset (e.g., business that operates the imaging device), etc. For example, the geographical region in which the asset source, recipient, etc. is located may assist in identifying one or more fonts that may be needed for presenting the asset. The business and business relationship of the source, recipient, etc. may also be attributes that factor into the fonts used by one or more of the entities. For example, particular fonts may be used more or less frequently in communications among the asset sources, recipients, etc. Such information may assist with identifying one or more fonts being absent at an asset delivery site or device (e.g., the printer  116 ). By using such attributes for font identification, little if any user input is needed for font identification. For example, operations may be executed absent input from the user of the recipient device (e.g., the user of the tablet device  114 , the printer  116 , etc.). As such, an end user may not be distracted, frustrated, etc. by requests for input to assist with font identification. Further, absent the need for user input, font identification operations may occur in a seamless manner and more efficiently execute to identify the fonts missing at the device. 
     Referring to  FIG. 2 , a computing environment  200  includes a computer system  202  that a user may interact with (e.g., using a keyboard or pointing device such as a mouse) to identify a target web asset (e.g., a webpage) to be presented by the computer system. For example, a web browser  204  or similar software application may be executed by the computer system  202  for the user to target one or more webpages. Upon being identified, operations of the web browser  204  may include requesting, via the Internet  206 , content from one or more web asset sources  208   a,b,c  for the target webpage(s). As illustrated, in this particular example a webpage page is requested from webpage source  208   a  and a corresponding asset file(s)  210  (e.g., an HTML file, a CSS file, etc.) is sent from the source through the Internet  206  to the computer system  202 . In one arrangement, the web asset files  210  include a hypertext markup language (HTML) file that includes instructions for presenting the asset and a cascading style sheet (CSS) file that provides presentation semantics for the asset being provided by the HTML file. 
     Once the asset file(s)  210  have been received, one or more techniques may be implemented to determine if one or more fonts used by the asset is missing from the computer system  202 . For example, operations may be executed by the computer system  202  to scan one or more of the asset file(s)  210  (e.g., a HTML file, a CSS file, etc.) to identify the individual fonts, font characters, etc. included in the webpage as defined by the file(s). In one arrangement, the computer system  202  may execute a software agent  212  to identify the individual fonts, font characters, etc. and to determine if one or more of these fonts, font characters, etc. is absent from the computer system  202  (e.g., not residing in memory, a local storage device, etc.). If font information (e.g., one or more fonts, font characters, etc.) is determined to be absent, one or more operations (e.g., gather information for identifying the absent font(s), etc.) may be executed by the software agent alone or in concert with the computer system  202  (and potentially other computing devices). For example, the software agent may initiate a request being sent to attain the appropriate font information be provided for presenting the asset (e.g., the target webpage). Such agents can be considered as a software module that is executable in a substantially autonomous manner. For example, upon delivered to the computer system  202 , a software agent may operate without considerable user interaction. By operating in a somewhat flexible manner, the software agent can adaptively identify fonts, font characters, etc. needed for presenting an asset such as a webpage. In this particular example, the software agent  212  scans the content of the asset file(s)  210  (e.g., a HTML file, a CSS file, etc.) in a somewhat persistent manner for identifying the fonts, font characters, etc. called out by the file(s). For example, the software agent may execute in a substantially continuous manner. In some arrangements the software agent is provided to the user computing device (e.g., computer system  202 ) very shortly after the delivery of the asset file(s)  210 . As such, web assets such as webpages, application pages, user interfaces, and the like may be perceived as being scanned nearly in real time as the documents are received. 
     In some arrangements, operations of the software agent  212  may be initiated by one or more conditions being satisfied, one or more events occurring, etc. For example, the software agent  212  may not use the contents of the asset file(s)  210  until appropriately signaled that one or more events have occurred. In one arrangement, applications such as a text-to-speech application may process the contents of the asset file(s)  210  prior to being used by the software agent  212 . For example, once textual content of the web asset file(s)  210  (e.g., an HTML file) has been read by the text-to-speech application (e.g., for conversion to audible speech), one or more signals may be sent (or other type of signaling technique employed) to notify the software agent  212  that the web asset files(s)  210  may be accessed and used. 
     The computing environment  200  also includes a font service provider  214  that receives the missing font information from the computer system  202  (e.g., from operations of the software agent  212 ) and determines the appropriate font information (e.g., missing fonts, font characters, font subsets, etc.) needed for delivery to the computer system for presenting the target asset. In some arrangements, the font service provider may create new fonts to address the needs of the requesting imaging device (e.g., the computer system  202 ). Once produced, the font information (e.g., illustrated as font file  216 ) is prepared and sent by the font service provider  214  to the requesting imaging device (e.g., the computer system  202 ). In some arrangements, the information may be directed to other imaging devices (e.g., one or more other computer systems, printers, etc.) in need of the font information. Along with identifying appropriate fonts based on the information included in the request from the software agent  212 , the font service provider  214  may execute other operations. For example, the font service provider  214  may determine to produce one or more font subsets based upon the information from the software agent  212 . Additionally, the font service provider  214  may be capable of determining if complete font character sets should be provided to the requesting computing device. For example, predefined rules may be used by the font service provider  214  in determining whether a font subset should be sent. One such rule may indicate that font character sets associated with particular languages (e.g., Chinese) should have subsets created due to the large size of the complete character set. Subset determinations may also be provided in a dynamic manner. For example, based upon achievable file transfer rates, a file size threshold (e.g., 2 MB) may be determined such that subsets are produced for character sets larger than the threshold. If a font character set size falls below the threshold, the entire character set may be sent as the file transfer rate may be considered within an efficient range. Such thresholds may be dynamically adjusted, for example, by monitoring the achievable transfer rates, the threshold may be changed. For example, as the level of achievable transfer rates decreases, the threshold for creating subsets for character sets may correspondingly be decreased (e.g., lowered from 2 MB to 1 MB). One or more attributes may account for determining the transfer rates as being within an efficient range. For example, geographic location of the user computing device (e.g., as provide by the request) and the font service provider may factor into whether a subset should be produced and sent in place of a complete character set. If both the font service provider and the imaging device are located relatively nearby (e.g., both in the eastern United States), relatively high transfer rates may be achievable and the entire character set may be sent. For a situation in which the imaging device is remote from the font service provider (e.g., one in the United States and the other in India), the font service provider may determine to subset the font character set to be sent. Similar to location based determinations, time of day, season of year and other temporal factors may be used by the font service provider to determine if subsets need to be produced for one or more font character sets identified for transmission. Similar to being used for font subset determinations, such information may also be used by the font service provider  214  for other determinations such as identifying other types of font information (e.g., missing fonts, etc.) to be provided by the font service provider  214  to one or more imaging devices (e.g., the computer system  202  that requested the information). 
     In some arrangements, the font service provider  214  may also provide the software agents to the computing devices in order to perform operations such as scanning received files (e.g., the asset file(s)  210 ) for identifying fonts characters, etc. not locally present along with identifying other information (e.g., the type of browser being executed, computing device being used, etc.). As such, the font service provider  214  may operate independent of the webpage sources  208   a,b,c.  Once a request is received from a user computing device, the font provider  214  may provide appropriate agent software to the requesting device for gathering information to identify any missing fonts, font characters, etc. and provide the information to the font service provider  214  for taking corrective action (e.g., providing font information such as the missing fonts, appropriately subset fonts for delivery to the user computing device, etc.). Agents provided by the font service provider may also provide other functions; for example, the agents may direct the deletion of provided fonts, font subsets, based on one or more conditions (e.g., expired license term, expired period of time, etc.). 
     Along with the information provided by the computer system  202  (e.g., via the software agent  212 ), to provide font information associated with any missing fonts, characters, etc., the font service provider  214  typically needs access to one or more libraries of fonts that may be stored locally or remotely to the font service provider. As represented in the figure, a library of fonts  218  is being stored in a storage device  220  (e.g., one or more hard drives, CD-ROMs, etc.) on site. Being accessible by a server  222 , the font library  218  may be used along with information provided from software agents to produce appropriate font information (e.g., complete font sets, font subsets, etc.). Illustrated as being stored in a single storage device  220 , the font service provider  214  may use numerous storage techniques and devices to retain a collection of accessible sets of fonts (e.g., for different font styles, languages, etc.). The font service provider  214  may also access font information (e.g., font sets) at separate locations for collecting the needed information for the computer system  202  (or other computing devices). For example, upon identifying fonts, font characters, font subsets, etc. needed for addressing one or missing fonts at the computer system  202 , the server  222  may be used to collect needed information from one or more sources external to the font service provider  214  (e.g., via the Internet  206 ). 
     Along with producing font information (e.g., complete font sets, font subsets, etc.) and providing it to requesting imaging devices, the font service provider  214  may provide other functions. For example, fonts and font subsets associated with particular assets (e.g., web assets such as webpages and websites) may be tracked for future requests. In one scenario, one or more font subsets (e.g., included in font file  216 ) may be created for presenting a particular webpage (on a computing device). The association between the font subsets and the webpage may be identified (e.g., by the server  222 ) and stored for later retrieval. As such, the subsets needed to present the webpage in the future (e.g., on another computing device) can be quickly identified and provided to the requesting computing device. In one arrangement, a font database  224  is stored at the font service provider  214  (e.g., on the storage device  220 ) and includes records that represent the association between webpages and font subsets (and fonts). In some instances, the association is identified from information provided by requests sent to the font service provider  214  (e.g., from a software agent). The association between a webpage and appropriate font subsets may also be stored prior to the webpage being selected by a user (e.g., based on directions and information provided by a webpage source). Similarly, the font service provider  214  may perform operations (e.g., track, store, etc.) regarding other types of associations. For example, records may be stored that reflect fonts that are frequently absent from particular imaging devices (e.g., printers, computing devices, etc.) and may need font information (e.g., font sets, font subsets, etc.) to provide corrective action for the imaging device to present one or more assets. Environmental characteristics (e.g., throughput, bandwidth, etc.), device information (e.g., device types, operating system types, etc.), enterprise information (e.g., listing of frequent business communications and type of communications, etc.) may also be stored by the font service provider  214  for determining the font information that may be needed by an imaging device. Other types of architectures and networking techniques may also be implemented for providing software agents and font information (e.g., font sets, subsets, etc.) to imaging devices for presentation of assets such as web assets (e.g., webpages, websites, etc.). 
     In some arrangements, information provided to the font service provider (e.g., for identifying and providing needed fonts, font subsets, etc.) may include attributes associated with characterizing the environment (e.g., a communication link between the font provider  214  and the imaging device). Such information may be used individually or in concert with other information, for example, information gathered from the content of a web asset (e.g., information scanned from the asset file(s)  210  to identify fonts, font characters, etc. included in the web asset). Other provided attributes may include structural attributes of the web asset (e.g., document layout information and metrics such as number of paragraphs included in the asset, page breaks, characters per line present in the asset, etc.). Attributes may also include information associated with the computing device presenting the asset (e.g., type of device, operating system used by the device, application executed by the device, etc.), the location of the device (e.g., geographic location, for example, to assist with identifying the native language of the user), enterprise information (e.g., company that owns the device to determine if font information has been sent to similar company devices, etc.), etc. Along with using multiple types of information (e.g., communication characteristics, web asset content, geographic location, etc.), previously stored information may be used for determining the appropriate font information (e.g., a font subset, a complete font set, etc.) to provide to one or more imaging devices (e.g., the computer system  202 , the tablet computing device  114 , the printer  116 ). For example, information from a data base (e.g., font database  224 ) may be used for such determinations. Other types of previously stored information may also be used, for example, previously collected communication characteristics (e.g., data transfer rates for links), asset attributes (e.g., web page structure), geographical information, enterprise level information, etc. may be used for making the determination. 
     By using information from these various sources individually or in concert, appropriate decisions can be made as to identifying the appropriate font information (e.g., one or more missing fonts, one or more font subsets, etc.), preparing the information and sending it from the font service provider  214  to the computing device (e.g., the computer system  202 ). The attributes used for the determinations can be considered relatively static or dynamic, for example, while the content of a web asset can be relative static, environmental characteristics (e.g., properties of the communication link between the font provider and a client device) may vary with time (e.g., changing data transfer rates over the course of a day) and location (e.g., data transfer rate changes due to moving the client device, a mobile device, to a different location). Due to the variations, one or more techniques may be implemented so relatively current values for dynamic attributes (e.g., communication characteristics) may be used for the determinations. For example, one or more environmental characteristics (e.g., communication link properties, capabilities of a client device) may be monitored and collected for use in such determinations. Various types of data monitoring and collection techniques may be implemented, for example, one or more communication link characteristics may be passively, actively, etc. collected by the imaging device (e.g., computer system  202 ), the font service provider  214  or by operations executed by the user device and font service provider in concert. Equipment separate from the user computing device and the font service provider  214  may also be implemented. Information may also be exchanged between one or more user computing devices, the font service provider  214  and potentially other devices to assist in font determinations (e.g., identifying missing fonts, producing font subsets, etc.), for example, characteristics of a user computing device (e.g., display capabilities, etc.) may be provided to the font service provider  214 . As such, environmental characteristics associated with various equipment, communication links, etc. may be used in making such font determinations. 
     Referring to  FIG. 3 , a diagram  300  represents some potential operations for gathering information for determining the appropriate font information (e.g., complete font set, font subsets, etc.) that should be provided to an imaging device (e.g., the computer system  202 ). In this particular arrangement, one or more attributes (e.g., missing font information, asset structure information, environmental characteristics, etc.) are collected by the imaging device and provided to the font service provider  214  for font determinations. To perform such attribute collections, the imaging device (e.g., the computer system  202 ) may execute one or more operations, for example, one or more characteristics of a communication link  302  may be measured by the computer system  202  and provided to the font service provider  214  for processing. Similarly, contents from an asset (e.g., asset file(s) of a web asset such as a webpage) may be collected to provide to the font service provider  214 . Other types of attributes may also be collected and provided through various implementations. For example, in this arrangement, an environment monitor  304  is executed by the computer system  202  to collect environment characteristic information as attributes. While an imaging device (e.g., the computer system  202 ) is illustrated as collecting such environmental characteristics, such operations may be executed at other locations, individually or in combination with the operations at the imaging device. For example, environmental characteristics (e.g., of the communication link  302 ) may be measured and quantified by the font service provider  214 . In one arrangement, the server  222  may collect information regarding the communication link to assist in determining appropriate font information (e.g., font sets, font subsets) to be sent to the imaging device. 
     Continuing with this example of collecting attributes, various types of information may be collected that is representative of environmental characteristics. For example, some characteristics may reflect the ability of a communication link (e.g., link  302 ) to transfer data among one or more imaging devices (e.g., computer system  202 ) and the font service provider  214 . Such characteristics may be associated with the time, rate, etc. for transferring information. Throughput, bandwidth, transmission rates, etc. of the communication link  302  may be measured and quantified by the environment monitor  304 . Along with the movement of information, establishing communication between devices (e.g., the computer system  202 , the server  222 ) may be monitored for decisions regarding provided font information. For example, connection characteristics (e.g., connection speed, bandwidth, HTTP handshake latency, etc.), overhead time (e.g., time needed to send and process a request for font information, etc.), time needed to establish a data connection between the computer system  202  and the server  214  may be measured (e.g., by the environment monitor  304 ) and provided to the font service provider  214 . Other quantities associated with information transfer over the communication link  302  between one or more imaging devices and the font service provider  214  may be identified. For example, protocols (e.g., an internet protocol (IP)) used by one or more imaging devices (and/or intermediate computing devices) and/or the font service provider  214  may be identified and used for font determinations. Ethernet, DSL, Cable, FIOS are examples of some types of protocols that may be identified. Whether the communication link  302  includes wired or wireless communication technology (e.g., wired, wireless access points, etc.) may also be a factor into the determinations. Device options, selected services, ranges of connectivity options (GPRS/Edge, 3G, 4G, etc.) may also be monitored for changes in link capabilities. For example, anticipated connection speeds may be considered to be relatively fast (e.g., mobile devices connected to 3G or 4G networks), however, actual signal strength and connection speed may still vary over time and adversely affect data transfer capabilities (e.g., web page download time) and user experience. 
     Similar to information associated with the communication link  302 , other types of attributes may be collected and provided to the font service provider  214  for subset determinations. For example, characteristics of one or more imaging devices may be provided. Such characteristics may be associated with display capabilities (e.g., screen specifications such as screen size and resolution, printer type, etc.), processing (e.g., operating system used by the device, type of browser executed by the device) and storage capabilities, etc., of the imaging device (e.g., the computer system  202 , the printer  116 ), which can be provided and used by the font service provider  214  to determine appropriate font information to be sent to the device (e.g., a font set to address a font not present at the device). Such device characteristics may be identified locally at the device (e.g., by the environmental monitor  304 , one or more software agents), remotely (e.g., by the font service provider  214 ), or by a combination of local and remote operations. 
     The environmental monitor  304  may be implemented in one or more arrangements to provide the monitoring functionality at the imaging device (e.g., the computer system  202 ). For example, the environmental monitor  304  may be implemented as one or more agents (e.g., similar to the agent  212  show in  FIG. 2 ) that may be provided to the computer system  202  through one or more methodologies (e.g., downloaded from or provided by the font service provider  214 ). One or more applications (e.g., a web browser) may also implement the environmental monitor  304 . Along with collecting information (e.g., to be provided to the font service provider  214 ), the environmental monitor  304  may provide additional functions such as tracking data and performing statistical analysis on collected data and related information. The collected and processed information may then be provided to the font service provider  214  for assisting in the font decisions and processing (e.g., to optimize font subsetting). 
     To dynamically execute and make such font-based decisions (e.g., to supply missing fonts, produce appropriate font subsets, etc.), one or more techniques may be implemented by the font service provider  214 . In the illustrated example, a font service manager  306  is executed by the server  222  (located at the font service provider  214 ). From the information provided to the font service provider  214  from the imaging device or devices (e.g., a message  308  that contains environment characteristic attributes along with other attributes), the font service manager  306  determines the appropriate font information (e.g., represented by font information file  310 ) should be sent to the imaging device (e.g., the computer system  202 ). In some arrangements the font information (e.g., missing fonts, font subsets, etc.) is prepared and sent based upon delivery of the attribute information (e.g., the message  308  is received by the font service provider  214 ). Previously produced font sets and subsets may also be sent based upon delivery of the attribute information. For example, due to previously experienced conditions, previously provided asset structure attributes, etc. one or more font, font subsets, etc. may be prepared for delivery to one or more imaging devices. Along with being sent, the prepared font information may be stored for delivery at other instances (e.g., when the same asset is targeted for presenting on another imaging device, when similar environmental characteristics are experienced, etc.), thereby increasing efficiency by allowing one or more previously prepared fonts, font subsets, etc. to be reused by the font service provider  214 . 
     In addition to executing font determinations (e.g., identifying and preparing missing font information to an imaging device), the font service manager  306  may also provide other types of functionality. For example, data provided from imaging devices may be further processed and stored (e.g., in the storage device  220 ). In some arrangements, such processing may include developing models (e.g., for predicting environmental characteristics), relational databases (e.g., for different types of imaging devices and previously identified missing fonts), etc. For example, based upon received data (e.g., from imaging devices) representative of one or more characteristics of the communication link  302  (e.g., throughput, bandwidth, etc.) over a period of time, models may be developed for predicting the environment characteristic (e.g., estimates of the throughput for a particular time). Data processing may also include producing (and storing) reports for archiving information such as previously made decisions (e.g., to provide fonts, font subsets, etc.) for various input considerations. For example, for presenting particular content (e.g., a web asset) on a particular imaging device and under certain conditions (e.g., throughput on a communication link), the font service manager  306  may reach a decision of subsetting a particular font (or alternatively, providing a complete character set for the font). By storing information that reflects this decision and the conditions that lead to the decision, future decisions may be expedited if the font service manager  306  recognizes that the conditions have reoccurred. The font service manager  306  may also execute operations for adjusting the fonts, for example, operations for adjusting fonts to improve clarity and the legibility of the produced text (e.g., optimizing font hinting for a particular operating system, font engine, imaging device screen resolution or printing capability, etc.). 
     Referring to  FIG. 4 , a diagram  400  is presented that illustrates that font decisions of the font service provider  214  may depend upon a variety of attributes (e.g., type of imaging device to present an asset, environment characteristics such as location of client device, etc.) that may dynamically change. Similar to  FIG. 3 , decisions are provided by the font service manager  306  executed by the server  222 , e.g., regarding situations such as font sets (from the storage device  220 ) missing from an imaging device (e.g., a printer), whether to provide one or more font subsets to one or more imaging devices, etc. In this particular illustrated example, the location of the imaging device serves as the determining attribute in regards to font subsetting. For example, an environment monitor  401  being executed by a tablet computing device  402  senses that relatively high throughput communication links may be established with the font service provider  214 . A communication link  404  is established and a message  406  is sent to the font service provider  214  to reflect the favorable communication characteristic (along with other attribute information such as the absence of one or more fonts needed to present an asset such as a web page). For example, the tablet computing device  402  may be present at a location that provides for Wi-Fi communications (e.g., through the Internet) with the font service provider  214 . As such, large data files (e.g., containing font sets) can generally be transferred to the tablet computing device  402  in a reasonable amount of time. From this throughput characteristic (and potentially other information), the font service manager  306  decides that complete font sets (e.g., represented by font information file  408 ) may be sent, received and processed by the tablet computing device  402  within a reasonable time period to present the associated web asset content without degrading the viewing experience of a user. 
     In an alternative situation, other environments may lack the ability to provide appropriate throughput levels, and the font service provider  214  may determine that font subsetting is needed (for transferring one or more font sets missing from an imaging device) to provide an appropriate viewing experience. For example, Latin fonts are generally considered as needing relatively small file sizes for storage, and throughput levels in regions where Latin-based languages are spoken are sufficiently large enough to allow complete font sets to be transferred to imaging devices in a reasonable time. Unfortunately, both assumptions (about file sizes and throughput) may not be consistently correct, and for example, a Latin font with an above-average file size delivered over a slow connection may cause significant delays in presenting an asset to a user. Further, environment characteristics may change, in some cases quite dynamically over a period of time, as the imaging device changes location, etc. As such, the environment characteristics may be frequently monitored by the environment monitor  401  and/or the font service manager  306 . For example, the font service provider  214  may request condition updates from the one or more imaging devices (e.g., the tablet computing device  402 ) that have established communications links (e.g., a periodic polling message may be sent from the font provider  214  to request updates). In some arrangements, the imaging devices may manage the condition updates (e.g., the environment monitor  401  sends updates at periodic intervals, based upon events such as power-up, reset, etc.). 
     As illustrated in the figure, a remotely located printer  410  may execute an environment monitor  412  that gathers environmental information such as the reception capabilities of the device due to its current location and status of its network connection (e.g., is experiencing poor throughput) and provides these attributes (potentially with other ones e.g., that reflect limited processing and storage capacity of the device, one or more missing fonts, etc.) in a message  414  to the font service provider  214  (e.g., over a low throughput wireless communication link  416 ). For example the message  414  may include information that identifies one or more fonts used by an asset to be printed but that are not present at the printer  410 . Provided this poor throughput and limited device capabilities attributes, the font service manager  306  may determine that font subsetting is needed to provide font data to the printer  410  such that content of an asset (e.g., an electronic document, web asset, etc.) may be processed and printed in a reasonable time frame and the viewer does not become frustrated that the printout does not represent the asset (e.g., a web page) as originally authored. A need for font subsets may also be determined for efficient operation of the imaging device (e.g., the printer  410 ). For example, font subsets may be provided such that the printer  410  operates in an efficient and substantially continuous manner (e.g., as one page of an electronic document is being printed, a font subset is received and processed by the printer for use in printing one or more subsequent pages). Based on this scenario, one or more font subsets may be produced by the font service provider  214  and sent to the printer  412  (e.g., as illustrated, in a font information file  418  over the communication link  416 ) to provide the needed font information for printing the asset (e.g., an electronic document, web asset, etc.). As such, a reduced amount of information is provided to the printer while still providing enough information to print a representation of the asset as originally created. 
     Along with monitoring environment characteristics (e.g., communication link throughput levels, client device capabilities, etc.) other attributes and information may use the font service provider  214  to determine whether or not fonts should be subsetted prior to delivery to one or more imaging devices. In one arrangement, the content of the asset (to be presented) may be used for assisting in the determination. For example, if a considerable percentage of characters of a font is needed (e.g., 80% of a font&#39;s characters is needed to present the first page of a web asset), sending a complete set of the font&#39;s character to the imaging device could be considered optimum. Content based information may also be associated with the source or sources of a particular asset. Further, in some arrangements source attributes may be used with device capability attributes for assisting in font subsetting determinations. For example, websites may support different content options that are designed to account for inherent capabilities of particular imaging devices such as mobile devices (e.g., screen size, processing power, limited mobile browser functionality, etc.). One instance of such differences is the content and styling of a website (e.g., http://www.yahoo.com) prepared for a more conventional imaging device (e.g., desktop computer system, laptop computer system, etc.) versus a website (e.g., http://m.yahoo.com) designed for a relatively more limited imaging device (e.g., a smartphone). In some arrangements, the environment monitor  401  may be implemented as an agent and can be exploited to determine if the imaging device is of one type (e.g., a PC-based device) or another (e.g., a mobile device device). As such, the imaging devices and their capability attributes can be monitored and used in concert with other environment characteristics (along with other attributes) to dynamically determine whether or not one or more fonts should be subsetted prior to transmission to the client device. 
     Other techniques and methodologies may be implemented for optimizing the delivery of fonts based on the environment attributes (e.g., of the imaging device), asset content and attributes, imaging device attributes, etc. For example, font subsetting may be executed (by the font service provider  214 ) for some portions of an asset and not performed for other asset portions. For example, due to a low throughput communication link, one or more font subsets may be provided to an imaging device for presenting as one portion of an asset (e.g., the first page of a web asset such as a set of webpages). While that portion (e.g., the first page) is being presented (and supposedly reviewed by a viewer), complete font sets and/or font subsets for viewing the other portion (or portions) of the asset (e.g., the remaining pages of a web asset) are prepared and sent to the web asset. Initiating the transfer of the font information for the subsequent portions of the asset may be scheduled for one or more time periods. For example, preparing to send the font information (e.g., font subsets, complete font sets, etc.) may be initiated as the font information is prepared and sent for the initial portion of the asset. In some arrangements, font information for subsequent portions of the asset may be prepared and sent after the font information has been prepared and sent for the initial portion of the asset. As such, font information may be sent from the font service provider  214  in the background as earlier sent font information is readily available for content being presented (e.g., rendered) by the imaging device. Such operations may reduce the time needed to present a first page while enabling full font functionality for the remaining subsequent page views. Other proportioning schemes may also be implemented for font information delivery, for example, frequently used fonts that call for less memory space may be initially sent for use while larger font sets that are less frequently used by a web asset may be sent (e.g., in subsets, complete sets, etc.) afterwards in the background. Similar to other font subsetting arrangements, once a font subset has been produced (e.g., for delivery to an imaging device over a low throughput connection), the subset may be stored (e.g., in the storage device  220 ) for reuse. For example, once produced and stored, a font subset may be reused for other imaging devices regardless of current environment characteristics (e.g., throughput, connection speed, etc.). 
     The font service manager  306  and/or the environment monitors  401 ,  412  may provide other types of functionality. For example, content of a web asset (e.g., a web page) may be monitored (remotely) by the font service manager  306  for changes (e.g., content being added, deleted, adjusted, etc.). When a change is detected in the content, which could be provided from one or multiple sources (e.g., a webpage that includes content from a number of websites), the font service manager  306  may dynamically produce one or more subsets, adjust previously prepared subsets, etc. As such, font subsets and the decision to send one or more subsets to an imaging device may be determined by the font service manager  306  prior to the web asset is requested, thereby reducing response time of the font service provider  214  in making a font or font subset readily available for download when requested. 
     In addition to the environmental attributes (e.g., achievable throughput for transferring font data to an imaging device, bandwidth analysis, statistics representing communication overhead, etc.), attributes regarding content of the asset (e.g., fonts present in a requested webpage, complete font file sizes, etc.) may also be included in determining whether or not to produce and send font subsets to an imaging device. One or more techniques may be utilized for gathering information regarding the requested asset (e.g., a web asset). For example, one or more agents may be executed by an imaging device (after being downloaded from the font service provider  214 ) to attain the information and provide it to the font service provider  214  for analysis with other attributes (e.g., environment characteristics). From this information the font service provider  214  may attempt to optimize processing of font requests with the goal of minimizing font download time and, at the same time, optimizing computational operations (e.g., of the server  222 ) by eliminating unnecessary processing steps, optimizing server response time, etc. 
     Referring to  FIG. 5 , a diagram  500  represents some operations for providing a software agent to an imaging device for gathering and providing attributes to the font service provider  214  such that appropriate fonts, font subsets, etc. are provided for presenting a webpage of other type of web asset or asset. As illustrated in  FIG. 2 , upon a user identifying a web asset (e.g., a webpage) of interest with a web browser executed on a computing device (e.g., providing a URL to the web browser), one or more asset files (e.g., an HTML file, a CSS file, etc.) may be provided to the imaging device from a corresponding webpage source. As illustrated, such a file  502  may include content  504  (e.g., text, graphics, video, audio, etc.) for presenting to the user (via the web browser). The file  502  may also contain one or more instructions  506  for requesting that a software agent be provided to the imaging device. Upon executing the instructions (labeled in the figure “Fetch agent instruction”), delivery of a request  508  may be initiated from the imaging device (e.g., the computer system  202 ) to the font service provider  214  (e.g., server  222 ), as represented by graphical arrow  510 . In response to the request  508 , an agent (e.g., the agent  212 ) is sent from the server  222  of the font service provider  214  to the computer system  202 , as represented by graphical arrow  512 . In some instances the delivery of the agent may occur very soon after the file is received and any delay may go unnoticed by a user. In some arrangements, other information may be provided by the request  508 . For example, the webpage of interest may be identified in the request (e.g., URL of the webpage provided) so that the font service provider  214  may determine if a one or more font, font subsets, etc. have been previously produced for the webpage. 
     Received at the imaging device, the requested agent  212  is executed to scan the content  504  of the HTML file  502  (as represented by a graphical arrow  514 ) to identify characters for each font represented in the content. The agent  212  may also provide the functionality to identify each unique character of each font present. As such, multiple instances of the same font character may only be noted once by the agent, thereby consolidating the characters needed to be requested from the font service provider  214  (for each asset). In some arrangements, the agent  212  notifies the font service provider  214  of each character identified for each font present in the webpage. Upon being provided this information, the font service provider identifies each uniquely occurring character for each font for possible inclusion in a font subset. To provide such scanning operations, one or more techniques may be implemented, for example, the agent may parse the content  504  to identify each character present for each font. One or more filters may then be used (by the agent  212  or the font service provider  214 ) to identify each unique character for each font. For example, if the characters “a”, “B”, and “c” for font A are detected in the content  504  and characters “x”, “Y”, and “Z” for font B are detected, the agent may identify a subset for font A as containing “a”, “B” and “c” while the subset for font B may contain “x”, “Y” and “Z”. Once scanned, identified font characters  516  are used by the agent  212  to produce a font request  518 . In general, the request  518  includes each character identified by the agent  212 ; however, some characters included in the content of the page content  504  may not be included in the request  518 . For example, characters identified as possibly being locally stored at the user computing device may not be included in the request  518 . As such, the agent  212  may exclude some characters included in the page content  504  from the subset request  518 . 
     In some arrangements other information may be provided from the agent  212  to the font provider  214  for assisting with font and font subset determinations. For example, information regarding fonts locally stored on the computer system  202  (e.g., identification of resident fonts, character sets of the fonts, etc.) may be collected by the agent and provided to the font service provider  214 . Once received, the information may be used for one or more procedures such as determining if one or more fonts, font subsets, etc. need to be produced and provided to the computer system  202 , and identifying which fonts, font subsets, etc. to be produced and delivered, etc. The information may also be used for procedures not related to font and font subset determinations, for example, the font service provider may store the information or have the information stored (e.g., provide the information to another facility for storage) for later retrieval and use (e.g., tracking fonts residing at the computer system  202 ). By monitoring the fonts and font information that resides at one or more imaging devices (e.g., computer system  202 , the printer  116 , etc.) and the font information that has been provided to each device (e.g., font subsets delivered), the font provider  214  may reduce redundant data transfers and the duplication of font data, thereby optimizing font information transfers and local storage. For example, one or more font transfer techniques may be utilized as described in “Font Data Streaming”, U.S. patent application Ser. No. 12/457,792 filed on Jun. 22, 2009, the entire contents of which are hereby incorporated by reference. Such techniques may assist with appropriate font information (e.g., font sets, font subsets, etc.) being transferred to an imaging device for efficient asset presentation (e.g., transferring font information such that printer operations execute efficiently and substantially continuous). 
     One or more techniques may be implemented to provide the font request  518  to the server  222  of the font service provider  214 , as represented by graphical arrow  520 . For example, for an agent represented in JavaScript, a technique associated with a protocol such as the hypertext transfer protocol (HTTP) may be used for transferring the request. By appending the identified unique characters to a query string of the URL of interest, a command (e.g., a GET command) can be used to provide the information to the server  222 . Similarly, an agent that is provided as an application may provide the font information to the server  222  of the font service provider  214  with a protocol such as HTTP. Once provided the request  518  for the font(s), font subset(s), etc., the server  222  may use this information with additional information (e.g., environmental attributes and other attributes) to produce the one or more needed fonts, font subsets and reply to the imaging device. For example, as represented with graphical arrow  522 , the font file  216  (that may represent one or more fonts, font subsets, etc.) is provided to the user computing device. 
     Referring to  FIG. 6 , instructions of an exemplary HTML file  600  are illustrated that include requesting an agent (such as the agent  212  shown in  FIG. 2 ) and assigning fonts to particular characters. In this particular example, upon instruction  602  being executed (e.g., by the computer system  202 ), an agent is requested from a font service provider (e.g., the font service provider  214 ). Once received by the computer system  202 , the agent is executed to analyze the contents of the HTML file  600 . For example, the agent may step through each of the remaining lines of the HTML file  600  and identify each character and font used to present the webpage associated with the contents of the file. For example, by analyzing instruction  604 , the agent may identify that characters “A”, “B”, “C” and “D” in “Frutiger” font are needed for webpage production. In this particular arrangement, the individual characters (e.g., “A B C D”) are provided by the instruction  604  along with a URL for accessing the font. Similarly, the executed agent also identifies, in instruction  606 , that the characters “Z” and “W” need to be represented in “Frutiger” font to produce the webpage. As such, when producing a font, font subset, etc. request (e.g., request  518  shown in  FIG. 5 ), the agent identifies each of the unique characters (i.e., “A”, “B”, “C”, “D”, “Z” and “W”) and the corresponding font (i.e., “Frutiger”) needed to produce the webpage. In some arrangements, while scanning the content of the file, the agent may come across characters that are not to be included in a font, font subset, etc. request. For example, the HTML file may include an instance in which locally stored fonts on the computer system (executing the file) are to be used for representing particular characters. As such, fonts do not need to be attained from sources external to the computer system. Instruction  608  of the exemplary HTML file  600  illustrates such an occurrence. In this instance, the characters “M”, “P” and “Q” are called out by the instruction  608  without a URL for a particular font. As such, fonts local to the computer system executing the file  600  may be used to present the characters “M”, “P” and “Q”. Since a font or font subset is not needed for these particular characters, the agent does not include these characters in the request  518 . However, while these characters are stored locally for this particular font, one or more of these characters may be included in the request for another font based upon another instruction (not shown) in the file  600  that calls out “M”, “P” and/or “Q” as being needed in a font attained from a source external to the computer system. 
     Referring to  FIG. 7 , one or more techniques may be implemented to analyze the content of a file such as the HTML file  600  (illustrated in  FIG. 6 ) to identify characters for fonts, font subsets, etc. For a JavaScript based agent, a browser independent library (e.g., Prototype, jQuery, etc. that emphasizes interactions between JavaScript and HTML), may be used to analyze text content. To provide this functionality, a Prototype, jQuery, etc. framework may be used to provide an agent for extracting unique characters from a string. The framework may also include an associative array (e.g., referred to as a JSON in some instances) for forming associations between the identified unique characters and a corresponding font. Stepping through the file in an iterative manner, the unique characters are identified and stored (e.g., cached) for further processing. The portion of code  700  presented in the figure can provide this functionality. 
     Referring to  FIG. 8 , upon identifying the unique characters, one or more techniques may be implemented to group the identified characters accordingly based upon font. For example, each unique character (e.g., “A”, “B”, “C”, “D”, “Z” and “W”) identified for a particular font (e.g., “Frutiger”) is a member of a group for that font. Additionally, for fonts that have relatively few members (e.g., a font associated with the Latin language), a group of unique characters may not be formed. For such fonts that include relatively fewer members, the entire font set may be sent without consuming considerable computational resources such as transfer time and bandwidth (e.g., as determined in concert with environment attributes). As such, the complete font set may be provided (e.g., from the font service provider) for producing characters of that font. The portion of code  800  presented in the figure can provide this functionality. 
     Referring to  FIG. 9 , once the identified unique characters for each font have been grouped (along with any identified fonts that have relatively small character sets), the agent provides this information to the font service provider  214  (e.g., to the server  222  of the font provider). One or more techniques may be used to provide this information. For example, a command such as the HTTP GET command may be used to append identified characters and corresponding fonts to a URL query string. Upon receiving a request (provided by the HTTP GET command), the font service provider  214  (e.g., the server  222  of the font provider) creates and sends one or more appropriate fonts, font subsets, etc. to the requesting imaging device. In some arrangements, complete font sets may also be sent for identified fonts that include relatively few characters, based upon predefined rules associated with one or more attributes (e.g., geographic location of user and/or font service provider, data transfer attributes such as achievable transfer rate, etc.). To provide the identified unique characters and corresponding fonts, a portion of code  900  is presented in the figure that can provide this functionality. 
     Referring to  FIG. 10 , a flowchart  1000  represents operations of a font service manager (e.g., the font service manager  306  shown in  FIG. 3 ). Operations of the font service manager  306  are typically executed by a single computing device (e.g., the server  222 ); however, operations of the font service manager may be executed by multiple computing devices. Along with being executed at a single site (e.g., the font service provider  214 ), execution of operation may be distributed among two or more locations. 
     Operations of the font service manager may include receiving  1002  a request from an imaging device indicating that the imaging device is unable to present textual content of an asset. The request includes one or more attributes of the textual content of the asset and the request is sent from the imaging device absent user input. For example, attributes associated with the asset (e.g., fonts included in asset such as a webpage, number of paragraphs, characters per line, etc.), attributes of the imaging device (e.g., fonts present in the memory of the device, identification information of the imaging device, display resolution, screen size, web browser being executed by the device, etc.), environmental attributes that may represent quantities (e.g., throughput, connection establishment time, bandwidth, etc.) of a communication link between the imaging device (e.g., a tablet computing device, a smartphone, printer, etc.) and equipment of a font service provider (e.g., the server  222 ). Operations of the font service manager may also include identifying  1004  an appropriate amount of font information from the received one or more attributes from the imaging device to present the asset. For example, based on the provided attributes, the font service subset manager can determine which fonts need to be provided to the imaging device. Additionally, the font service manager can determine whether or not to subset one of more of the fonts (used by the web asset) for efficient transfer of the fonts from the font service provider to the imaging device. Along with using the received attributes, other information such as previously stored attributed and other information (at the font service provider) may be used in making the determination. Operations of the font service manager may also include providing  1006  the identified font information to the imaging device for presenting the asset. For example, if determined that one or more fonts, font subsets, etc. are needed to provide the appropriate font characters for presenting the content of the asset, the font service manager may initiate the preparation and transfer of this font information to the imaging device. 
     Referring to  FIG. 11 , a flowchart  1100  represents operations of a software agent (e.g., the agent  212  shown in  FIG. 2 ). As mentioned, operations of the software agent  212  are typically executed by a single computing device (e.g., the computer system  202 ); however, operations of the software agent may be executed by multiple computing devices. Along with being executed at a single site (e.g., the location of an imaging device), operation execution may be distributed among two or more locations. 
     Operations of the software agent may include receiving  1102  at an imaging device data representing textual content of one or more assets. For example, the software agent may receive data that represents various types of asset and web assets (e.g., websites, webpages, etc.) from one or more sources (e.g., website sources, repositories, etc.). Operations of the software agent may also include parsing  1104  the data representing the textual content to determine if font information is absent at the imaging device for presenting the textual content of the one or more assets. For example, the agent may identify fonts, characters, etc. present in the content of the asset and check local memory, listing, etc. that reside at the imaging device to determine if one or more of the identified fonts is absent at the device (e.g., not present in the memory of the device). Operations also include sending  1106  a request to a font service provider for requesting the absent font information for presenting the one or more assets. The request is sent to the font service provider absent user input. For example, the software agent may initiate the creating of a request that includes the identified fonts that are used by the asset but are absent at the imaging device. Once created, the request can be sent to the font service provider for taking corrective action (e.g., sending data that represents the absent fonts). Corrective actions may also include determining if one or more font subsets would be appropriate based on the content of the asset and sending such subsets to the imaging device for efficient presentation of the asset of interest. 
     Referring to  FIG. 12 , font information needed for presenting other types of assets (e.g., fonts not present at a computing device) may be provided by one or more techniques and methodologies. For example, assets such as editable electronic documents (e.g., MS-Word documents, MS-PowerPoint presentations, MS-Excel files, PDF files, Photoshop PSD files, etc.) may be produced, edited, etc. by a computing device as illustrated in a diagram  1200 . In this example, a computing device  1202  may produce an editable electronic document  1204 , which utilizes one or more fonts, by executing an application  1206  (e.g., a word processor, graphics or photo editor, spreadsheet manager, etc.). Being editable, the content (e.g., text) of the electronic document  1204  may be altered (e.g., changed, appended, deleted, etc.) for presentation, storage, transfer, etc. Similar to other types of assets described above, the fonts used by such editable electronic documents may or may not reside at the computing device that may attempt to access and present the document (e.g., for additional editing). For example, the editable electronic document  1204  may be produced by another computing device (not shown) prior to being provided to the computing device  1202 . When accessed for presentation (and potentially further processing such as editing), appropriate fonts may not be present at the computing device  1202  and textual content of the document may not be accurately rendered (e.g., fonts resident at the computing device  1202  may be used to substitute for missing fonts). As such, a viewer may not be presented the content of the document as originally intended by its author. However, by taking appropriate corrective steps, the missing font information may be attained and used to present the editable document as originally intended. 
     One or more techniques may be implemented for detecting one or more fonts that are used by the editable electronic document  1204  but which are not present at the computing device  1202 . For example, a software agent may be used to scan the electronic document  1204  for textual content to identify missing fonts, characters, etc. not present at the computing device  1202 . Similar to other agents, the software agent can be considered as a software module that may be executed in a substantially autonomous manner (e.g., operate without considerable user interaction). By flexibly operating, the software agent can adaptively identify attributes of editable electronic documents (e.g., fonts, font characters, etc.) needed for presenting the documents. If the software agent is already residing at the computing device  1202 , the agent can be executed to scan the electronic document to determine one or more fonts, characters, etc. that may not be resident at the computing device  1202 . For situations in which the software agent does not reside at the computing device, one or more techniques may be employed for providing such an agent to the computing device. For example, a software agent may be requested from one or more possible sources (e.g., one or more computing devices). As illustrated in the figure, an agent request  1208  is sent from the computing device  1202  to a font service provider  1210 , which in turn provides a software agent  1212  from a server  1214  present at the font service provider. As represented by a graphical arrow  1216 , one or more techniques may be implemented to send the request  1208  to the font service provider  1210 . For example, one or more signals, messages, etc. or other techniques may be used to send the agent request  1208  to the font service provider  1210 . Similarly, as represented by a graphical arrow  1218  one or more techniques (e.g., messages, file transfer protocols, etc.) may be used for sending the agent  1212  from the font service provider  1210  to the computing device  1202  for use (e.g., being executed for scanning the editable electronic document  1204 ). 
     Once received by the computing device, the requested agent  1212  is executed to scan the content of the electronic document  1202  (as represented by a graphical arrow  1220 ) to identify attributes (e.g., fonts, characters for each font, etc.) represented in the content. In some arrangements, the operations executed by the agent  1212  may depend upon the type of electronic document being scanned. For one type of file (e.g., a Photoshop™ PSD file), the file may be scanned at a binary level (e.g., binary parsing of the file) to identify layers of the file. One or more layers may be identified as being associated with font information. For example, a tag (e.g., TySh tag) may be found for each layer and each tag may be searched for another tag (e.g., a “FontSet” key tag) that identifies one or more fonts and potentially other font information. Once identified, the fonts may be reviewed to determine which are currently residing in the application, computing device, etc. and which need to be attained. For another type of file (e.g., a PDF file), a library such as an open source library (e.g., iText, iTextSharp, etc.) may be utilized. One or more functions, methods, etc. (e.g., “BaseFont.GetDocumentFont(string filename)”) from the library may be used to identify the fonts (e.g., FontFamilies names) used by the file (e.g., a PDF file). Other types of libraries (e.g., Aspose libraries) may be used for parsing some type of files (e.g., MS-Word documents, MS-PowerPoint presentations, etc.) to identify fonts utilized by the file along with other types of font information. 
     The agent  1212  may also provide other functionality for assisting with identifying the fonts, characters, etc. included in the electronic document. For example, the agent  1212  may be capable of determining information associated with the application  1206 . In some arrangements, information such as application type, version (e.g., bit version of application), capabilities, etc. may be identified by the agent and used to request the font information needed to present the electronic document. Upon identifying the font attributes (e.g., fonts, characters, etc.) present in the electronic document, the executed software agent may identify which font information is absent from the computing device and hindering presentation of the document. For example, the agent may identify font attributes  1222  such as each unique font, character, etc. present in the electronic document  1204  that do not reside at the computing device  1202 . With this information identified, the software agent may initiate a font request  1224  to be sent to the font service provider  1210 . As represented by graphical arrow  1226 , one or more techniques (e.g., signaling, messages, etc.) may be utilized to provide the font request  1224  to the font service provider  1210 ; similarly, one or more techniques may be used as represented with a graphical arrow  1228  to provide a file  1230  that contains the font information for the application to present the electronic document (e.g., for editing). In this particular arrangement, the software agent scans an electronic document at the computing device attempting to present the document to identify attributes associated with needed font information. In some arrangements, operations may be executed remotely from the computing device that is attempting to present the document. For example, operations may be executed at the font service provider to identify attributes of an editable electronic document for font information needed by an application to present the document. 
     Referring to  FIG. 13 , an editable electronic document  1306  is sent to a font service provider  1302  to determine if any font information (e.g., fonts, characters, etc.) is needed by a computing device  1304  to have an executed application  1308  present the electronic document (e.g., for editing). To provide the textual content of the electronic document  1306  to the font service provider  1302 , a copy of the editable electronic document  1310  is sent in this arrangement. However, other techniques may be implemented, as represented by graphical arrow  1312 , to provide this information to the font service provider  1302 . Once received, the copy  1310  may be processed by a font service manager  1314  executed by a server  1316  located at the font service provider  1302 . For example, similar to the operations of the software agent described with respect to  FIG. 12 , the font service manager  1314  may perform operations to scan the copy of the electronic document  1310  to determine attributes of textual content for identifying the font information needed to present the document. In some arrangements, the font service manager  1314  may also determine what (if any) font information is specifically needed by the computing device  1304  to present the editable electronic document  1306  as intended. To identify the font information not present at the computing device, information is typically needed by the font service provider  1302  that indicates the font information that is currently present at the computing device (e.g., to allow the font service manager  1314  to compare the font information present and the information needed to display the electronic document). One or more techniques may be implemented to alert the font service manager  1314  to the font information present at the computing device  1304 . For example, data that represents that current font information residing at the computing device  1304  may be included with the copy of the electronic document  1310 . In another arrangement, data may be stored at the font service provider  1302  (or remotely stored and accessible by the font service provider) that represents the font information present at the computing device  1304  (and other computing devices, for example). From this information, the font service manager  1314  may determine the font information needed by the computing device  1304  to present the electronic document. Once identified, the needed information is attained by the font service provider  1302  (e.g., retrieved from one or more storage devices located at the font service provider, located external to the font service provider, etc.) for delivery to the computing device  1304 . As illustrated by graphical arrow  1318 , one or more techniques may be implemented to provide the needed font information to the computing device. For example, a font file  1320  may be prepared and sent by the font service provider  1302  to deliver the needed font information to the computing device. In some arrangements, the needed font information may be provided with the electronic document. As illustrated, a copy of the electronic document  1322  embedded with the needed font information may be sent to the computing device. One or more techniques may be utilized for embedding such information into an electronic document. Such techniques may also be dependent upon the document type. For example, application specific operations (e.g., for the MS-Word application) may be executed for embedding font information (e.g., TrueType fonts) into an electronic document associated with the application (e.g., an MS-Word document). By including the needed font information, the electronic document can be easily transferred to other computing devices in need of equivalent information to present the electronic document. In some arrangements, the font service provider  1302  may embed information for presenting all the fonts present in the electronic document. As such, the electronic document can be provided to any device for presentation since all the needed font information is capable of being provided with the document. In another arrangement to provide an electronic document embedded with all the font information associated with the content of the document, the computing device (e.g., via an application, agent, etc. executed by the computing device) may insert font information already present at the computing device to complement the needed font information provided by the font service provider  1302 . 
     Referring to  FIGS. 14-17 , a series of user interfaces are presented on the display of a computing device  1400  to demonstrate potential screens that may be provided to assist a user with attaining needed font information for presenting an editable electronic document. Referring to  FIG. 14 , a user interface  1402  is presented on the display of the computing device  1400  that reflects a file (e.g., a PSD file) that is attempting to be opened by an application (e.g., Adobe Photoshop). While accessing the file (e.g., open the file for display), the computing device (e.g., via a software agent executed by the computing device) has detected that font information is absent from the computing device and, therefore, the text of the electronic document will not be presented as originally intended. To alert the user of the situation, a message (e.g., in a graphical window  1404 ) is presented (e.g., by the application as triggered by the executed software agent) to indicate that font information is absent. In response to the alert that font information is absent, one or more techniques or methodologies may be employed to assist the user with attempting to remedy the issue. For example, triggered by the attempt to access the editable electronic document, the computing device (e.g., via the executed software agent) may send a request to a font service provider to provide the absent font information. For the situation, in which the document is being accessed (e.g., opened) at a font service provider (e.g., after being uploaded from a computing device), a server (e.g., via an executed software agent, application, etc.) may initiate a local request for font information absent at the computing device using attributes of the electronic document (e.g., fonts, characters, etc. identified within the document). In some arrangements, one or more user interactions may factor into requesting absent font information. 
     Referring to  FIG. 15 , a portion of a graphical interface  1500  is shown as being presented on the display of the computer system  1400 . In the illustrated example, a menu  1502  is presented with a number of options associated with fonts. For example, one user-selectable command  1504  (entitled “Find Missing Fonts”) is presented to allow the user to initiate a process of identifying absent font information (e.g., scan the electronic document at the computing device, a remote location such as a font service provider, etc.) and taking corrective action (e.g., sending a request to a font service provider for the absent information, sending a copy of the electronic document to a font service provider, etc.). Once the absent font information is attained (e.g., from the font service provider), the editable electronic document can be properly presented by the computing device. Additionally the attained font information may be embedded into the electronic document such that a complete set of font information is included with the document to assist with presentation (e.g., at the computing device  1400  or at another device). 
     Referring to  FIG. 16 , additional functionality may also be provided by the computing device  1400  (e.g., via an executed application, software agent, etc.) to assist with potentially identifying absent font information and taking corrective action. As illustrated in the figure, a graphical interface  1600  may be presented on the display of the computing device  1400  to allow a user to select one or more electronic documents to determine if any corresponding font information is not present at the computing device. In this example, the graphics interface  1600  provides a list  1602  of all files being accessed (e.g., opened) by the computing device  1400 . As a demonstration, two files (e.g., one PSD file and one pdf file) are represented in the list  1602  and each file is associated with a selection graphic  1604 ,  1606  (e.g., representing storage pathway to the file) that allows the user to select the respective file for examination. In this illustration, the selectable graphic  1606  presents that an associated .pdf file (labeled “pdf2.pdf”) that has been selected to determine if the computing device  1400  is missing any font information needed to present the text content of this file. Once a selection has been made, processing of the selected file or files may be initiated by the user, in this example, through a radio button  1608  (labeled “List Missing Fonts”). While such user interactions may initiate local examination of the access file or files, such interactions may also initiate examination at other locations. For example, examination of files accessed at a font service provider may be initiated by interactions with the graphical interface  1600 . In some arrangements, such interactions may initiate a corresponding document or documents to be sent to a font service provider for examination (e.g., scanning the document or documents). Interactions may also initiate examination of documents already present at the font service provider (e.g., documents being accessed at the font service provider). 
     One or more techniques and methodologies may be implemented to determine which files are being accessed in order to determine if any font information is needed to present the content of the files. In one arrangement, one or more processes may be executed by the computing device to make a series of determinations. For example, initially the computing device may determine which applications (e.g., Adobe Photoshop, Adobe Acrobat, MS-Word, etc.) are being executed which could be accessing one or more electronic documents (e.g., a PSD file, a .pdf file, an Word document, etc.). Along with identifying the application(s), other aspects may be identified, for example, the application type (e.g., text editor, image editor, etc.), application version (e.g., bit version), etc. may be determined by interrogating the application or applications being executed by the computing device. In some arrangements, once accessed files have been identified, operations may include filtering out particular types of files. For example, some files (e.g., non-PSD files) associated with particular applications (e.g., Photoshop) may not be capable of being interrogated for font information and therefore should not be presented in a list such as the list  1602 . Similar to accessed files (e.g., files being opened by an application); files with other statuses may be identified for font information checks. For example, stored files (e.g., a stored PSD file, pdf file, etc.) may be identified and interrogated to determine if any font information is needed to present textual content of the file (when accessed). In some arrangements, operations may be executed in the background (e.g., the user of the computing device is unaware of the executing operations) to make such determinations. For example, one or more storage devices, memories, etc. may be checked for pre-selected files, file types, etc. to determine if any font information is needed at one or more computing devices. Such file checking of files may also be scheduled to occur at one or more predefined times. For example, files residing to particular storage locations (e.g., storage devices, folders, etc.) may be examined at predefined times, days, etc. (e.g., each Sunday evening at 9:00 PM) to determine font information is missing from one or more computing devices based on the font needs of the files. Other examining techniques may also be employed for checking the readiness level of the computing devices. 
     Referring to  FIG. 17 , a graphical interface  1700  is presented in the display of the computing device  1400  to report font information absent from the computing device, for example, which is needed for presenting the electronic document of interest (e.g., selected through the graphical interface  1600  shown in  FIG. 16 ). In this illustrated example, the fonts missing from the computing device  1400  are identified in a table  1702  along with related information. In particular, one column  1704  of the table reports that five fonts (e.g., “ITC Anna™ Com Regular”, “Aquitaine™ Initials Com”, Anzeigen Grotesk™ Com”, Solid Antique Pro Roman”, and Aptifer™ Sans Pro Thin”) are absent from the computing device and are needed to present the textual content of the selected electronic document (i.e., “pdf2.pdf”). In this example, the table  1702  also provides information for attaining the missing fonts; for example, a right-most column  1706  reports the type of transaction needed to attain each of the missing fonts (e.g., each of the five missing fonts may be rented from one or more entities such as a font service provider). Two additional columns  1708 ,  1710  of the table  1702  also provide information about using the missing fonts; for example, the column  1708  (labeled “Usage”) provides the current rental rate for using each font and the column  1710  (labeled “Cr.”) reports any attained credits that may be used against the rental rate. Other types of information may also be provided to assist with attaining the absent font information, for example, information (e.g., a URL, internet link, etc.) may be provided to direct the user to the source of one or more missing fonts. 
     Referring to  FIG. 18 , a flowchart represents operations of a font service manager (e.g., the font service manager  1314  shown in  FIG. 13 ). Operations of the font service manager are typically executed by a single computing device (e.g., the server  1316  also shown in  FIG. 13 ); however, operations of the font service manager may be executed by multiple computing devices. Along with being executed at a single site (e.g., the font service provider  1302 ), execution of operation may be distributed among two or more locations. 
     Operations of the font service manager may include receiving  1802  a request that a computing device is unable to present textual content of an editable electronic document. For example, such a request may be initiated when a document is accessed for presentation (e.g., at a user computing device, at a server located remote from a user, etc.) and the computing device (for presenting the document) lacks font information for proper presentation. The request includes one or more attributes of the textual content of the editable electronic document. For example, the request may include data that represents attributes (e.g., included fonts, characters, etc.) of the document that the computing device is unable to present (e.g., the needed font information is absent from memory, operating system, etc.) Operations also include identifying  1804  appropriate font information for the computing device to present the textual content of the editable electronic document from the one or more attributes. For example, based upon receiving the request, a font service provider may collect the font information (e.g., locally at a font service provider, from one or more remote locations, etc.) needed to present the document as intended. Operations also include providing  1806  the identified font information to the computing device to present the editable electronic document. For example, the needed font information may be inserted into a file and sent to the computing device for presenting the electronic document (e.g., to allow a user to edit the document). The needed font information may also be embedded into the editable electronic document to allow the document to be transferred and presented (as intended) to a variety of different computing devices regardless of font information resident at the devices. 
       FIG. 19  is a block diagram showing an example of a system  1900  for providing hosted storage and accessing the hosted storage from a client device  1902  (e.g., a computing device). In some implementations, a hosted storage service  1920  may provide access to data (e.g., font information) stored by applications (e.g., web browsers) running on computing devices operating separately from one another, provide offsite data backup and restore functionality, provide data storage to a computing device with limited storage capabilities, and/or provide storage functionality not implemented on a computing device. 
     The system  1900  may provide scalable stores for storing data resources. The client device  1902  may upload data resources to the hosted storage service  1920  and control access to the uploaded data resources. Access control may include a range of sharing levels (e.g., private, shared with one or more individuals, shared with one or more groups, public, etc.). Data stored in hosted storage service  1920  can be secured from unauthorized access. The hosted storage service  1920  can use a simple and consistent application programming interface, or API, which can allow arbitrary quantities of structured or unstructured data to be kept private or shared between individuals, organizations, or with the world at large. The client device  1902  may access, retrieve, be provided, store, etc. data in the hosted storage service  1920  for any number of a variety of reasons. For example, data may be stored for business reasons (e.g., provide identification information to attain access clearance for font data at the hosted storage service  1220 ), or for use in data processing by other services. 
     The client device  1902  may be implemented using a computing device, such as the computing device  2000  or the mobile device  2050  described with respect to  FIG. 20 . The client device  1902  may communicate with the hosted storage service  1920  via a network  1904 , such as the Internet. The client device  1902  may communicate across the network using communication protocols such as one or more of Transmission Control Protocol/Internet Protocol (TCP/IP), Hypertext Transfer Protocol (HTTP), Secure Shell Remote Protocol (SSH), or Application Program Interfaces (API). Electronic mail (e-mail) protocols may also be utilized. For example, one or more e-mail protocols may be used for providing assets (e.g., electronic documents, etc.) to an imaging device (e.g., a printer) from the hosted storage service  1220 , a computing device such as the computing device  2000  or the mobile device  2050 , etc. While only a single client device  1902  is shown, there may be multiple client devices communicating across the network  1904  with the hosted storage service  1920  and/or other services and devices. 
     The hosted storage service  1920  may be implemented such that client applications executing on client device  1902 , such as a client application  1903 , may store, retrieve, or otherwise manipulate data resources in the hosted storage service  1920 . The hosted storage service  1920  may be implemented by one or more server devices, which may be implemented using a computing device, such as the computing device  2000  or mobile device  2050  described with respect to  FIG. 20 . For example, the hosted storage service  1920  may be implemented by multiple server devices operating in the same, or different, data centers. 
     The hosted storage service  1920  generally includes an interface frontend  1906 , an interface backend  1908 , a storage backend  1910 , and metadata  1916  for resources stored in the storage backend  1910 . The hosted storage service  1920  may also include an authenticator  1909  to verify that a user requesting one or more fonts should be provided access to the fonts (e.g., based on a service subscription, rental period, etc.). 
     In general, the interface frontend  1906  may receive requests from and send responses to the client device  1902 . For instance, the hosted storage service  1920  may be implemented as a Web Service with a corresponding set of Web Service Application Programming Interfaces (APIs). The Web Service APIs may be implemented, for example, as a Representational State Transfer (REST)-based HTTP interface or a Simple Object Access Protocol (SOAP)-based interface. Interface frontend  1906  may receive messages from the client  1902  and parse the requests into a format usable by the hosted storage service  1920 , such as a remote procedure call (RPC) to an interface backend  1908 . The interface frontend  1906  may write responses generated by the hosted storage service  1920  for transmission to the client  1902 . In some implementations, multiple interface frontends  1906  may be implemented, for example to support multiple access protocols. 
     The interface frontend  1906  may include a graphical front end, for example to display on a web browser for data access. The interface frontend  1906  may include a sub-system to enable managed uploads and downloads of large files (e.g., for functionality such as pause, resume, and recover from time-out). The interface frontend  1906  may monitor load information and update logs, for example to track and protect against denial of service (DOS) attacks. 
     As described above, the Web Service API may be a REST-based HTTP interface. In a REST-based interface, a data resource is accessed as a resource, uniquely named using a uniform resource identifier (URI), and the client application  1903  and service  1920  exchange representations of resource state using a defined set of operations. For example, requested actions may be represented as verbs, such as by HTTP GET, PUT, POST, HEAD, and DELETE verbs. The GET verb may be used to retrieve a resource, while the HEAD verb may be used to retrieve information about a resource without retrieving the resource itself. The DELETE verb may be used to delete a resource from the hosted storage service  1920 . The PUT and POST verbs may be used to upload a resource to the service  1920 . PUT requests may come from the client  1902  and contain authentication and authorization credentials and resource metadata in a header, such as an HTTP header. POST requests may be received when a client  1902  wants to upload from a web browser form. The form POST upload protocol for the hosted storage service  1920  may involve multiple form fields to provide authentication, authorization, and resource metadata. More generally, any of the API requests may include credentials for authentication and authorization, for example in a header of the request. An authorization header may be included in the REST requests, which may include an access key to identify the entity sending the request. 
     Alternatively, or additionally, a user may be authenticated based on credentials stored in a browser cookie, which may be appended to the API requests. If no valid cookie is present, a redirect to an authentication frontend may be generated, and the authentication frontend may be used to generate the browser cookie. The authentication frontend may be used by systems and services in addition to the hosted storage service  1920  (e.g., if the organization operating the hosted storage service  1920  also operates other web services such as email service). A user may also or alternatively be authenticated based on authentication credentials from an external credentialing service or an external service that includes credentialing functionality. User or group identifier information may be calculated from the external service&#39;s credential information. Requests sent by the client  1902  to the interface frontend  1906  may be translated and forwarded to the external service for authentication. 
     In general, resources stored in the hosted storage service  1920  may be referenced by resource identifiers. The hosted storage service  1920  may define namespaces to which a valid resource identifier must conform. For example, the namespace may require that resource identifiers be a sequence of Unicode characters whose UTF-8 encoding is at most 1024 bytes long. As another example, the namespace may require that resource identifiers be globally unique identifiers (GUIDs), which may be 128-bit integers. 
     Resources (e.g., objects such as font data) may be stored in hosted storage service  1920  in buckets. In some examples, each bucket is uniquely named in the hosted storage service  1920 , each data resource is uniquely named in a bucket, and every bucket and data resource combination is unique. Data resources may be uniquely identified by a URI that includes the bucket name and the resource name, and identifies the hosted storage service  1920 . For example, a resource named “/frutiger.fnt” in a bucket named “fonts” could be specified using a URI pattern such as http://s.hostedstoragesystem.com/fonts/frutiger.fnt or http://fonts.s.hostedstoragesystem.com/frutiger.fnt. Alternatively, the user of the client  1902  may create a bucket named my.fonts.org, publish a CNAME alias redirected to http://fonts.s.hostedstoragesystem.com, and address the resource as http://my.fonts.org/frutiger.fnt. In some examples, buckets do not nest. 
     The interface backend  1908  along with the authenticator  1909  may handle request authentication and authorization, may manage data and metadata, and may track activity such as for billing. As one example, the interface backend  1908  may query the authenticator  1909  when a request for one or more fonts is received. The interface backend  1908  may also provide additional or alternative functionality. For example, the interface backend  1908  may provide functionality for independent frontend/backend scaling for resource utilization and responsiveness under localized heavy loads. Data management may be encapsulated in the interface backend  1908  while communication serving may be encapsulated in the interface frontend  1906 . The interface backend  1908  may isolate certain security mechanisms from the client-facing interface frontend  1906 . 
     The interface backend  1908  may expose an interface usable by both the interface frontend  1906  and other systems. In some examples, some features of the interface backend  1908  are accessible only by an interface frontend (not shown) used by the owners of the hosted storage service  1920  (internal users). Such features may include those needed for administrative tasks (e.g., resolving a resource reference to a low level disk address). The interface backend  1908  may handle request authentication (e.g., ensuring a user&#39;s credentials are valid) and authorization (e.g., verifying that a requested operation is permitted). The interface backend may also provide encryption and decryption services to prevent unauthorized access to data, even by internal users. 
     The interface backend  1908  may manage metadata  1916  associated with data resources, for example in a MySQL database or BigTable. User-specified names labeling the buckets can be completely defined within the metadata  1916 , and resource metadata  1916  can map a resource name to one or more datastores  1912  storing the resource. The metadata  1916  can also contain bucket and resource creation times, resource sizes, hashes, and access control lists  1918  (ACL  1918 ) for both buckets and resources. The interface backend  1908  can log activity and track storage consumption to support accounting for billing and chargebacks. In some examples, this includes quota monitoring in each dimension in which customers are charged (e.g., reads, writes, network transfers, total storage in use). 
     The ACLs  1918  may generally define who is authorized to perform actions on corresponding buckets or resources, and the nature of the permitted actions. The ACLs  1918  may be an unordered list of {scope, role} pairs, plus Boolean flags. The scope may define a user or group of users and the role may define the access permissions for the user or group. In some examples, the union of all {scope, role} pairs may define access rights. In some examples, more specific {scope, role} pairs override more general ones. 
     The storage backend  1910  may contain multiple datastores  1912   a - 1912   c . Although three datastores  1912  are shown, more or fewer are possible. Each of the datastores  1912   a - 1912   c  may store data resources  1914   a - 1914   c  in a particular format. For example, data store  1912   a  may store a data resource  1914   a  as a Binary Large Object (BLOB), data store  1912   b  may store a data resource  1914   b  in a distributed file system (e.g., Network File System), and data store  1912   c  may store a data resource  1914   c  in a database (e.g., MySQL). In some arrangements, one or more of the data resources  1914   a - 1914   c  may include information associated with electronic documents (e.g., editable electronic documents). For example, the type of document, location of the stored document, etc. may be stored in one or more of the datastores  1912   a - 1912   c , the data resources  1914   a - 1914   c , etc. In some arrangements, the datastores  1912   a - 1912   c  and/or the data resources  1914   a - 1914   c  may include portions of electronic documents for later retrieval and use. For illustration, one editable electronic document  1915  is shown as being stored in datastore  1912   c . Similar to storing electronic documents, the datastores  1912   a - 1912   c , data resources  1914   a - c , etc. may store information associated with electronic documents. For example, font information corresponding to one or more electronic documents, types of electronic documents, etc. may be stored for later retrieval and use. 
       FIG. 20  shows an example of example computer device  2000  and example mobile computer device  2050 , which can be used to implement the techniques described herein. For example, a portion or all of the operations of the font service manager  1314  (shown in  FIG. 13 ) or the software agent  1212  (shown in  FIG. 12 ) may be executed by the computer device  2000  and/or the mobile computer device  2050 . Computing device  2000  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  2050  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  2000  includes processor  2002 , memory  2004 , storage device  2006 , high-speed interface  2008  connecting to memory  2004  and high-speed expansion ports  2010 , and low speed interface  2012  connecting to low speed bus  2014  and storage device  2006 . Each of components  2002 ,  2004 ,  2006 ,  2008 ,  2010 , and  2012 , are interconnected using various busses, and can be mounted on a common motherboard or in other manners as appropriate. Processor  2002  can process instructions for execution within computing device  2000 , including instructions stored in memory  2004  or on storage device  2006  to display graphical data for a GUI on an external input/output device, including, e.g., display  2016  coupled to high speed interface  2008 . 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  2000  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  2004  stores data within computing device  2000 . In one implementation, memory  2004  is a volatile memory unit or units. In another implementation, memory  2004  is a non-volatile memory unit or units. Memory  2004  also can be another form of computer-readable medium (e.g., a magnetic or optical disk. Memory  2004  may be non-transitory.) 
     Storage device  2006  is capable of providing mass storage for computing device  2000 . In one implementation, storage device  2006  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  2004 , storage device  2006 , memory on processor  2002 , and the like.) 
     High-speed controller  2008  manages bandwidth-intensive operations for computing device  2000 , while low speed controller  2012  manages lower bandwidth-intensive operations. Such allocation of functions is an example only. In one implementation, high-speed controller  2008  is coupled to memory  2004 , display  2016  (e.g., through a graphics processor or accelerator), and to high-speed expansion ports  2010 , which can accept various expansion cards (not shown). In the implementation, low-speed controller  2012  is coupled to storage device  2006  and low-speed expansion port  2014 . 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  2000  can be implemented in a number of different forms, as shown in the figure. For example, it can be implemented as standard server  2020 , or multiple times in a group of such servers. It also can be implemented as part of rack server system  2024 . In addition or as an alternative, it can be implemented in a personal computer (e.g., laptop computer  2022 .) In some examples, components from computing device  2000  can be combined with other components in a mobile device (not shown), e.g., device  2050 . Each of such devices can contain one or more of computing device  2000 ,  2050 , and an entire system can be made up of multiple computing devices  2000 ,  2050  communicating with each other. 
     Computing device  2050  includes processor  2052 , memory  2064 , an input/output device (e.g., display  2054 , communication interface  2066 , and transceiver  2068 ) among other components. Device  2050  also can be provided with a storage device, (e.g., a microdrive or other device) to provide additional storage. Each of components  2050 ,  2052 ,  2064 ,  2054 ,  2066 , and  2068 , are interconnected using various buses, and several of the components can be mounted on a common motherboard or in other manners as appropriate. 
     Processor  2052  can execute instructions within computing device  2050 , including instructions stored in memory  2064 . 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  2050 , e.g., control of user interfaces, applications run by device  2050 , and wireless communication by device  2050 . 
     Processor  2052  can communicate with a user through control interface  2058  and display interface  2056  coupled to display  2054 . Display  2054  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  2056  can comprise appropriate circuitry for driving display  2054  to present graphical and other data to a user. Control interface  2058  can receive commands from a user and convert them for submission to processor  2052 . In addition, external interface  2062  can communicate with processor  2042 , so as to enable near area communication of device  2050  with other devices. External interface  2062  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  2064  stores data within computing device  2050 . Memory  2064  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  2074  also can be provided and connected to device  2050  through expansion interface  2072 , which can include, for example, a SIMM (Single In Line Memory Module) card interface. Such expansion memory  2074  can provide extra storage space for device  2050 , or also can store applications or other data for device  2050 . Specifically, expansion memory  2074  can include instructions to carry out or supplement the processes described above, and can include secure data also. Thus, for example, expansion memory  2074  can be provided as a security module for device  2050 , and can be programmed with instructions that permit secure use of device  2050 . 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  2064 , expansion memory  2074 , and/or memory on processor  2052 ), which can be received, for example, over transceiver  2068  or external interface  2062 . 
     Device  2050  can communicate wirelessly through communication interface  2066 , which can include digital signal processing circuitry where necessary. Communication interface  2066  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  2068 . 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  2070  can provide additional navigation- and location-related wireless data to device  2050 , which can be used as appropriate by applications running on device  2050 . Sensors and modules such as cameras, microphones, compasses, accelerators (for orientation sensing), etc. maybe included in the device. 
     Device  2050  also can communicate audibly using audio codec  2060 , which can receive spoken data from a user and convert it to usable digital data. Audio codec  2060  can likewise generate audible sound for a user, (e.g., through a speaker in a handset of device  2050 .) 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  2050 . 
     Computing device  2050  can be implemented in a number of different forms, as shown in the figure. For example, it can be implemented as cellular telephone  2080 . It also can be implemented as part of smartphone  2082 , 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, which 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 display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying data to the user, 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 back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end 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 front end 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.