A system and method for displaying a text with a font
Field of the invention
 The present invention concerns a method and a system for displaying a text using a font on a user's device, wherein access rights associated with this font depend on this text in order to allow display of said text with this font and to prevent display of any other text with this font.
Description of related art
 With the advent of communication networks, such as the Internet and other private/public networks, computer devices have been used for sharing a wide range of information, from text to images and videos. Wireless networks have extended this scope of connectivity through mobile devices such as smart-phones, personal device assistants or notebooks. Since individuals and businesses now commonly use communication tools such as emails, blogs or chats for various purposes, users require a large degree of control over these messages to convey different intentions.
 In this context of massive information exchange, differentiation becomes a key factor. Given that a major part of online communications is text-based, text display customization should be extensive and user- friendly.
 Therefore, in text communications, users often put some emphasis on specific words or text blocks, in order to facilitate the legibility of a document or to convey a special meaning. In such a case, users have developed distinct ways to personalize texts: by applying styles, by changing fonts, by altering font properties, or by creating micro-languages such as smileys and short SMS-style language.
 Most text-editors feature basic styles such as size, color, underlined, or paragraph alignments. Visual variety is also provided by font choices, which may however be limited to the set of fonts installed on the
computer device. Finally, font properties such as spacing, tracking or contextual ligatures may sometimes be applied.
 Despite this array of personalization options, text-based applications share some common limitations. The text format has to be set manually for each character, text block, paragraph or selection. It is only through a time-consuming manual process that an end-user can customize the visual appearance of a message. More advanced personalization, for example non parallel paragraphs or text baselines, are usually not possible, although very common and distinctive for handwriting.  The possibilities of personalization with new or unusual fonts, although attractive, are often limited. This in due, in part, to the complexity of current font creation and distribution tools. Drafting and sharing personalized fonts is out of reach for most end-users which therefore have to rely on existing sets of standard fonts.  Font creation solutions exist, but their use is limited to advanced users and professionals and usually requires installation of a comprehensive software package. This in not adapted for casual users. Moreover, even when a new font has been created or updated, it is difficult to distribute it. Current font formats such as TrueType®, OpenType® or Postscript® cannot be used on a device without prior local installation.
 A consequence is that most web sites or email clients, for example, only use the very limited number of standard fonts that are installed in most computers and devices.
 Solutions such as Embedded OpenType® have been developed in order to distribute and display copyright vector fonts on the web, but the specific subsetting and encryption methods it uses lead to the multiplication and redundancy of font data and files between many devices and websites, to a waste of storage space, and to frequent incompatibility between successive versions of one font.
[00011 ] There are several patents or patent publications in the prior art related to the creation of fonts, including fonts based on handwriting. The following documents are herewith enclosed by references:
 FR2807183 describes a method for creating a handwritten font based on a guide grid. This document does not provide any solution for sharing fonts, and requires installation of a dedicated program and fonts on an end-user's device.
 US7352899 ("Realistic machine-generated handwriting with personalized fonts") describes a method for generating a handwritten font, where handwriting variability is randomly simulated. The method applies to vector fonts only. Although vector fonts are easily scalable, they are poorly adapted to the representation of handwriting, since the texture and pressure of the writer cannot be easily represented with vectors.
 US5412771 ("Generation of interdependent font characters based on ligature and glyph categorizations") describes a method for automatic generation of ligatures between characters.
 US6867787 ("Character generator and character generating method") relates to a method for applying three dimensional effects to a font.  US7379075 relates to a method for the representation of colour in bitmap fonts.
 US6870535 ("Font architecture and creation tool for producing richer text") relates to a method of creating a series of font characters represented by a specific hierarchical graph structure.  US6958755 describes a personalized computer font solution using a simplified workflow for personal fonts creation. It is limited to creation of fonts based on letters drawn on a grid. As most current font solutions, it also relies on font technologies that are not appropriate for live communications between different interconnected devices.
 US2004091176 describes another method for generating a vector font from characters written in a grid.
 US6065008 ("System and method for secure font subset distribution") relates to a method for creating, signing and distributing fonts and to various methods for authenticating fonts subsets.
[00021 ] US5533174 relates to a method for secure distribution of font stored in a server.
 US6853980 describes a system for distributing fonts, where the distance between fonts is computed for facilitating the search.  US7009612 relates to a method for generating fonts based on an existing font.
 US6975412 relates to a method for authenticating fonts in order to make sure that the font used during rendering is the same as the font used during the creation of a document.  US7188313 relates to a program for automatic generation of ligature between adjacent characters.
 US5295238 relates to another program for automatic generation of context sensitive characters.
 WO2006042307 relates to a method for introducing randomness in a vector font, in order to simulate handwriting.
 US2003025675 describes a method for simulating handwriting in a vector font, using various parameters such as width, pressure, speed, etc.
 US7161598 describes a program for the rendering of fonts, wherein a single file is used for defining a plurality of characters.  None of those solutions provides a method for displaying a text with a font and preventing display of any other text with this font.
[00031 ] Moreover none of those solutions provides a method for creating and sharing a new font without installing any dedicated authoring software. Thus, the creation of new font is limited to expert users who have the time and money for purchasing and/or installing a new application in their computer. This is hardly convenient for casual users, for example users who have only one font to create and share.
 In addition, the author of a new font has no or limited possibilities for controlling the access rights to his new font, and for deciding which other user or group of users are authorized to use or modify his font.
 Especially the creation of a new font from an image, such as a scanned bitmap image, for example, involves advanced methods and user interactions which are usually performed with proprietary software which must be installed in the author's computer.  In addition, none of those solutions provides a convenient method allowing users to produce new original fonts, for example fonts based on their personal handwritings or custom smileys, and immediately use those fonts in messages sent to recipients. In all or most of the prior art solutions, display and use of a font is only possible for recipients who have previously installed this font in their computer systems. This seriously limits the acceptance of the new fonts.
 Moreover, even if some services have been proposed to simplify the process of handwritten font creation, the lack of control over the end- result limits the interest of those services and the quality of this result.  Moreover, the creation and the rendering of the fonts are usually performed with two different software programs, which often produce a different rendering.
 Therefore, there is a need for a font creation tool which is adapted to users who want to create a new font for one single message, in order to prevent other messages to be displayed with this font.
 There is also a need for a system and method that enable authors to control which user, or group of users, can use this newly created font and for which purpose.
 There is a need for a system and for a method that enable users to easily create a new font, for example a font based on handwriting, or based on a scanned image, or any other type of font.
 There is also a need for a system and for a method that enable users to immediately use a newly created font in documents or messages that can immediately and easily be read and correctly rendered by any recipient, without any installation of font creation software in the author's device nor in the recipient device, and without explicit installation of the new font in the recipient's device.
[00041 ] There is further a need for a system and method that enable authors to create fonts, especially bitmap fonts, which better simulate the handwriting and quality of a rendered text with this font.
 There is also a need for a system and method that enable authors to create or edit a font with the same tools, or a similar set of tools, than the software tools used by the receiving user for rendering the font.
 A further aim is to fulfill the need for a system that provides more advanced styling features, more flexibility over displayed texts, for example text blocks or text flows and with a greater ease of use for the end-users. They may also be empowered to create custom glyphs to extend existing fonts. This will ultimately lead to more expressive and original displayed texts. Brief summary of the invention
 According to the present invention, these problems are solved by a method for displaying a text created by an author using a font on at least an user's device, wherein access rights are associated with said font, characterized in that said access rights depend on said text to display with said font, in order to allow display of said text with said font and to prevent display of any other text with said font.
 One author can preferably define access user's rights to a font in order to authorize or prevent other users to use this font. The user's rights can be stored in a Central Server.
 Advantageously, the access rights are granted by the author to a limited number of users.
 Advantageously the font is based on bitmap font described by a bitmap file (i.e., an array of pixels) for allowing a more flexible representation of text, since the color of each pixel can be individually controlled. The bitmap that corresponds to each character can be stored in a central server that can be accessed by each authorized user who needs this font to display a text.
 Advantageously the same piece of software used for creating a new font and for rendering this font in a browser is used also for granting the access rights in order to authorize or prevent a user to use the font.
 The bitmap fonts are preferably stored in a central server, and accessed by the rendering application of the users who need to use this font. Local, cache copies of those fonts can also be stored in devices of authorized users
[00051 ] Advantageously the authentication of the association method of a font with a text changes periodically in order to prevent the association of any text content with any font.
 This association method comprises a static web resource containing the URL of the font, created by the server; this static web resource is stored in the server. The rendering application of user's device
computes the address of this web resource using a common non-reversible algorithm based on the content and a secret they share. In one embodiment this secret, or this algorithm, is changed periodically. A new set of static web resource containing the URL of the font is calculated when the secret or the algorithm is changed.
 A time stamp can be associated with each modification of the user's rights, so that, when a font is disabled or otherwise made unavailable for some users, only earlier message can be displayed with this font but no message created after the font disability.  Advantageously multiple fonts can be associated with a text by the author. The author can, in one embodiment, associates different parts of the text with different fonts. For example he can associate the first part of the text with a font F1, the second part with a font F2 different from F1, and the final part with a font F3 different from F1 and F2.  In another embodiment, different fonts can be associated by the author to different parts of the text and the user, when receives the text, can select the font with which display these different parts. For example the author can associates the first part of a text with fonts F1 and F2 and the second part with font F2 and F3. The user can choose to display for example all the text with the font F2, or the first part with the font F1 and the second with the font F2 or F3. All the possible combinations of the fonts for the different parts can be selected by the user.
 In another embodiment, the author can associate a text with multiple fonts having different priorities. The text is displayed by the user with the font having a higher priority. In one embodiment the user can decide to display this text with an allowed font having a lower priority.
 The invention concerns also a system for allowing at least an user's device to display a text created by an author using a font, wherein access rights are associated with said font and depend on said text to display with said font comprising an author's device for creating said font and for associating said access rights to said font, a network server connected over a network to said author's device and at least an user
device for receiving said font from the server, whereby the author's device includes computer program means for receiving and sending information over the network server, computer program means for creating said bitmap font and for associating access rights to said font depending on said text, whereby said server includes means for storing said access rights and whereby said user device includes computer program means for receiving information over the network server, computer program means for rendering said text using said fond depending on said access rights in order to allow display of said text with said font and to prevent display of any other text with said font.
 Preferably, the server comprises a web/application server running over an operating system of this server.
 The present invention has applicability for an author who wants to create new fonts either for its private use or for sharing them with another user or group of recipient users connected together over a network and use them only for a specific text or message. This user or group of users may select a font in a font collection created by the author on his own device but stored in a central server. For example, the newly created fonts can be immediately applied to emails, web pages and blogs.  An important advantage of the method and system according to the invention is permitting an author to associate a font, created for example by scanning his own handwritten writing, with a specific text, in order to prevent other texts to be displayed with this font.
[00061 ] The invention concerns also a computer program product comprising a program to be executed by an author's device and/or a user's device and/or a server for causing it to perform the steps of such a method.
Brief Description of the Drawings
 The invention will be better understood with the aid of the description of an embodiment given by way of example and illustrated by the Figures, in which:
 Figure 1 is a bloc diagram of a system with a client-server architecture for font creation, distribution and storage according to the present invention.
 Figure 2 shows a bloc diagram of a prior art system for creating and sharing fonts.
 Figure 3 shows a flow diagram of a method according to the invention, for creating and sharing fonts in order to use them in messages.
 Figure 4 shows a flow diagram of an alternate method according to the invention for creating and sharing fonts in order to use them in messages.
 Figure 5 shows a flow diagram of a method for creating, processing and using personalized fonts through a service server, according to the prior art.
 Figure 6 shows a flow diagram of another alternate method according to the invention for creating, processing and using personalized fonts from guides.
 Figure 7 shows a possible embodiment of a font creation interface with multiple input sources for font creation, according to the present invention.  Figures 8a to 8f show different input sources for font creation.
[00071 ] Figure 9 shows a possible embodiment of the glyph assignment of multiple input sources according to the present invention.
 Figures 10a and 10b show a screen copy and a partial screen copy for illustrating an embodiment of graphical user interface (GUI) used for segmenting the glyphs and assisting the segmented glyphs with a character, according to the present invention.
Detailed Description of possible embodiments of the Invention
 For understanding purposes, a definition of the following words as they are used in this document is provided:
A letter corresponds to a single alphanumerical or non alphanumerical character, to a symbol, pictogram, etc. A word is a series of letters which may or may not be visually inter-connected. A word usually carries one meaning and is separated from other words by a word separator, for example by a space.
A glyph is an element of writing, i.e. a single portion of an image of a text which contributes to the meaning of what is written. A glyph may correspond to a portion of a letter, a complete letter, an alphanumerical character, a pictogram, a smiley, an emoticon, an ideogram, etc.
A ligature corresponds to two or more glyphs which are visually inter-connected, for example when two or more characters are joined in handwriting. The word text needs to be understood in its broad acceptation.
Basically, a text is an ordered set of letters, including alphanumerical or non alphanumerical characters, pictograms, and/or symbols.
 According to the invention, a specific font may be associated with a specific text, in order to allow display of this text with this font and to prevent other texts to be displayed with the same font. Appropriate access rights may be defined by the font author and stored in the Central Server 2 in order to define which text may be rendered with which font.
 Using this feature, an author may for example create a font corresponding to his handwriting, or any other font, and immediately send a highly personalized message, for example an e-mail, a contribution to a blog or website, etc, with this font to any recipient. The recipient user can use this font for immediate display of the personalized message sent by the author, but is prevented from using this handwritten font for the rendering of other messages.
 Figure 1 shows a system for creating and distributing personalized fonts over a network according to the present invention. This system comprises the following elements: a plurality of Font Creation Clients 1, a Central Server 2, possibly associated with a Web/application server 4, and a plurality of Font Display Clients 3. Only one Font Creation Client 1 and one Font Display Client 3 are shown on Figure 1.
 The Font Creation Client 1, the Font Display Client 3 and the Central Server 2 are mutually connected through a network connection such as a local network and/or the Internet. Fonts created and stored by one Font Creation Client 1 are automatically synchronized with copies stored in a Central Server 2for access and use by one or several Font Display Client 3. One Font Creation Client 1 is provided to each author who wants to create and share a font. This Font Creation Client 1 comprises a software application, for example a program or preferably a plug-in, which is executed locally in a user device such as a computer, a game station or a mobile communication device. The user device includes a processor, random access memory (RAM), non volatile memory, e.g. ROM, hard disk drive, flash memory and/or similar memories. It also comprises a network input/output which can be implemented as a wireless module or as a network connection, and a display monitor.
 Various input devices Id can be connected to the Font Creation Client 1, such as but not limited to a mouse, a stylus, a touch panel, a camera or a scanner. A printer P can be connected in order to print paper grids and other guides used during the creation of a font.  A Local Font Storage 11 stores fonts created with this Client 1. The Local Font storage 11 comprises an input sources database 11a, a font database 11 b, a font packages storage 11c and a font file database 11d.
 The input source database 11 a stores digital images to be processed for retrieving a font. The digital images used as sources may correspond to handwritten text pages, freeform hand-drawn letter sheets, characters in a grid guide, photo images, hand-drawn smileys, etc.
Font Creation Client 1 and in the Font Display Client 3. In another embodiment; the software of the Font Display Client 3 is a lighter version of the software in the Font Creation Client 1 , and comprises for example only the portions of the code which are required for retrieving and displaying the bitmap fonts, without the portions needed for creating a new font.
 The font creation, distribution and rendering applications may also consist of independent applications running on top of the operating system, such as but not limited to an Adobe® AIR™ application. It is noted that any other operating system, such as Apple® OSX™ or Linux® may be used, as well as any application platform, should it be browser-based or not, for example but not limited to MS® Silverlight™ or C++™ applications.
 The resources and processing power required for the font creation, storage and rendering of a bitmap font are shared between Font Creation Client 1, the Server 2 and the Font Display Client 3. The font creation process is principally performed on the author's side in the Font Creation Client 1 by an application executed on the author's device, for example within a browser. The font rendering process on the user's side is performed by the Font Display Client 3 with a similar or identical application executed within a browser of the user's device.
 Since the same, or a similar, application may be used during the creation and rendering this font, the appearance of this font is the same on the author and user sides.
 The application run in the author's and/or client's device, respectively for the Font Creation Client 1 and the Font Display Client 3, is preferably also capable of sending messages, for example emails or contributions to a blog or chat platform, personalized with a bitmap.
 Still referring to Figure 1, the Central Server 2may be built around a computer server having an operating system, such as but not limited to Microsoft® Windows® NT Server. The Central Server 2 includes a processor, non volatile memory, e.g. ROM, hard disk drive, flash memory, and/or similar memories, a network I/O (input/output) which can be
implemented as a wireless module or a network connection, and a display monitor. The Central Server 2 may also be any form of distributed server or virtual machine. The Central Server 2 may run additional image and font processing applications on top of the operating system, such as but not limited to a vectorization application, for processing fonts and text images sent by Fonts Creation Clients 1.
 The Central Server 2 comprises or can access a Central Database 21 , in which the fonts created by different authors by means of their Font Creation Client 1 are stored, as well as the corresponding access rights. [00091 ] More precisely, a plurality of files or data are stored in the Central Database 21 during the creation of a new font:
• the original input sources database 21 a;
• the font database 21 b, which is a set of bitmap font glyphs at their highest resolution; • a font packages storage 21c for a set of multi-resolution font packages which are automatically down-sampled from the original font, and/or a vector font file;
• a font metadatabase 21 d in which metadata such as font name, character sets, keywords, spacing, kerning, etc., are stored for each font;
• a storage 21 e for storing content-file signatures allowing a specific font to be associated with a specific content, for example in order to prevent the use of a particular font with a different content; • an access rights database 21f that stores the font access rights assigned by each author to his fonts. Each font may be associated with credentials issued by the font author or by a font distributor (not shown). A font author may assign specific rights to a font or group of font and to a user or
group of users, in order to grant or restrict the right to preview, view, use, copy and/or buy a font.
 Scripts may also be associated with some fonts in order to define and personalize the rendering.  According to the invention, it is possible to change periodically the validation of the association of a text content with a font without impacting the content. This characteristic enables to prevent attackers from gathering all fonts or to associate any content with any font.
 To validate the association of a content with a font and retrieve this font, it is possible to call a dynamic web service that would read a database, validate the association and then provide the associated font URL. However calculating this information by this way may hinder scalability. Therefore, according to one aspect of the invention, static resources of the internet infrastructure are used.  In one example, when an author decides to associate a content with a font, for example when an author creates a message with a specific font, the Central Server 2 creates a static web resource referenced at the address at URL1 and containing the URL of the associated font referenced URL2.  When the Font Display Client 3 on the recipient's s side needs to display a content with a specific font associated with this content, it have to compute the address URL1. If at this address there is a resource, it means that there is a font associated with this content. If so, the Font Display Client 3 retrieves the URL2 from this resource. If not, the Font Display Client 3 displays the content using a replacement font.
 Font Display Client 3 computes the address URL1 by using a nonreversible algorithm shared with the Central Server; the computation is based on the content and on a secret shared by the Central Server and the Client. This secret or the algorithm is changed periodically, new sets of URL1 are calculated for all known associations and distributed.
 The Font Display Client 3 then navigates to this computed URL1 and retrieves the resource at this URL. If the resource exists, this means that there is a Font-Package associated with this content.
 Since the algorithm is non-reversible, to be able to create a new set of URL1 when the secret changes, the Central Server 2 needs to store the association in a database when it is created. This information will be read again only when the secret is changed and in order to recreate the new set of URL1.
 The following algorithm may be used to compute URL1 : For p the content's permalink, c the content and s the shared secret, k = sha1 (norm(p)) m = sha1 (norm(c)) URL1 = http://fontstoraaeURL.eom/s/k/mRenderinq
Other algorithms can be visualized by the person skilled in the art in order to compute the URL1.
 The access rights may be assigned by the author using the above mentioned browser-based application and/or later edited or updated using an interface to access to Central Server 2. An author may for example grant private rights to one font that can only be accessed by him, restricted rights for other fonts authorized to users or group(s) of users, or public rights for other fonts which can be accessed by all users. Several combinations of rights may be assigned to a specific font and/or to a specific user through a specific interface. Advantageously, a graphical user interface (GUI) provides the author a series of options to grant rights.  Table 1 shows an example of assignment of rights in the access right database 21f. In this example, an author has the rights which required for viewing and editing his font. This author authorized some users to use one font, but not to duplicate it. Other specific groups may buy the font in order to use it. Finally, all users have at least a right to preview the font, for example in a catalog in the public library.
Preview View Use Copy
Preview Display a font preview in the font library
View Display messages with the font
Use Enable font usage
 All fonts are stored in the input sources database 21a, preferably as bitmap fonts. Several successive versions of a font may be stored in the server 2.  Multi-resolution font-packages may also be computed and stored in the font-packages storage 21c of the Central database 21 in order to optimize bandwidth and to provide efficient font data transmission. When a Font Display Client 3 renders a message with a font, it may automatically retrieve and use the font package with the closest resolution to the requested size and quality.
 As already mentioned, the fonts stored in the Central Database 21 are synchronized with local copies temporarily stored in Local Font Storage 11 on the author's side, and distributed over the Internet to different Font Display Clients 3; this distribution is for example automatically triggered on demand when one authorized user displays a page, e-mail or document with this font.
 Still referring to Figure 1, the system may comprise a web/application server 4, associated with the Central Server 2. This web server consists of any kind of web server or application server software where a specific set of instructions, provided as plug-ins, DLLs or others, have been implemented. Interconnected between the Central Server 2
and the Font Display Client 3, it makes the fonts stored in Central Database 21 available to a plurality of users for rendering fonts. In one embodiment, the web/application server 4 can also process and forward messages sent by the author(s) to some users.  We will now describe some methods which are carried out during the creation, sharing and display of a font. Figure 2 shows a flow diagram of a prior art method for local creation of a font, and later sharing of the font with other users. In this method, an author who wants to send a message with a new font first needs to draw or import the different letters of the new font (step 5). A font is then locally created and/or edited in the user's device during step 6 in order to generate a font file during step 7. This font is then sent to a Central Server 2 (step 8) where it is stored during step 20. Separately, this font is installed in the author's device during step 9.  In this prior art method, a user 3 who wants to receive and display a text with this new font first needs to download the font from the server 2 during step 32, and install the font in his device during step 33.
 A message using the new font can then be prepared and sent by the author during step 10, and displayed with the new font on the recipient side during step 34.
[0001 10] This process is cumbersome and time consuming both for the author 1 and for the recipient 3, who both need to install the font before it can be used. Moreover, this font can only be used by recipients 3 who actively retrieved the font from the server, and successfully installed it.
[0001 11 ] Figure 5 shows a flow diagram of another prior art method for creating, remotely processing and using personalized fonts. The main difference with the method of Figure 2 is that, in this case, the new font is generated in a central server. [0001 12] During step 14 of Figure 5, a user first prints a grid guide with his printer P, and then fills during step 5 the grid by drawing glyphes, such as
letters or other symbols in the boxes of the grid. The grid is then scanned during step 15, and converted into an image file. The position of each glyph in the grid guide corresponds to the character which has to be associated with this glyph. [0001 13] In the prior art method of Figure 5, the scanned bitmap image is then sent at step 16 to a server 2. Since a high resolution image is required, a large file needs to be transferred, which is time consuming or even impossible for equipments with slow Internet connection.
 The bitmap data received by the server 2 is then processed in the server during step 22, in order to generate a bitmap font at step 23.
Processing usually includes segmentation of the image in order to isolate the different glyphs, and association of those glyphs with characters or symbols. In the prior art, this step is usually performed automatically without any user intervention, and based for example on optical character recognition and/or position of the glyphs within the grid. Therefore, it only works with fonts which are relatively easy to recognize, or at least when optical recognition or use of a grid is feasible.
[0001 15] The font generated at step 23 is then sent back during step 24 to the author's device 1, where it is downloaded at step 17. During step 8, the author 1 then has to send, or make available, a copy of this newly generated font to all other users who needs this font, for example by sending e-mails with the font in attachment, or by uploading this fonts in font repositories over the Internet.
[0001 16] A recipient 3 who receives or retrieves this font during step 32, has to install it during step 33 before he can use it to display messages with this font at step 34. In a similar way, the author 1 also needs to install his own font (step 9) in order to use it (step 18).
 This process is very cumbersome for different reasons. First, the transfer of the scanned image to a remote server 2 at step 16 is time consuming and requires a large bandwidth which is not always available. The generation of a font from this image occurs remotely in the server 2 during steps 22 and 23, meaning that the author has little possibilities to
control this process and to define which glyph corresponds to which character. The need to send the font in advance and to install it in the devices of all potential users, including the author, makes the sharing of a new font difficult and slow. [0001 18] Figures 3 and 4 describe two embodiments of the present invention for creating and sharing fonts in order to use them in messages or for rendering text displayed in any document. During step 12, an author who wants to create and use a font first needs to install in his device a Font Creation Client 1, i.e., an application or plug-in. This application can be retrieved from the Central Server 2, or from any other suitable repository, and needs to be downloaded only once for all the subsequent fonts to create or display. This application/plug-in is preferably run in a browser where it is automatically launched when the author accesses a specific address or link on the Internet. [0001 19] A font is then created within the Font Creation Client 1 by drawing or importing an image with glyphs (step 5 in Figures 3 and 4). The font is then edited and processed (step 6), wherein the processing comprises a segmentation and assignment, as will be described. The font creating and processing of steps 5 and 6 is performed locally in the author's device with the application previously installed or launched during step 12. A message using this new font can then be sent directly from the same application during step 10, for example an e-mail message, a contribution on a blog, a web page, an instant messaging message, etc.
 The font created and processed during steps 5 and 6 is automatically sent to a Central Server 2, where it is stored during step 20. A duplicate of the font-packages storage 11c is then stored in the font package storage 21 c of the Central Database 21.
 The bitmap font stored in the Central Server 2 may be further processed by the author and/or by any other authorized user, using a suitable remote application in the Central Server 2, for example an application available through a web page which can be accessed with the Web server 4 (step 40). This font is also made immediately available to authorized users over this web server 4, and can be immediately used at
step 34, for example in order to display messages with this font sent by the author during step 10.
 There is thus no need for installing the font in the author and in the recipient device; the font is immediately made available through the Central Server 2, over the Web Server 4, and displayed by any client having previously installed the requested application/plug in.
 In order to optimize bandwidth consumption and accelerate font display, font-packages may be cached by the Font Display Client 3 in a local memory 31. Instead of repeatedly fetching the same font package on the Central Server 2, all messages with an identical font will be displayed by using this locally-stored copy of the bitmap font. The Font Display Client 3 then provides a mechanism for synchronizing the local copy of the font with the copy in the Central Storage 2, in order for example to update the font. Thus, new versions of the fonts uploaded in the Central Server 2 are automatically transmitted to the users with a local copy, subject to access rights.
 In one embodiment, a subset of glyphs is transmitted from the Central Server 2 to the Font Display Client 3, for example only the glyphs corresponding to the characters which are used in a text to render with this font.
 The font-package transmitted to the user's device for rendering of a particular text or for synchronization with the local copy is preferably automatically selected among a plurality of available packages with different resolutions; the Font Display Client 3 automatically retrieves the font with the best resolution needed for the display of the text, depending on the text and on the user's device.
 In addition, different versions of the font, corresponding to different languages may be available. The Font Display Client 3 automatically selects the version which is needed, depending on user's selections, on the current language settings of the user, on the language of the text, and/or on the letters or symbols which need to be represented in this text.
 In the embodiment of Figure 4, a local copy of a new font is stored during step 13 in a cache of the author device 1 for faster access and processing. The fonts in this local Cache are later automatically synchronized with the fonts stored in the Central Server 2. This local storage is not performed in Figure 3, where the new font is immediately transferred to the Central Server 2, and where even the author accesses only the centrally stored version of his font.
 The transmission of the new font from the Font Creation Client 1 to the Central Server 2 is preferably automatically performed without any author's intervention, using synchronization mechanisms executed as part of the Font Creation Client 1. The author may nevertheless intervene during this step, for example in order to change the user's rights assigned to this font.
 A font will not be deleted from the Central Database 21, modified or otherwise made unavailable after its distribution to any client 3 who used or bought it. Even if one author disables one font at some time, messages previously associated with that font will still be displayable by using a duplicated font-packages storage 21c. A time stamp may be associated with each modification of the font's access rights and with each message, so that only earlier messages can be displayed with this font, but no messages created after the font's disability.
 Figure 6 illustrates another example of font generating and sharing process according to the invention. During step 12, an author downloads from the Central Server 2 or any other repository the Font Creation Client 1, and installs this application in his device, or runs it as a plug-in in a browser. This installation needs to be done only once in a device and the plug-in can for example be executed or made available each time the browser is subsequently started.
 During step 14, as in the prior art, the author prints a grid guide with the printer P or retrieves such a grid guide. The grid guide may be printed by using an option or command in the plug in.
 The author then draws letters or groups of letters in boxes of the grid guide during step 5. When the grid guide has been completed, it is scanned during step 15, and converted into a bitmap file.
 Alternatively, the author can also retrieve images of texts with glyphs by selecting a file otherwise available. The author can also draw or modify glyphs within the plug-in, by using a suitable drawing software.
 During step 19, the bitmap image is processed in order to isolate the different glyphs on the page and to associate each glyph with one character or sequence of characters. This processing is advantageously performed locally in the Font Creation Client, i.e, by the very same application/plug in which is used for drawing or importing the bitmap file and later on for sharing and displaying the generated bitmap font.
 In one embodiment, some steps of the font generation process are performed in a remote Central Server 2 during step 22. For example, the segmentation of the image into different glyphs, and/or the association between each glyph and or character or sequence of characters, is preferably performed locally in the author's Font Creation Client 1, in order to avoid transfer of large size files. Some subsequent steps can be performed in the server 2, in order to exploit the larger processing power.
 The bitmap font which is generated at the end of the process is preferably stored in the author's Font Creation Client 1 during step 13, and automatically sent and synchronized during step 20 with a copy stored in the Central Database 21 of the Central Server 2. This font can also be used immediately for displaying text in the author device, using a bitmap font rendering tool as part of the Font Creation Client /plug-in.
 Using the same plug-in, the user can also define user's rights during steps 19-13, and store those rights in the Central Server 2 for defining what other users can do with this font.  The method according to the present invention preferably does not rely on the input-sources database 21 a to store access rights for a Font
Display Client 3. The method of authentication and credentials required for using a specific font can thus be changed without any modification of the input-sources database 21a. This feature further enables to periodically change the association method in order to prevent attackers from gathering all font-packages or associate any content with any font- package.
 After synchronization and definition of user's rights in step 20, the new font is immediately made available at step 40 to other users through the web or application server 4. Other users who need to display a text with this new bitmap font can immediately do this with a suitable Font Display Client 3 that will retrieve this font from the Central Server 2 through the web or application server 4.
 Figures 7 to 8b are various screen copies and partial screen copies displayed by the Font Creation Client 1 during the font creation process of the present invention.
 Figure 7 is a screen copy displayed by the Font Creation Client 1 of the author's device during step 19 of the font creation process. The creation of a new bitmap font comprises a plurality of steps which are, in this embodiment, successively performed with various tabs in a window displayed by the Font Creation Client Software application. In the example, the displayed window comprises a first tab titled "Import" for the importation of an image of a text with glyphs,, a second tab "Segment" for the segmentation of this image in order to isolate the glyphs, a third tab "Assign" for assigning a character or sequence of characters to a glyph, a fourth tab "Adjust" for the adjustment of the glyph, and a fifth tab "Export" for exporting the created bitmap font.
 The first step (importation) consists in the importation of images and/or directly drawing of glyphs within the Font Creation Client 1, by using any device such as a mouse, a tablet, a touch screen or an image scanner for example. The application for importing the image is advantageously run in the web browser of the author's computer, as part of the author's Font Creation Client plug-in. In Figure 7, the importing window proposes different files which are available from the author's
device, namely a free text scan_31.jpg represented by a mosaic 106, a photo scan_32.jpg represented by a mosaic 110, a grid guide scan_33.jpg represented by a mosaic 104 and a free form scan_34.jpg represented by a mosaic 102. The author can freely select one of those images. Other and new images can also be used, including sources in different formats.
 Figures 8a to 8f illustrate different examples of images (input sources) that an author may select to create a font. Example of possible images include for example: separate individual image files 100 (one file for each glyph); one single hand-written page 102 with characters, numbers, symbols and even drawings; a grid guide of characters 104, in which one glyph is written in each or some boxes of the grid; a hand-drawn text page 106; a guided hand-drawn text page 108; and/or a photographic picture 110.
 Sources with guides may include some specific helper codes such as a Datamatrix or QR Code 114, shown on Figure 8c and 8e, in order to identify the specific character sequences and to indicate the orientation of the page. This code 114 can also be used for indicating the type of input source.
 Those guides 114 may for example be printed on paper form on which the author draws or writes a new font, and scanned together with the image of the font in order to provide automatic font recognition and orientation.
 An author may also combine several glyph creation methods, and/or modify a previously imported glyph. For example, the author may write a free text on a page, scan and import this text into the browser- based application, and modify or clean the scan image using image processing tools provided by the Font Creation Client plug-in and/or by the Central Server 2. The processing of the scanned image may for example include removal of noise, increase of sharpness, adaptation of contrast,
rotation and resizing of the image and manual edition of glyphs or glyph parts.
 Multiple input sources may also be processed and used for the creation of a single alphabet. To provide a global view of the images to be processed, the author(s) may import several input sources on a single canvas and display them with a preview.
 Additional information may also be retrieved from the scanned form and/or entered by the author, including for example the characters to be extracted or the type of segmentation to be used during the next step of the font processing.
 When several sources are edited at any step of the process, they may also be displayed and organized as a series of elements. In one possible embodiment, various sources of one type are displayed on various sub-tabs, with or without a preview icon, or simply by representing the sources by file names scan_31.jpg to scan_34.jpg, as shown in Figure 9. The lower part of the window of Figure 9 shows an image of a currently selected sub-tab (here the image scan_33.jpg) as well as a virtual keyboard for assigning glyphs on this image with characters or series of characters.
 After the importation, as a second step of the font creation method of the present invention, a segmentation is automatically and/or manually performed in order to identify areas of the image containing the various glyphs. An automatic segmentation may be used when the source is guided, for example based on a grid, while manual segmentation may be preferred for other types of sources. In one embodiment, the Font Creation Client 1 proposes an automatic segmentation, based for example on position in a grid and/or on optical recognition algorithms, and the author can adjust the segmentation in a manual step, if needed.
 Figures 10a and 10b show an exemplary screen copy of a window that may be displayed within the browser by the Font Creation Client 1 during the font segmentation and association process.
[0001 52] After an optional initial automatic segmentation of the selected image into glyphs (if possible), the author(s) may draw and/or adjust the size, shape and position of bounding boxes around each glyph to be extracted. Other shapes instead of this rectangle bounding box may also be used, for instance a lasso tool to delimit a freeform polygon around the glyph.
[0001 53] Figure 10a illustrates a source image 200 previously imported and selected by the author and which is displayed in a portion of the display. This image typically comprises a plurality of individual glyphs 202 which need to be isolated. Each glyph is delimited by a bounding box 204, 210, 212 or 214. The bounding box 204 comprise handles 206 with which the boxes may be manually modified with a cursor in order to affect the dimension, position and rotation of the box. It is also possible to scale a box 204 in order to adapt the size of the glyph in the box. Once a new bounding box 204 is selected, the other ones 212 are simply visualized with a single stroke without any handles.
[0001 54] After its segmentation, a glyph 202 may then be manually associated with a character or a string of characters by using for example one of the following steps performed by the author: -automatic association, for example based on optical character recognition, or on position in a grid. The character or symbol automatically assigned to a glyph can be corrected by the author.
-clicking a specific key 208, for example one key for each bounding box 204, or a key associated with the currently selected box 204, to launch a new preview window 230, as illustrated in Figure 10b; or
-typing the appropriate character(s) on a text field 210 near the currently selected glyph 202; or
-dragging a box 214 and dropping it on a "droppable key" 220 linked to a specific character or on a generic key 21 6 on a virtual keyboard 218 displayed on screen.
 In Figure 10a, the box 214 is dragged and dropped on the generic key 216 which displays a preview window 230 similar to the one shown in Figure 10b.
 During the drag-and-drop process, the image cropped inside the box may be displayed as semi-transparent, as shown by the box 214, or replaced by a smaller icon or specific cursor arrow to facilitate the placement over the virtual keyboard 218. In the same time, droppable keys 224 of the virtual keyboard may be specifically at least temporarily recognizable, for example by highlighting as the box is dragged over them. Once a glyph has been dropped over a virtual key, this key can be made recognizable in another manner, for example differently highlighted as referenced with 222, for the author to notice which keys have already been associated with a glyph.
The preview window 230 of Figure 10b provides a preview of the cropped glyph image together with a text field 232 in which the author can enter one or several character(s) to associate with this glyph. A box eraser 236 is provided in the preview window 230 for removing noise pixels around the character. This preview window 230 includes additional image modifications options 234 for modifying the glyph, such as a delete key D and navigation keys referenced Pr, Ne En respectively for Previous, Next and Enter to navigate between the successive bounding boxes.
 These features may also have time-based properties. A behavior may be effective on glyphs, words, sentences or paragraphs, and affect them differently, for instance incrementally. A behavior may be set before the user types text, or applied after a text block was selected. Behaviors may be exposed to the user by a series of parameters. Behaviors may be accumulated and applied sequentially. Behaviors may be provided at random or may be manually added to the rendering system, and provided as external programming script codes.  As samples of the different parameters that may be affected and exposed for specific displayed text behaviors, bending lines can be cited in regard of slope, curvature and bending start. Jitter can be also considered, especially for horizontal displacement, vertical displacement, maximum for
random translation, maximum for random rotation and maximum for random scale. Parameters concerning the drying ink, i.e. percentage loss and consumption per letter/ word/ line and parameters concerning the ligatures, i.e. On /Off switch and maximum letters per ligature are also of interest as well as alternates, e.g. contextual alternative glyphs.
 The author of a font may thus program specific scripts, for instance in a Flash® application or similar software, in order to apply them to a displayed text. This also allows to use bitmap fonts and to process additional image-based visual effects, such as but not limited to a blur, sharpening or coloring of the glyphs.