Cloud dynamic dot-matrix font service method and system

Abstract

The embodiment of the invention provides a cloud dynamic dot-matrix font service method and system, and relates to the field of font processing, and the method comprises the steps that a client rendering agent module obtains a font request sent by terminal equipment; the client rendering agent module determines request information based on the font request and sends the request information to the dynamic rasterization engine. After receiving the request information, the dynamic rasterization engine sends a first verification request to a permission and version control module; and after the dynamic rasterization engine receives verification passing information returned by the permission and version control module, generating a dot matrix bitmap about fonts, and sending the dot matrix bitmap to the dot matrix cache and distribution network. And the dot matrix cache and distribution network caches the dot matrix bitmap and sends the dot matrix bitmap to the client rendering agent module, so that the terminal equipment can display fonts. The problems of overlarge storage space occupation and weak copyright management and control are solved.

Description

Technical Field

[0001] This application relates to the field of font processing, specifically to a cloud-based dynamic dot matrix font service method and system. Background Technology

[0002] With the rapid development of the Internet of Things (IoT), industrial interconnection, and smart terminal devices, the demand for graphical user interfaces in embedded systems is increasing. Text, as the core carrier of human-computer interaction, has become crucial for enhancing product experience through clear, diverse, and efficient display. However, embedded devices are generally limited by limited storage space, processing power, and network bandwidth, posing a significant challenge to their font rendering technology.

[0003] Currently, embedded devices primarily rely on pre-built bitmap font files to display text. This solution centralizes font storage, management, and rendering entirely on the terminal, leading to several drawbacks: First, storage efficiency is low, requiring a large number of pre-built files to adapt to multiple font sizes and languages, consuming valuable storage space; second, copyright control is weak, making it difficult to control the scope and permissions of font file usage, hindering commercial operation.

[0004] Therefore, there is an urgent need for a cloud-based dynamic dot matrix font service method / system to solve the above-mentioned defects. Summary of the Invention

[0005] In view of the above problems, this application provides a cloud-based dynamic dot matrix font service method and system, which overcomes or at least partially solves the problems of low storage efficiency and weak copyright control.

[0006] A first aspect of this application provides a cloud-based dynamic bitmap font service method, comprising: a client rendering proxy module acquiring a font request sent by a terminal device; the client rendering proxy module determining request information based on the font request and sending the request information to a dynamic rasterization engine; the dynamic rasterization engine receiving the request information and sending a first verification request to a permissions and version control module; the dynamic rasterization engine receiving verification pass information returned by the permissions and version control module and generating a bitmap of the font, and sending the bitmap to a bitmap cache and distribution network; the bitmap cache and distribution network cache the bitmap and sending the bitmap to the client rendering proxy module for display of the font on the terminal device.

[0007] In this embodiment, the client rendering proxy module determines the request information based on the font request, sends the request information to the dynamic rasterization engine, and the dynamic rasterization engine generates a bitmap of the font. This establishes an architecture where the terminal device requests the font and the dynamic rasterization engine generates the bitmap, so that the terminal device does not need to pre-install a complete font library, but only needs to integrate a lightweight client rendering proxy module, thus solving the problem of excessive storage space.

[0008] After receiving the request, the dynamic rasterization engine needs to send an initial verification request to the permissions and version control module. This verification must be approved by the permissions and version control module, which acts as a real-time authorization decision point for the entire cloud-based dynamic bitmap font service process. This mandates that the dynamic rasterization engine obtain explicit authorization before generating the bitmap, thus controlling the scope and permissions of font file usage. Furthermore, the generated bitmap is cached and distributed via a bitmap cache and distribution network, which can accelerate high-frequency requests and reduce the processing load on the dynamic rasterization engine.

[0009] In an alternative approach, before the client rendering proxy module obtains the font request sent by the terminal device, the method further includes: initializing the client rendering proxy module.

[0010] In one optional approach, the client rendering proxy module is initialized by sending an authentication request to the permissions and version control module, the request carrying the terminal device ID and a pre-assigned security token. The permissions and version control module checks the validity of the terminal device ID and the pre-assigned security token. Upon successful authentication, the permissions and version control module returns an access token, an available font ID, and a font version to the client rendering proxy module.

[0011] By verifying the terminal device ID against the pre-allocated security token, strong verification and legitimacy access of the terminal device are completed at the service entry point, intercepting illegal devices at the source. The access token, available font ID, and font version returned after successful authentication establish a secure and efficient lightweight session credential for all subsequent interactions. It also informs the client in advance of its precise resource permission range, thereby avoiding a large number of invalid or unauthorized network requests.

[0012] In an alternative approach, before the client-side rendering proxy module sends the request information to the dynamic rasterization engine, the method further includes: querying the local cache, and if the cache is hit, directly using the cached bitmap for displaying the font on the terminal device.

[0013] In this embodiment, by setting a local cache query at the very front end of the request chain, a large number of repetitive and high-frequency font rendering requests are intercepted and responded to directly on the terminal device. This reduces the dependence on the cloud service network and the pressure on backend computing resources, thereby significantly reducing service response latency and network traffic consumption. While ensuring the consistency of font display effect, offline availability is achieved, and the overall service capacity of the system and the end-user experience are greatly improved.

[0014] In one alternative approach, the request information includes character encoding, font ID, font version, font size, terminal device ID, and access token.

[0015] In one alternative approach, after receiving the request information, the dynamic rasterization engine sends a first verification request to the permission and version control module, including: after receiving the request information, the dynamic rasterization engine sends a first verification request to the permission and version control module based on the font ID, font version, terminal device ID and access token in the request information.

[0016] In one alternative approach, after the dynamic rasterization engine receives the verification pass information returned by the permissions and version control module, the method further includes: the dynamic rasterization engine sending a second verification request to the font asset management module based on the font ID and font version in the request information.

[0017] In one alternative approach, after receiving the verification pass information returned by the permissions and version control module, the dynamic rasterization engine generates a bitmap of the font, including: the dynamic rasterization engine obtaining the vector description data corresponding to the font ID from the cloud vector description library, and the dynamic rasterization engine generating a bitmap of the font based on the vector description data.

[0018] In this embodiment, the core assets of the font, namely the vector description and the dynamic rasterization engine, are centrally deployed in the cloud, enabling a one-time modification to take effect globally and instantly. Any glyph update only requires modifying the data once in the vector description library in the cloud, and all subsequent requests from all terminals can automatically obtain the latest rendering results. This completely solves the maintenance problem of distributing and updating complete font files to a massive number of devices one by one in traditional solutions, and realizes centralized and versioned management of font assets.

[0019] In an alternative approach, the method further includes: when the font is updated, the permissions and version control module instructs the bitmap cache and the distribution network cache to invalidate the bitmap bitmaps before the font update.

[0020] In this embodiment, by actively invalidating the old cache, the waste of storage resources and the chaos of serving new and old data simultaneously can be avoided.

[0021] Another aspect of this application provides a cloud-based dynamic bitmap font service system, including a client-side rendering proxy module, a dynamic rasterization engine, a permission and version control module, a bitmap caching and distribution network, and a terminal device. The client-side rendering proxy module is integrated into the terminal device, while the dynamic rasterization engine, permission and version control module, and bitmap caching and distribution network are all deployed on a cloud service platform. The client-side rendering proxy module is used to obtain font requests sent by the terminal device. It is also used to determine request information based on the font request and send the request information to the dynamic rasterization engine. Upon receiving the request information, the dynamic rasterization engine sends a first verification request to the permission and version control module. The permission and version control module performs verification based on the first verification request. After receiving verification pass information from the permission and version control module, the dynamic rasterization engine generates a bitmap of the font and sends the bitmap to the bitmap caching and distribution network. The bitmap caching and distribution network caches the bitmap and sends it to the client-side rendering proxy module for display on the terminal device.

[0022] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating a cloud-based dynamic dot matrix font service method provided in some embodiments of this application.

[0025] Figure 2 This is a schematic diagram of the structure of a cloud-based dynamic dot matrix font service system provided in some embodiments of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0028] The terms "comprising" and "having," and any variations thereof, used in the specification, claims, and drawings of this application are intended to cover without excluding other meanings. The words "a" or "an" do not exclude the presence of multiples.

[0029] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of the phrase "embodiment" in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0030] Furthermore, the terms "first," "second," etc., in the specification and claims of this application or in the aforementioned drawings are used to distinguish different objects rather than to describe a specific order, and may explicitly or implicitly include one or more of the features.

[0031] In the description of this application, unless otherwise stated, "multiple" means two or more (including two), and similarly, "multiple groups" means two or more (including two groups).

[0032] In the description of this application, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linkage" should be interpreted broadly. For example, "connection" or "linkage" in mechanical structures can refer to a physical connection, such as a fixed connection, for example, a connection fixed by fasteners, such as a connection fixed by screws, bolts, or other fasteners; a physical connection can also be a detachable connection, such as a snap-fit ​​or interlocking connection; a physical connection can also be an integral connection, such as a connection formed by welding, bonding, or integral molding. In circuit structures, "connection" or "linkage" can refer not only to a physical connection but also to an electrical connection or a signal connection. For example, it can be a direct connection, i.e., a physical connection, or an indirect connection through at least one intermediate component, as long as the circuit is connected; it can also refer to the internal connection of two components. Signal connection can refer not only to signal connection through a circuit but also to signal connection through a media, such as radio waves. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0033] Figure 1 This is a flowchart illustrating a cloud-based dynamic dot matrix font service method provided in some embodiments of this application. Figure 1 As shown in the figure, the cloud-based dynamic dot matrix font service method provided in this application embodiment includes the following steps 101 to 105: Step 101: The client rendering proxy module obtains the font request sent by the terminal device.

[0034] Step 102: The client-side rendering proxy module determines the request information based on the font request and sends the request information to the dynamic rasterization engine.

[0035] For example, when a terminal device needs to display font F, it can send a font request to the client rendering proxy module.

[0036] The client-side rendering proxy module determines the request information based on the font request. The request information may include character encoding, font ID, font version, font size, terminal device ID, access token, and other rendering parameters.

[0037] For example, the character encoding could be U+4E2D, the font ID could be F, the font version could be v1.0, the font size could be 12 pixels, the terminal device ID could be Device_A, and the access token could be AccessToken_A.

[0038] Step 103: After receiving the request information, the dynamic rasterization engine sends the first verification request to the permissions and version control module.

[0039] In some embodiments, after receiving the request information, the dynamic rasterization engine sends a first verification request to the permission and version control module based on the font ID, font version, terminal device ID and access token in the request information.

[0040] Step 104: After receiving the verification information returned by the permissions and version control module, the dynamic rasterization engine generates a bitmap of the font and sends the bitmap to the bitmap cache and distribution network.

[0041] Step 105: The bitmap is cached and distributed via a network and then sent to the client rendering proxy module for display on the terminal device.

[0042] In practical applications, after receiving the bitmap, the client rendering proxy module sends it to the terminal device's application to display the font, and also stores the bitmap in the local cache for later use.

[0043] In this embodiment, the client rendering proxy module determines the request information based on the font request, sends the request information to the dynamic rasterization engine, and the dynamic rasterization engine generates a bitmap of the font. This establishes an architecture where the terminal device requests the font and the dynamic rasterization engine generates the bitmap, so that the terminal device does not need to pre-install a complete font library, but only needs to integrate a lightweight client rendering proxy module, thus solving the problem of excessive storage space.

[0044] After receiving the request, the dynamic rasterization engine needs to send an initial verification request to the permissions and version control module. This verification must be approved by the permissions and version control module, which acts as a real-time authorization decision point for the entire cloud-based dynamic bitmap font service process. This mandates that the dynamic rasterization engine obtain explicit authorization before generating the bitmap, thus controlling the scope and permissions of font file usage. Furthermore, the generated bitmap is cached and distributed via a bitmap cache and distribution network, which can accelerate high-frequency requests and reduce the processing load on the dynamic rasterization engine.

[0045] In some embodiments, before the client rendering proxy module obtains the font request sent by the terminal device, the method further includes: initializing the client rendering proxy module.

[0046] In some embodiments, initializing the client rendering proxy module includes sending an authentication request to the permissions and version control module, the authentication request carrying a terminal device ID and a pre-assigned security token. The permissions and version control module checks the validity of the terminal device ID and the pre-assigned security token. After successful authentication, the permissions and version control module returns an access token, an available font ID, and a font version to the client rendering proxy module.

[0047] By verifying the terminal device ID against the pre-allocated security token, strong verification and legitimacy access of the terminal device are completed at the service entry point, intercepting illegal devices at the source. The access token, available font ID, and font version returned after successful authentication establish a secure and efficient lightweight session credential for all subsequent interactions. It also informs the client in advance of its precise resource permission range, thereby avoiding a large number of invalid or unauthorized network requests.

[0048] In some embodiments, before the client rendering proxy module sends the request information to the dynamic rasterization engine, the method further includes: querying the local cache; if the cache is hit, the cached bitmap is directly used for displaying the font on the terminal device.

[0049] In this embodiment, by setting up local cache query at the forefront of the request link, a large number of repeated and high-frequency font rendering requests are directly intercepted and responded locally on the terminal device, reducing the dependence on the cloud service network and the pressure on the backend computing resources. Thus, the service response latency and network traffic consumption are significantly reduced. While ensuring the consistency of the font display effect, offline availability is achieved, and the overall service capacity of the system and the terminal user experience are greatly improved.

[0050] In some embodiments, after the dynamic rasterization engine receives the verification passed information returned by the permission and version control module, the method further includes: the dynamic rasterization engine sends a second verification request to the font asset management module based on the font ID and font version in the request information.

[0051] In some embodiments, after the dynamic rasterization engine receives the verification passed information returned by the permission and version control module and the verification passed information returned by the font asset management module, a dot matrix bitmap is generated. After the dynamic rasterization engine receives the verification failed information returned by the font asset management module, it can display to the terminal device that this font or this font version is not published.

[0052] In some embodiments, after the dynamic rasterization engine receives the verification passed information returned by the permission and version control module, a dot matrix bitmap of the font is generated, including: the dynamic rasterization engine obtains the vector description data corresponding to the font ID from the cloud vector description library, and the dynamic rasterization engine generates a dot matrix bitmap of the font based on the vector description data.

[0053] The dynamic rasterization engine based on the vector description data, combined with font size, anti-aliasing algorithm, font shaping adjustment instructions, etc., calculates and generates an accurate dot matrix bitmap in real time in the server memory.

[0054] For example, taking the generation of a bitmap of the Chinese character "中" in a 12x12 pixel dot matrix as an example, the working process of the dynamic rasterization engine in the cloud to generate a dot matrix bitmap of the font is described in detail.

[0055] Obtain vector description data: Assume that the vector description of the character "中" is stored in the cloud vector description library, which may be a simplified contour path, for example, represented by SVG path data: M 2,10 L 5,10 L 5,2 L 7,2 L 7,10 L 10,10 L 10,12 L 2,12 Z.

[0056] This represents a path that starts from the point (2,10), passes through several points, and finally closes. Note that this path is defined in an abstract coordinate system, for example, the coordinate system is a 1000x1000 unit.

[0057] Scale to the target size: The target dot matrix is 12x12 pixels. Therefore, the vector path needs to be scaled from the original coordinate system to a 12x12 grid. Note that the coordinate range of the original path is from 2 to 10 (width is 8) and from 2 to 12 (height is 10), and it needs to be adapted to a 12x12 pixel grid.

[0058] The scaling process includes translation and scaling transformations, so that the bounding box of the original path (2,2) to (10,12) is mapped to a 12x12 pixel grid. At the same time, it may be necessary to consider blank spaces. For example, mapping the original height of 10 units to 12 pixels, that is, the vertical scaling factor is 12 / 10, which is 1.2, and the horizontal scaling factor is 12 / 8, which is 1.5.

[0059] Apply font hinting instructions: [[ID=We]] Font hinting instructions are adjustments to the outline to keep the glyphs clear and consistent at low resolutions. For example, there may be some font hinting instructions to ensure that the vertical strokes of the character "中" are aligned at the pixel boundaries to avoid blurring.

[0060] Assume that the font hinting instructions require aligning the x coordinates of the vertical strokes to integer pixel positions. After scaling, non-integer coordinates may be obtained. Through the font hinting instructions, the above coordinates can be adjusted to the nearest integer pixel position. For example, adjusting x = 3.7 to 4 to ensure the clarity of the vertical strokes.

[0061] Rasterization: Convert the adjusted path into a pixel dot matrix, and use the scan line algorithm or other rasterization algorithms to determine which pixels fall inside the path. For a 12x12 grid, traverse the center point of each pixel and determine whether it is inside the path. If so, set the pixel to 1, that is, display it in black, otherwise it is 0, that is, display it in white.

[0062] Apply anti-aliasing algorithm: Due to the low resolution, direct binarization may cause edge jaggedness. The anti-aliasing algorithm sets the gray value by calculating the area of the pixel covered by the path. For example, if a pixel is covered by the path by 50% of its area, then it is set to 50% gray. In the binary dot matrix, it can be represented by a gray-scale image or converted into a black-and-white dot matrix through a dithering algorithm.

[0063] Generate dot matrix bitmap data: Convert the 12x12 pixel array into a bitmap byte array row by row. For example, each row is 12 bits, that is, 1.5 bytes, and 16 bits, that is, 2 bytes, are used to represent a row, and the high 4 bits are filled with zeros. In this way, the entire dot matrix can be represented by 12 rows × 2 bytes, that is, 24 bytes.

[0064] In some embodiments, the method further includes: when the font is updated, the permission and version control module instructs the dot matrix cache and the distribution network cache to invalidate the dot matrix bitmaps before the font update.

[0065] The following uses a specific example to describe the process of a cloud dynamic dot matrix font service method provided by this application.

[0066] The client rendering proxy module on the terminal device A first initializes and sends an authentication request to the permission and version control module. The authentication request carries the terminal device ID, namely Device_A, and the pre-allocated security token, namely Token_A.

[0067] The permission and version control module checks the validity of the terminal device ID and the pre-allocated security token. Assume that Device_A is a registered legal device, then the authentication passes. After the authentication passes, the permission and version control module returns an access token, namely AccessToken_A, the available font ID, and the font version to the client rendering proxy module.

[0068] When the application on the terminal device A needs to display the Chinese character '中', the client rendering proxy module obtains the font request sent by the terminal device, that is, it needs to display the Chinese character '中'. The client rendering proxy module determines the request information based on the font request. The request information includes character encoding, font ID, font version, font size, terminal device ID, and access token. The client rendering proxy module first queries the local cache. If the cache is hit, it directly uses the cached dot matrix bitmap for the terminal device to display the font. If not, the client rendering proxy module determines the request information based on the font request.

[0069] In practical applications, the client rendering proxy module can also send the request information to the edge node of the dot matrix cache and the distribution network. The edge node will check the legality of the request information. For example, it checks whether the access token is valid. If it is legal, it checks whether there is a cache in the dot matrix cache and the distribution network. If the cache is hit, it directly uses the cached dot matrix bitmap for the terminal device to display the font. If there is no cache, the client rendering proxy module sends the request information to the dynamic rasterization engine.

[0070] After receiving the request information, the dynamic rasterization engine sends a first verification request to the permission and version control module based on the font ID, font version, terminal device ID, and access token in the request information to verify whether the device has the right to use this font. After the dynamic rasterization engine receives the verification passed information returned by the permission and version control module, the method further includes: the dynamic rasterization engine sends a second verification request to the font asset management module based on the font ID and font version in the request information.

[0071] After the dynamic rasterization engine receives the verification passed information returned by the permission and version control module and the verification passed information returned by the font asset management module, it generates a dot matrix bitmap. After the dynamic rasterization engine receives the verification failed information returned by the font asset management module, it can display to the terminal device that this font or this font version has not been released. The dynamic rasterization engine sends the dot matrix bitmap to the dot matrix cache and distribution network. The dot matrix cache and distribution network caches the dot matrix bitmap and sends the dot matrix bitmap to the client rendering proxy module for the terminal device to display the font.

[0072] An illegal request from terminal device B. Since terminal device B does not have a legitimate token or its terminal device ID is on the blacklist, the client rendering proxy module on terminal device B initializes first and sends an authentication request to the permission and version control module, which will reject it and return an error code. Even if terminal device B bypasses the client rendering proxy module and directly sends a request to the dot matrix cache and distribution network, the dot matrix cache and distribution network will also fail when checking the access token and thus deny the service. If the request information reaches the dynamic rasterization engine, the dynamic rasterization engine will also fail when sending the first verification request to the permission and version control module.

[0073] When the font is updated, assume that the designer uploads the vector description data of the font "中" in the new version v1.1 through the background of the font asset management module, and this vector description data is transferred and stored in the vector description library.

[0074] Specifically, the designer selects the font "中" on the operation interface of the asset management module, uploads the vector description data of the new version, and submits the update to generate the new version number v1.1.

[0075] The asset management module notifies the permission and version control module that there is a new version v1.1 of the font "中". At the same time, the asset management module archives the old vector description data and switches to the new version.

[0076] The permission and version control module decides the update strategy. For example, it can immediately switch the font version of all devices to v1.1, or conduct a gray release, that is, first let some devices update. Assume that immediate update is selected.

[0077] The permission and version control module sends a command to the dot matrix cache and distribution network, instructing all cache entries related to the font "中" v1.0 to become invalid. Specifically, a "clear cache" request can be sent to match all caches with the font ID "中" and the font version "中".

[0078] After receiving the command, the dot matrix cache and distribution network immediately clears the eligible caches on all its edge nodes. In this way, the previously cached dot matrix bitmap of version v1.0 will be deleted.

[0079] Similarly, the permission and version control module can also send commands to the client rendering proxy module to indicate the invalidation of all local caches related to the font "中" v1.0. Specifically, a "cache clearing" request can be sent to match all local caches with the font ID "中" and the font version "中".

[0080] After receiving the command, the client rendering proxy module immediately clears the eligible local caches. In this way, the dot matrix bitmaps of the previously locally cached v1.0 version will be deleted.

[0081] At the same time, the permission and version control module marks the current version of the font "中" as v1.1. When the client rendering proxy module of terminal device A is initialized next time or checked regularly, it will obtain the new font version v1.1 from the permission and version control module.

[0082] When the application on terminal device A requests the character "中" again, the font version in the request information determined by the client rendering proxy module is v1.1. Since the dot matrix cache and the cache of v1.0 in the distribution network and the client rendering proxy module have been cleared, and the cache of v1.1 has not been generated yet, the client rendering proxy module sends the request information to the dynamic rasterization engine. Specifically, the client rendering proxy module sends the request information to the dot matrix cache and distribution network, and then the dot matrix cache and distribution network sends it to the dynamic rasterization engine.

[0083] The dynamic rasterization engine obtains the vector description data of the font "中" v1.1 from the vector description library, generates new dot matrix bitmaps, and returns them to terminal device A through the dot matrix cache and distribution network. At the same time, the dot matrix cache and distribution network caches the dot matrix bitmaps of the font version v1.1.

[0084] In this way, smooth font updates and global cache invalidation are achieved, ensuring that all terminal devices can obtain the latest font glyphs in a timely manner. The object of update and maintenance is decoupled from the complete static font files on the terminal device side to the processing on the cloud side, so that the modification of the font only needs to update the data once on the cloud side, realizing accurate incremental updates.

[0085] In practical applications, for example, hundreds of thousands of smart meters of a certain brand are deployed globally, and their LCD screens need to display multiple languages. The company updated the trademark font and needed to add the symbol " " in the electricity numbers. The administrator used an online editor in the background of the font asset management module on the cloud to modify the corresponding glyphs of the trademark and add the symbol " The vector description data of "" is used to generate the new version V1.1. Through the console, the update can be pushed out in a gray-scale rollout to all terminal devices (electricity meters) within 48 hours. When the electricity meter needs to display the relevant characters again, the client rendering proxy module detects that the previously cached version has expired, requests a new bitmap from the dynamic rasterization engine, and seamlessly completes the update. Without downtime or wireless network access, a huge update package containing all font files is sent to the electricity meter, which then performs the entire font package replacement and installation locally—fast and accurate.

[0086] In practical applications, for example, advertising screen service providers need to offer customers hundreds of artistic fonts to choose from, but they cannot predict customer needs, and the storage space of the screen control card is limited.

[0087] Service providers can integrate the client-side rendering proxy module into the screen controller software. When a customer edits advertising content on a webpage and selects a rare 3D-effect artistic font, the webpage backend generates a playlist containing the font ID and text content. After the screen controller parses this playlist, the client-side rendering proxy module can request the bitmap of each character under the specific 3D-effect artistic font and the specific screen physical pixels from the cloud-based dynamic rasterization engine, cache and play it, achieving "massive fonts, select and use immediately" with zero pre-installation cost.

[0088] In some embodiments, the cloud-based dynamic bitmap font service method provided in this application is easy to expand with new functions, such as adding an AI super-resolution module to improve the clarity of low-sized fonts, which only requires inserting a processing step after the dynamic rasterization engine.

[0089] Another embodiment of this application also provides a cloud-based dynamic dot matrix font service system. Figure 2 This is a schematic diagram illustrating the structure of a cloud-based dynamic dot matrix font service system provided in some embodiments of this application. (Reference) Figure 2The cloud-based dynamic bitmap font service system includes a client-side rendering proxy module 21, a dynamic rasterization engine 22, a permission and version control module 23, a bitmap cache and distribution network 24, and a terminal device 25. The client-side rendering proxy module 21 is integrated into the terminal device 25, while the dynamic rasterization engine 22, permission and version control module 23, and bitmap cache and distribution network 24 are all deployed on the cloud service platform. The client-side rendering proxy module 21 is used to obtain font requests sent by the terminal device 25. It also determines request information based on the font request and sends the request information to the dynamic rasterization engine 22. Upon receiving the request information, the dynamic rasterization engine 22 sends a first verification request to the permission and version control module 23. The permission and version control module 23 performs verification based on the first verification request. After receiving the verification pass information returned by the permission and version control module 23, the dynamic rasterization engine 22 generates a bitmap of the font and sends the bitmap to the bitmap cache and distribution network 24. The bitmap cache and distribution network 24 is used to cache bitmaps and send them to the client rendering proxy module 21 for display of fonts on the terminal device 25.

[0090] refer to Figure 2 The cloud-based dynamic bitmap font service system may also include a local cache 26, a vector description library 27, and a font asset management module 28. The dynamic rasterization engine 22, the permission and version control module 23, and the vector description library 27 are all connected to the font asset management module 28. The permission and version control module 23 and the vector description library 27 are also connected to the dynamic rasterization engine 22. The dynamic rasterization engine 22 and the permission and version control module 23 are both connected to the bitmap cache and distribution network 24. The bitmap cache and distribution network 24 is connected to the client rendering proxy module 21 integrated in the terminal device 25. The client rendering proxy module 21 is also connected to the local cache 26 within the terminal device 25.

[0091] This application provides a cloud-based dynamic dot matrix font service system, which helps to solve the problems of low storage efficiency and weak copyright control.

[0092] Those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, in the claims, any of the claimed embodiments can be used in any combination.

[0093] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A cloud-based dynamic dot matrix font service method, characterized in that, The method includes: The client-side rendering proxy module obtains the font request sent by the terminal device; The client-side rendering proxy module determines the request information based on the font request and sends the request information to the dynamic rasterization engine; After receiving the request information, the dynamic rasterization engine sends a first verification request to the permission and version control module. After receiving the verification pass information returned by the permission and version control module, the dynamic rasterization engine generates a bitmap of the font and sends the bitmap to the bitmap cache and distribution network. The bitmap is cached in the bitmap cache and the distribution network, and the bitmap is sent to the client rendering proxy module for display of the font on the terminal device.

2. The method according to claim 1, characterized in that, Before the client rendering proxy module obtains the font request sent by the terminal device, the method further includes: The client rendering proxy module is initialized.

3. The method according to claim 2, characterized in that, The initialization of the client rendering proxy module includes: Send an authentication request to the permissions and version control module, the authentication request carrying the terminal device ID and a pre-assigned security token; The permission and version control module checks the validity of the terminal device ID and the pre-allocated security token; After successful authentication, the permission and version control module returns an access token, an available font ID, and a font version to the client rendering proxy module.

4. The method according to claim 1, characterized in that, Before the client rendering proxy module sends the request information to the dynamic rasterization engine, the method further includes: The local cache is queried. If the cache is hit, the cached bitmap is used directly for the terminal device to display the font.

5. The method according to claim 3, characterized in that, The request information includes character encoding, font ID, font version, font size, terminal device ID, and access token.

6. The method according to claim 5, characterized in that, After receiving the request information, the dynamic rasterization engine sends a first verification request to the permissions and version control module, including: After receiving the request information, the dynamic rasterization engine sends a first verification request to the permission and version control module based on the font ID, font version, terminal device ID and access token in the request information.

7. The method according to claim 1, characterized in that, After the dynamic rasterization engine receives the verification pass information returned by the permission and version control module, the method further includes: The dynamic rasterization engine sends a second verification request to the font asset management module based on the font ID and font version in the request information.

8. The method according to claim 5, characterized in that, After receiving the verification pass information returned by the permission and version control module, the dynamic rasterization engine generates a bitmap of the font, including: The dynamic rasterization engine obtains the vector description data corresponding to the font ID from the cloud vector description library, and generates a bitmap of the font based on the vector description data.

9. The method according to claim 7, characterized in that, The method further includes: When the font is updated, the permissions and version control module instructs the bitmap cache and the distribution network cache to invalidate the bitmap before the font update.

10. A cloud-based dynamic dot matrix font service system, characterized in that, The system includes a client rendering proxy module, a dynamic rasterization engine, a permission and version control module, a bitmap cache and distribution network, and terminal devices; The client-side rendering proxy module is integrated into the terminal device, and the dynamic rasterization engine, the permission and version control module, and the dot matrix cache and distribution network are all deployed on the cloud service platform side. The client-side rendering proxy module is used to obtain font requests sent by the terminal device; The client rendering proxy module is also used to determine request information based on the font request and send the request information to the dynamic rasterization engine; The dynamic rasterization engine is used to send a first verification request to the permission and version control module after receiving the request information; The permission and version control module is used to perform verification based on the first verification request; The dynamic rasterization engine, upon receiving the verification pass information returned by the permission and version control module, generates a bitmap of the font and sends the bitmap to the bitmap cache and distribution network. The bitmap cache and distribution network is used to cache the bitmap and send the bitmap to the client rendering proxy module for the terminal device to display the font.

Images