CN119598970B - Font processing methods, apparatus, devices and storage media - Google Patents
Font processing methods, apparatus, devices and storage mediaInfo
- Publication number
- CN119598970B CN119598970B CN202411404026.2A CN202411404026A CN119598970B CN 119598970 B CN119598970 B CN 119598970B CN 202411404026 A CN202411404026 A CN 202411404026A CN 119598970 B CN119598970 B CN 119598970B
- Authority
- CN
- China
- Prior art keywords
- file
- font
- web
- target
- virtual
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/103—Formatting, i.e. changing of presentation of documents
- G06F40/109—Font handling; Temporal or kinetic typography
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/38—Creation or generation of source code for implementing user interfaces
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Health & Medical Sciences (AREA)
- Artificial Intelligence (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Computational Linguistics (AREA)
- General Health & Medical Sciences (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application provides a font processing method, a device, equipment and a storage medium, which comprise the steps of obtaining an interface function code file comprising a desktop font file of a target application program of a desktop version, determining a packing mode and a target path mapping relation between a target source storage path of a local file system and a target virtual storage path of a virtual file system, compiling the interface function code file according to the packing mode to generate other webpage end code files and webpage end font files stored in the target source storage path, loading the webpage end font files to the virtual file system according to the other webpage end code files and the target path mapping relation, and accessing and rendering a user interface of the target application program of the webpage version based on the webpage end font files in the virtual file system in response to an access request of the target application program of the webpage end version. The method and the device ensure that the desktop end version and the webpage end version of the same application are loaded with the same fonts, and improve the interface display effect.
Description
Technical Field
The embodiment of the application relates to the technical field of computers, in particular to a font processing method, a font processing device, font processing equipment and a storage medium.
Background
An application program, which is simply referred to as an application, may include multiple running versions of the same application according to different running environments or running modes, for example, the version of the same application generally includes a desktop end version and a web page end version, that is, the same application generally includes a desktop end application and a client end application. The desktop application refers to an application directly installed on a user computer or other device, and the Web page application (or called Web application) is an application that presents a user interface and content through a browser.
Desktop applications and client applications typically have the same or corresponding functionality, e.g., desktop and web page end versions for the same application, which typically have similar or consistent styles in User Interface (UI) designs. However, the desktop application and the client application may run in different systems, and generally default to load the system fonts of the running systems, so that the loaded fonts cannot be ensured to be consistent, and further the user interface design cannot be ensured to have a consistent style, so that the interface display effect is poor, and the user experience is affected.
Disclosure of Invention
The application provides a font processing method, a device, equipment and a storage medium, which can ensure that the desktop end version and the webpage end version of the same application can load consistent fonts, have consistent user interface design styles and can improve interface display effect and user experience.
The application provides a font processing method, which comprises the steps of obtaining an interface function code file of a target application program of a desktop end version, determining a packing mode corresponding to the desktop end font file and a target path mapping relation between a target source storage path of a local file system and a target virtual storage path of a virtual file system, compiling the interface function code file according to the packing mode to generate other webpage end code files and webpage end font files stored in the target source storage path, loading the webpage end font files in the local file system into the virtual file system according to the other webpage end code files and the target path mapping relation, responding to an access request of the target application program of the webpage end version, accessing the webpage end font files in the virtual file system, and rendering a user interface of the target application program of the webpage end version based on the webpage end font files.
The application provides a font processing device, which comprises a first acquisition module, a first determination module, a file compiling module and a file loading module, wherein the first acquisition module is used for acquiring an interface function code file of a target application program of a desktop end version, the interface function code file comprises the desktop end font file, the first determination module is used for determining a packing mode corresponding to the desktop end font file and a target path mapping relation between a target source storage path of a local file system and a target virtual storage path of the virtual file system, the file compiling module is used for compiling the interface function code file according to the packing mode to generate other code files of a webpage end and the webpage end font file stored in the target source storage path, the file loading module is used for loading the webpage end font file in the local file system into the virtual file system according to the other code files of the webpage end and the target path mapping relation, and the access rendering module is used for responding to an access request aiming at the target application program of the webpage end version, accessing the webpage end font file in the virtual file system and rendering a user interface of the target application program of the webpage end version based on the webpage end font file.
In a third aspect, the application provides an electronic device comprising a processor and a memory for storing a computer program, the processor being for invoking and running the computer program stored in the memory for performing the method as in the first aspect or implementations thereof.
In a fourth aspect, the present application provides a computer-readable storage medium storing a computer program for causing a computer to perform the method as in the first aspect or implementations thereof.
In a fifth aspect, the application provides a computer program product comprising computer program instructions for causing a computer to perform the method as in the first aspect or implementations thereof.
In a sixth aspect, the application provides a computer program for causing a computer to perform the method as in the first aspect or in various implementations thereof.
According to the technical scheme, the electronic equipment can acquire the webpage end font file stored in the local file system through compiling the interface function code file comprising the desktop end font file, so that the corresponding fonts of the webpage end font file and the desktop end font file are consistent, the consistency of the fonts loaded by the target application program of the desktop version and the target application program of the webpage version is ensured, the consistency of the style on the multi-end version of the user interface design is ensured, the interface display effect and the user experience sense are improved, and the webpage end cannot directly access the local file system due to the safety and privacy consideration, so that the electronic equipment can map the webpage end font file of the local file system to the virtual file system, and render the user interface of the target application program of the webpage version based on the webpage end font file in the virtual file system, and a legal and flexible file access mode is realized.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for the description of the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a schematic view of an application scenario provided in an embodiment of the present application;
FIG. 2 is a flow chart of a font processing method according to an embodiment of the present application;
FIG. 3 is a schematic diagram of a font processing method according to an embodiment of the present application;
FIG. 4 is a schematic diagram of another font processing method according to an embodiment of the present application;
FIG. 5 is a schematic diagram of another font processing method according to an embodiment of the present application;
fig. 6 is a schematic diagram of a font processing device 600 according to an embodiment of the present application;
fig. 7 is a schematic block diagram of an electronic device 700 according to an embodiment of the present application.
Detailed Description
It should be noted that the terms "first," "second," and the like in the description and the claims of the present application and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the application described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or server that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed or inherent to such process, method, article, or apparatus, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
As described above, since the desktop application and the client application running systems under the same application program are different, the related art has the problem that fonts loaded by the desktop application and the client application are inconsistent, so that the user interface is inconsistent in design and poor in display effect, and user experience is affected.
In order to solve the technical problems, the application is characterized in that the webpage end font file stored in the local file system is obtained through compiling an interface function code file comprising a desktop end font file, the webpage end font file of the local file system is mapped to the virtual file system, and a user interface of a target application program of a webpage version is rendered based on the webpage end font file in the virtual file system.
It should be understood that the technical solution of the present application can be applied to the following scenarios, but is not limited to:
In one embodiment, the application can be applied to development of an application program or display of a scene by a user interface, and particularly can be applied to a scene of developing a user interface of a webpage end version application program or a scene of displaying fonts in the user interface of the webpage end version application program.
In one embodiment, as shown in fig. 1, the application scenario may include a terminal device 110 and a server 120, where the terminal device 110 and the server 120 may be connected through a wired network or a wireless network.
The browser on the terminal device 110 may start the target application program of the desktop version, the server 120 may obtain the interface function code file of the target application program of the desktop version, which includes the desktop font file, and obtain the web page font file stored in the local file system through compiling the interface function code file, map the web page font file of the local file system to the virtual file system, and then, the server 120 may access the web page font file in the virtual file system in response to an access request for the target application program of the web page version, and control the terminal device 110 to render the user interface of the target application program of the web page version based on the web page font file obtained by the access.
The server 120 may be a server, a server cluster formed by a plurality of servers, or a cloud platform control center, but is not limited thereto. The terminal device 110 may be a mobile phone, a tablet computer, a notebook computer, a desktop computer, or the like, but is not limited thereto.
It should be noted that the terminal device and the server in fig. 1 are only exemplary, and specifically, other numbers or types of terminal devices or servers may also be included.
In addition, the technical scheme of the application can be executed only by the terminal equipment, and in order to avoid repetition, the application does not need to describe the scheme.
After the application scenario of the embodiment of the present application is introduced, the following details of the technical solution of the present application will be described:
fig. 2 is a flowchart of a font processing method according to an embodiment of the present application, where the method may be executed by the terminal device 110 or the server 120 in the application scenario, but is not limited thereto. As shown in fig. 2, the method may include the steps of:
S210, acquiring an interface function code file of a target application program of a desktop end version, wherein the interface function code file comprises a desktop end font file;
S220, determining a packing mode corresponding to the desktop font file and a target path mapping relation between a target source storage path of the local file system and a target virtual storage path of the virtual file system;
s230, compiling the interface function code file according to a packaging mode to generate other code files of a webpage end and a webpage end font file stored in a target source storage path;
s240, loading the webpage end font file in the local file system into the virtual file system according to the other code files of the webpage end and the target path mapping relation;
S250, responding to an access request of the target application program aiming at the webpage end version, accessing the webpage end font file in the virtual file system, and rendering a user interface of the target application program of the webpage end version based on the webpage end font file.
The interface function code file refers to a code file for defining and implementing user interface related functions of a target application program of a desktop end version. The User Interface related function may be a function related to User Interface (UI) interaction or display, but is not limited thereto. For example, the function may be a function related to a font of a text displayed on the user interface, a font used for drawing a chart, or the like.
Specifically, the interface function code file may include a desktop font file. The desktop font file refers to a file for displaying fonts to be displayed on a user interface of a target application program, and may include specific resources required for loading fonts on the user interface by the target application program, for example, specific resource information for specifying fonts, sizes, and styles (bold, italics, etc.) of the fonts. The target application of the desktop end version can render a user interface according to the desktop end font file, and display various text, charts or image contents.
The desktop end may be a desktop end running based on a Windows, mac, linux system or the like, but is not limited thereto.
The programming language used to develop the above-described interface function code file may be, but is not limited to, C language, c++ language, rust language.
The desktop font file may be a file associated with a native custom font of the target application of the desktop version.
In one embodiment, the electronic device may determine all code files of the desktop end version of the target application, then may locate the interface function code files in the all code files via the command line tool, and finally may extract the interface function code files directly from the all code files (e.g., copy the interface function code files directly from the all code files), so that the interface function code files may be obtained.
The electronic equipment can firstly determine the file name, the file type, the character string or the function and the like related to the interface function code file, then take the file name, the file type, the character string or the function as the search parameter of the command line tool, and then can work in all code files through the command line with the search parameter set to locate the interface function code file.
Command line tools, including but not limited to find commands, locate commands, grep commands.
It should be noted that, for safety and privacy reasons, the web page end cannot directly access the local file system, but the web page end font file determined according to the interface function code file is generally directly generated in the local file system (for example, the generated web page end font file is stored in the target source storage path of the local file system by default), so the electronic device needs to determine the virtual file system in advance, and store the generated web page end font file in the virtual file system, and then, the web page end can realize normal access to the web page end font file through the virtual file system.
In addition, the electronic device can package the desktop font file before storing the webpage font file in the virtual file system, so as to reduce the file size and simplify resource management, and meanwhile, the obtained webpage font file can be conveniently loaded/operated on the webpage, and the loading/operating system corresponding to the webpage can be better compatible.
The application will be described in the following embodiments with respect to the packing and compiling of desktop-side font files and virtual file systems:
In one embodiment, the desktop font file includes 2 types of packaging modes, namely an asynchronous packaging mode (preload mode) and a synchronous packaging mode (emud mode).
The asynchronous packing mode means that other code files of the webpage end and font files of the webpage end are obtained by mutually independent packing, namely, the other code files of the webpage end and the font files of the webpage end obtained by packing are independent and separated, so that the obtained other code files of the webpage end are small in size, and the webpage end font files can be conveniently loaded according to the other code files of the webpage end.
The synchronous packing mode is that the webpage end font file is embedded into other webpage end code files in the packing process, namely, the webpage end other code files and the webpage end font file obtained by packing are contained in one file, so that the obtained webpage end other code files are large in size, and the webpage end font file is not convenient to load according to the webpage end other code files later compared with the asynchronous packing mode.
Therefore, the electronic device can determine the other code files and font files of the webpage end according to the asynchronous packaging mode, so that the file size of the generated other code files of the webpage end is reduced, the subsequent loading process for the font files of the webpage end is facilitated, and the loading speed and efficiency are improved. Of course, other code files and font files at the web page end can be determined according to the synchronous packaging mode, and the application is not limited to this.
In one embodiment, the electronic device may package the interface function code file during the compiling of the interface function file, or the electronic device may separately compile and package the interface function code file, for example, after compiling the interface function code file, the compiling result file (e.g., the other code file at the web page end and the font file at the web page end) may be packaged. The application does not limit the order of packaging and compiling.
For example, the electronic device may compile the interface function code file using a compiler. Specifically, the compiler may be a Wasm technology-based compiler. For example, it may be a EMSCRIPTE NSDK-based compiler, or it may also be a Binaryen tool chain, wasmEdge, etc., but is not limited thereto.
Wherein the electronic device may compile and package the interface function code file according to the EMSCRIPTEN SDK-based compiler.
In addition, the electronic device may also use an automated build system to control the compilation process to achieve more efficient compilation. For example, the automated build system may be a CMake system, but is not limited thereto. The electronic device can control the compiling of the interface function code files by using the configuration files through an automatic construction system, for example, engineering configurations of different platforms can be achieved through conditional compiling provided by CMake systems, so that the code multiplexing is realized as much as possible.
The automatic construction system for controlling the process of compiling the interface function code file can be an automatic construction system used when compiling a target application program of a desktop end version, so that compatibility and controllability of a compiling process and a code file obtained by compiling and generating can be improved.
For example, for a manner in which compiling and packaging are performed separately, the electronic device may use a separate packaging script to package the file compiled for the interface function code file. In particular, the package script may be a scripting tool in EMSCRIPTENSDK, and may be, but is not limited to, file_package.
In one embodiment, a virtual file system is a file system that does not exist in reality, and is a virtual file system whose directory structure and storage path are also virtual. Wherein the path hierarchy of the virtual file system is consistent with the path hierarchy of the local file system.
By way of example, the virtual file system may be MEMFS (Memory FILE SYSTEM), and the ME MFS is a virtual file system provided by EMSCRIPTEN, which allows files to be stored in Memory, rather than directly on a hard disk, thus facilitating the simulation of the input and output of files in a Web environment, i.e., on the Web page side.
In addition, the virtual file system may be a proc file system or NFS (network file system), but is not limited thereto.
In one embodiment, after determining the web page side font file, the electronic device may generate a target virtual storage path of the virtual file system for storing the web page side font file later, where a path level of the target virtual storage path and a path level of the target source storage path are consistent.
It should be noted that, in the following embodiments, the storage path mapping between the virtual file system and the local file system and the target path mapping relationship between the target source storage path and the target virtual storage path will be described, and in order to avoid repetition, the description of the present application is omitted here.
In one embodiment, in combination with the above embodiment, the electronic device may control the compilation process by an automated build system (e.g., CMake compilation) and package during the compilation process, as will be described in the following embodiments:
Specifically, compiling the interface function code file according to the packaging mode to generate other code files at the web page end and font files at the web page end stored in the target source storage path may include the following steps:
s230-1, constructing compiling parameters according to the packing mode and the target path mapping relation.
The compiling parameters are parameters for controlling the compiling process of the interface function code file of the desktop application program. Specifically, after the packing mode and the target path mapping relation are obtained, a corresponding packing label can be generated based on the packing mode, a target virtual storage path is determined according to the target path mapping relation, and then compiling parameters are constructed according to the packing label and the target virtual storage path.
The packing label is a label for uniquely identifying the packing mode, for example, if the packing mode is an asynchronous packing mode, the packing label may be "- -preload-file", and if the packing mode is a synchronous packing mode, the packing label may be "- -ebed-file".
The target path mapping relationship may include a target virtual storage path and a mapping symbol, where the mapping symbol is a symbol for identifying a step of mapping a source storage path of the local file system to a virtual storage path of the virtual file system, and for example, the mapping symbol may be "@/". The target virtual storage path may refer to a particular hierarchy of virtual directories of the virtual file system.
When the compiling parameters are constructed according to the packing labels and the target virtual storage paths, the packing labels, the target virtual storage paths and the mapping symbols can be combined, or the packing labels and the target virtual storage paths can be combined to obtain the compiling parameters.
Specifically, assuming that the packing mode is an asynchronous packing mode, the target path mapping relationship includes: the specific hierarchy (i.e., target virtual storage path) and mapping notation of the virtual directory that needs to be mapped to the virtual file system, then the compilation parameters may be: -preload-file/fonts @/, wherein "-preload-file" indicates that the packaging is asynchronous; the method includes the steps of "@/"/fonts@indicates a target path mapping relation ","/fonts "indicates a target virtual storage path", "@/" is a mapping symbol indicating that a source storage path of a local file system needs to be mapped to the virtual file system, and "/" in "@/" indicates a root directory default when the virtual file system runs.
The relative path may be used to represent the target virtual storage path, and specifically, the initial path on which the relative path is based may be a path where a script file generated by any engineering after compiling by the automated building system is located, for example, the initial path on which the relative path is based may be a path where a Makefile file generated by different engineering after compiling by cmake is located.
For example, as shown in fig. 3, assume that the generated webpage end font file needs to be mapped and stored in fonts folder, that is, the target virtual storage path is the path corresponding to fonts folder; the path where the Makefile is located is "M/Src/build/FTMain/MainApp", and as can be seen from fig. 3, there are fonts folders in the upper four layers of folders where the Makefile is located, so it can be determined that the target virtual storage path represented by the relative path is: "/fonts".
S230-2, configuring the compiling parameters in the engineering configuration files corresponding to the interface function code files through the parameter configuration commands.
Specifically, in combination with the above, the engineering configuration file may be a configuration file in which an executable file may be generated from a configuration file named "cmakelist.
Correspondingly, the parameter configuration command can be target_link_libraries (), and the compiling parameter is configured in the engineering configuration file corresponding to the interface function code file through the parameter configuration command, which can be specifically:
the code of target_link_lists ($ { process_name } PUBLIC "- -preload-file./. Times./fonts@/") is added to the PROJECT profile.
S230-3, in response to the packaging mode being an asynchronous packaging mode, compiling the interface function code files is controlled through the engineering configuration file, and other code files of the webpage end and font files of the webpage end, which are obtained through mutually independent packaging, and the webpage end font files stored in the target source storage path are generated.
Correspondingly, the compiling of the interface function code file is controlled through the engineering configuration file, specifically, the compiling of the interface function code file is controlled through the running control of the newly added code, namely, the parameter configuration command, namely, the engineering configuration file, specifically, the compiling is controlled to realize the packaging according to an asynchronous packaging mode in the compiling process, and other code files of the webpage end and the webpage end font file stored in the target source storage path are generated independently.
The process of automatically mapping the webpage-side font file stored in the target source storage path to the target virtual storage path of the virtual file system can be controlled, and the storage mapping process of the webpage-side font file will be described in the following embodiments.
In one embodiment, the other code files of the webpage end can comprise webpage script files and glue layer code files.
The webpage script file comprises a label for referencing the glue layer code file, and the glue layer code file can be loaded and executed through the label so as to realize automatic execution of the glue layer code file. Specifically, the web script file may be text.
The glue layer code file is used for loading the webpage end font file, and can trigger a loading interface of the virtual file system to load the webpage end font file in the local file system into the virtual file system. Specifically, the glue layer code file may be test.
In addition, the webpage end code file may further include a test.wasm file, where the test.wasm file refers to some binary files generated by compiling the interface function code file with EMSCRIPTEN.
In one embodiment, as shown in fig. 4, the loading the font file at the web page end in the local file system into the virtual file system according to the mapping relationship between the other code files at the web page end and the target path may include the following steps:
s240-1, running a webpage script file;
S240-2, loading and executing the glue layer code file through a tag referencing the glue layer code file in the webpage script file;
The web page script file may include the tag referencing the glue layer code file, and if the web page script file is executed, the glue layer code file may be automatically loaded and executed in response to the analysis of the tag when the tag is executed and analyzed.
S240-3, triggering a loading interface of the virtual file system through the glue layer code file;
The loading interface may be fs.createpoloadedfile, as shown in fig. 4.
In particular, the glue layer code file may include calls to a virtual file system load interface that may operate the virtual file system, e.g., may enable input and output to the virtual file system (i.e., re-reading or writing data from the virtual file system).
S240-4, loading the webpage font file in the local file system into the virtual file system through the loading interface and the target path mapping relation.
The web page font file may be a test. It can be understood that the compiling of the interface function code file is controlled through the engineering configuration file, so that the desktop end font file in the interface function code file is saved in the webpage end font file such as the data file, and the file path of the font file is mapped into the target source storage path.
Specifically, in combination with the above embodiment, the electronic device may control the above S240-4 through the engineering configuration file, so as to complete the mapping of the storage path for the font file at the web page end, and implement the connection between the web page end and the local file system, so that the web page end may use, through the virtual file system, the resources stored in the local file system, for example, the font file at the web page end, thereby improving the user experience and performance at the web page end.
It can be understood that before accessing the font file at the web page end in the virtual file system, that is, before executing S250, the electronic device may determine the function conversion relationship corresponding to each of the file system and the font file (for example, the function conversion relationship between the file operation functions corresponding to each of the font file at the web page end in the desktop end and the virtual file system) and the path mapping relationship between the virtual file system and the local file system (including, but not limited to, the target path mapping relationship between the target source storage path of the local file system and the target virtual storage path of the virtual file system, that is, the target path mapping relationship in S220 above), so that, when the virtual file system is accessed subsequently, the electronic device may directly access the file operation functions and the source storage path used when accessing the local file system according to the function conversion relationship and the path mapping relationship, and may automatically convert the function conversion relationship into the file operation functions corresponding to the virtual file system and the virtual storage path, and access the virtual file system, thereby achieving the same effect of directly accessing the local file system, and improving the accessing efficiency and user experience.
In addition, various operations for the virtual file system may be implemented, for example, obtaining a file path, reading a file, writing a file, etc. in the virtual file system, so that the web page-side font file can be mapped and stored (i.e., loaded) into the virtual file system, i.e., the above S240 is performed.
Specifically, the electronic device may determine the function conversion relationship and the path mapping relationship in the process of compiling the interface function code file, which is not limited in the present application.
The following describes the function conversion relation of the file operation function and the path mapping relation of the storage path:
in one embodiment, the electronic device may first obtain a desktop side file operation function for the desktop side font file, then convert the desktop side file operation function into a web side file operation function for interacting with the virtual file system to obtain a function conversion relationship, and finally define the web side file operation function in a function library of the virtual file system to access the virtual file system through the function library.
The web page side file operation function can achieve similar functions as accessing the local text system through the desktop side file operation function by calling a corresponding interface in the virtual file system, such as opening a file, reading a file or writing a file.
By way of example, in connection with FIG. 5, assuming that the desktop side font file is a C/C++ file, the electronic device may call the desktop side font file operation interface to operate the desktop side font file through a desktop side file operation function, where the desktop side file operation function may include fopen, fread, and fwrite, where "fope n" is used to open the file, "fread" is used to read the file or data in the file, and "fwrite" is used to write the file or write the data in the file.
Specifically, "fopen", "fread", "fwrite" can be respectively converted into web page side file operation functions, namely open function, read function and write function, for interacting with the virtual file system. The open function may call the fs.open interface of the virtual file system to open a file in the virtual file system, or create a file stream, obtain a file path fs.ge tPath, etc., the read function may call the fs.read interface of the virtual file system to read a file or data in a file, etc., and the write function may call the fs.write interface of the virtual file system to write a file or write data in a file, etc.
Correspondingly, the function conversion relation can comprise a webpage end file operation function and a desktop end file operation function which are in one-to-one correspondence. For example, the functional conversion relationship may be:
(fopen, open function; fread, read function; fwrite, write function).
The web page side file operation function may then be defined in a function library of the virtual file system by the compiler, after which the virtual file system may be accessed by the web page side file operation function in the function library. As shown in FIG. 5, the library of functions of the virtual file system may be library_fs.js.
In addition, the function conversion relation can be defined in the function library, so that the desktop side file operation function can be automatically converted into the webpage side file operation function based on the function library according to the function conversion relation, the same effect as that of directly accessing the local file system is achieved, and the access efficiency and the user experience are improved.
In addition, as shown in FIG. 3, the compiler may also include a virtual file system, a C standard library (libc), and a C++ standard library (libcxx). The C standard library and the C++ standard library provide basic functions (such as the desktop side file operation functions) and classes required by the operation of the interface function code file, so that the functions and the classes are specially adapted, packaged and converted in the compiled interface function code file, and the subsequently generated desktop side font file is determined to be used for correctly operating in the webpage side environment.
In one embodiment, the electronic device may obtain a plurality of source storage paths of a file generated by compiling the interface function code file in the local file system, and map the plurality of source storage paths to a plurality of virtual storage paths in the virtual file system to obtain a path mapping relationship, where the path mapping relationship includes a target path mapping relationship, and a path hierarchy of the virtual file system is consistent with a path hierarchy of the local file system.
The virtual storage path may be represented by using a relative path, and specifically, reference may be made to the representation of the target virtual storage path.
Illustratively, assume that the storage path under the Wasm file under the virtual storage path corresponds to: fon/aaa ttf, if the source storage path is ".//Wasm", it may be mapped to a virtual storage path "/"; if the source storage path is "/Wasm/font", it may be mapped to a virtual storage path "/font"; if the source storage path is "/v./Wasm/font/bbb. Ttf", it may be mapped to a virtual storage path "/font/bbb. Ttf".
Correspondingly, the path mapping relation can comprise a source storage path and a virtual storage path which are in one-to-one correspondence. For example, the path mapping relationship may be:
("../../../../Wasm","/";"../../../../Wasm/font","/font";"../../../../Wasm/font/AAA.ttf","/font/BBB.ttf").
The following description will be given of a process of rendering a user interface of a target application program of a web page end version based on a web page end font file in a virtual file system, namely, S250 described above:
in one embodiment, the electronic device may implement S250 above by:
s250-1, obtaining a target source storage path and a desktop end font adding function corresponding to the desktop end font file in the desktop end file operation function.
Specifically, the electronic device may obtain the target source storage path and the desktop font addition function in response to an opening operation of a user interface for the target application program of the web page end version.
Illustratively, the target source storage path and desktop font addition function obtained by the electronic device may be ADD (str./Wasm/font); where "ADD ()" is a desktop font addition function, "./ Wasm/font" indicates a target source storage path.
It should be noted that, the electronic device may be a terminal device running a target application program of a web page end version, or may be a server corresponding to the terminal device.
In addition, the electronic device may set an add return function, and if adding the webpage-side font corresponding to the webpage-side font file fails, the value "-1" may be returned by adding the return function, and no subsequent operation is performed (e.g., S250-5). If the addition of the webpage end font corresponding to the webpage end font file is successful, a subsequent operation is performed (e.g., S250-5). That is, whether the addition of the webpage-side font corresponding to the webpage-side font file is successful may be determined by adding the return function.
S250-2, converting the desktop font adding function into a webpage font adding function in a webpage file operation function according to the function conversion relation, and mapping the target source storage path into a target virtual storage path according to the path mapping relation.
For example, in combination with the above embodiment, assuming that the web page end font adding function corresponding to the desktop end font adding function "ADD ()" in the function conversion relationship is "ADD", the electronic device may determine that the target virtual storage path is "/font" and the web page end font adding function is "ADD".
S250-3, accessing the virtual file system through the function library and the target virtual storage path, and obtaining the webpage font file in the virtual file system.
The electronic device may determine that a desktop font adding function has been defined in the function library, call an interface corresponding to the desktop font adding function in the virtual file system through the function library, and obtain a webpage font file from a target virtual storage path in the virtual file system through the interface.
S250-4, determining the webpage end fonts corresponding to the webpage end font files.
Specifically, the electronic device may identify a specific resource included in the webpage-side font file, for example, a font shape, a size, and a style (bold, italic, etc.) of the font, and then determine the webpage-side font according to the specific resource. For example, the webpage-side fonts can be bold regular script fonts.
The display effect of the webpage end fonts corresponding to the webpage end font files in the webpage end is consistent with the display effect of the desktop end fonts corresponding to the desktop end font files in the desktop end.
S250-5, setting the webpage fonts in the font examples of the user interface, and rendering the user interface through the font examples.
Specifically, the electronic device may set the webpage end font in a font instance of the user interface, and render the user interface through the font instance by:
step one, adding the webpage end fonts into a font database of a target application program of the webpage end version, wherein the font database is used for managing the fonts.
The font database may store a plurality of fonts, and the plurality of fonts may be all fonts related to the target application program of the webpage end version. Through the font database, multiple fonts can be more securely (e.g., ensuring that fonts subsequently displayed on the user interface are authorized for use) and more intensively managed, and maintainability and accessibility of the fonts can be improved.
And step two, acquiring a font family corresponding to the webpage end fonts in the webpage end font file.
The font family is a group of fonts with similar design styles and containing different styles (such as bold, italic and the like), and can ensure that the fonts are harmonious and unified visually. The font family may be included in a webpage-side font file, and may include a set of fonts with different styles and similar design styles in the same user interface.
Setting the webpage end fonts in the font database in a font instance according to the font family, and rendering the user interface through the font instance.
In particular, fonts in the font family and the webpage-side fonts in the font database may be together arranged in the font instance to provide a consistent visual style for the user interface when the user interface displays different display elements, where some display elements may be displayed based on the webpage-side fonts and some display elements may be displayed based on fonts having similar design styles and different styles (i.e., fonts in the font family) than the webpage-side fonts.
The font instance may define elements and execution steps required for displaying the font at the web page end in the user interface, for example, the font instance may include a name of the font to be displayed at the web page end (for example, a font name of the font in the web page end font and the font family), a storage path of each font to be displayed (for example, the target virtual path or a path of the font in the font database), and an execution step for displaying the font to be displayed. The executing step can be that the storage path of each font to be displayed is determined according to the name of the font to be displayed, the corresponding font is obtained according to the storage path of each font to be displayed, and the corresponding display element (for example, a section of text or title in the user interface) in the user interface is loaded and rendered according to the corresponding font.
Specifically, the user interface is rendered through the font instance, which can be understood as that display elements based on the font display at the web page end are displayed in the user interface through the font instance. That is, display elements in the user interface are displayed by fonts and executing steps involved in the font instance.
Further, if the electronic device fails to add/set fonts in the instance, a log may be recorded.
In one embodiment, the electronic device may first obtain an interface function code file of the desktop-side version of the target application, where the interface function code file includes a desktop-side font file.
The electronic device can acquire a desktop side file operation function aiming at the desktop side font file, convert the desktop side file operation function into a webpage side file operation function for interacting with the virtual file system to obtain a function conversion relation, and define the webpage side file operation function in a function library of the virtual file system so as to access the virtual file system through the function library.
In addition, the electronic device can acquire a plurality of source storage paths of the file generated after compiling the interface function code file in the local file system, map the plurality of source storage paths into a plurality of virtual storage paths in the virtual file system to obtain a path mapping relation, wherein the path mapping relation comprises a target path mapping relation, and the path level of the virtual file system is consistent with the path level of the local file system.
The electronic device may then determine a packing manner (e.g., an asynchronous packing manner) corresponding to the desktop-side font file, and determine a storage location of the web-side font file generated after compiling the interface function code file, that is, a target source storage path of the local file system.
Then, the electronic device can compile the interface function file, and package the interface function code file based on an asynchronous package mode in the compiling process to obtain other code files of the webpage end and font files of the webpage end stored in the target source storage path, which are obtained by mutually independent package. The electronic equipment can generate a corresponding packing label based on an asynchronous packing mode, determine a target virtual storage path according to a target path mapping relation and a target source storage path, combine the packing label corresponding to the asynchronous packing mode and the target virtual storage path to obtain compiling parameters, configure the compiling parameters into engineering configuration files corresponding to interface function code files in an automatic construction system through parameter configuration commands, control compiling of the interface function code files through the engineering configuration files of the automatic construction system, and generate webpage end other code files obtained by mutually independent packing and webpage end font files stored in the target source storage path. The other code files of the webpage end can comprise webpage script files and glue layer code files.
The electronic equipment can run the webpage script file, load and execute the glue layer code file through the label of the glue layer code file referenced in the webpage script file, trigger the loading interface of the virtual file system through the glue layer code file, and load the webpage end font file stored in the target source storage path into the target virtual storage path in the virtual file system through the loading interface and the target path mapping relation.
Finally, in response to an access request of a target application program aiming at a webpage end version, the electronic equipment can acquire a target source storage path and a desktop end font adding function corresponding to a desktop end font file in a desktop end file operation function, convert the desktop end font adding function into a webpage end font adding function in the webpage end file operation function according to a function conversion relation, map the target source storage path into a target virtual storage path according to a path mapping relation, call an interface corresponding to the desktop end font adding function in a virtual file system through a function library, acquire a webpage end font file from the target virtual storage path in the virtual file system through the interface, then can determine a webpage end font corresponding to the webpage end font file, add the webpage end font into a font database of the target application program of the webpage end version, wherein the font database is used for managing fonts, acquire a font family corresponding to the webpage end in the webpage end font file, and set the webpage end in the font database in a font instance according to the family, and pass through a font instance user interface.
It should be noted that, in all the above technical solutions, any combination may be adopted to form an optional embodiment of the present application, which is not described herein in detail.
It should be noted that, in the specific embodiment of the present application, related data such as code files, storage paths, packaging manners, and operation functions are related, when the embodiment of the present application is applied to a specific product or technology, permission, consent, or authorization of a user needs to be obtained, and collection, use, and processing of related data need to comply with related laws and regulations and standards of related countries and regions.
Fig. 6 is a schematic diagram of a font processing device 600 according to an embodiment of the present application. As shown in fig. 6, the apparatus 600 includes a first obtaining module 601, a first determining module 602, a file compiling module 603, a file loading module 604, an access rendering module 605, a second obtaining module 606, a function conversion module 607, a function definition module 608, a third obtaining module 609, and a path mapping module 610.
In one embodiment, a first obtaining module 601 is configured to obtain an interface function code file of a target application program of a desktop end version, where the interface function code file includes a desktop end font file, a first determining module 602 is configured to determine a packing manner corresponding to the desktop end font file and a target path mapping relationship between a target source storage path of a local file system and a target virtual storage path of a virtual file system, a file compiling module 603 is configured to compile the interface function code file according to the packing manner, generate a web end other code file and a web end font file stored in the target source storage path, a file loading module 604 is configured to load the web end font file in the local file system into the virtual file system according to the web end other code file and the target path mapping relationship, and an access rendering module 605 is configured to access the web end font file in the virtual file system in response to an access request for the target application program of the web end version, and render a user interface of the target application program of the web end version based on the web end font file.
In one embodiment, the file compiling module 603 is specifically configured to construct compiling parameters according to a packing mode and a target path mapping relationship, configure the compiling parameters in an engineering configuration file corresponding to an interface function code file through a parameter configuration command, and control compiling of the interface function code file through the engineering configuration file in response to the packing mode being an asynchronous packing mode to generate other code files of a web page end and a font file of the web page end, wherein the other code files are obtained by mutually independent packing, and the font file of the web page end is stored in a target source storage path.
In one embodiment, the other code files of the webpage end comprise a webpage script file and a glue layer code file, wherein the webpage script file comprises a tag for referencing the glue layer code file, the glue layer code file is used for loading the webpage end font file, the file loading module 604 is specifically used for running the webpage script file, loading and executing the glue layer code file through the tag for referencing the glue layer code file in the webpage script file, triggering a loading interface of the virtual file system through the glue layer code file, and loading the webpage end font file in the local file system into the virtual file system through the loading interface and the target path mapping relation.
In one embodiment, the second obtaining module 606 is configured to obtain a desktop side file operation function for the desktop side font file, the function conversion module 607 is configured to convert the desktop side file operation function into a web side file operation function for interacting with the virtual file system to obtain a function conversion relationship, and the function definition module 608 is configured to define the web side file operation function in a function library of the virtual file system to access the virtual file system through the function library.
In one embodiment, the third obtaining module 609 is configured to obtain a plurality of source storage paths where a file generated after compiling the interface function code file is located in the local file system, and the path mapping module 610 is configured to map the plurality of source storage paths to a plurality of virtual storage paths in the virtual file system, so as to obtain a path mapping relationship, where the path mapping relationship includes a target path mapping relationship, and a path level of the virtual file system is consistent with a path level of the local file system.
In one embodiment, the access rendering module 605 is specifically configured to obtain a target source storage path and a desktop font adding function corresponding to a desktop font file in the desktop file operation function, convert the desktop font adding function into a web page font adding function in the web page file operation function according to a function conversion relationship, map the target source storage path into a target virtual storage path according to a path mapping relationship, access a virtual file system through a function library and the target virtual storage path, obtain a web page font file in the virtual file system, determine a web page font corresponding to the web page font file, set the web page font in a font instance of the user interface, and render the user interface through the font instance.
In one embodiment, the access rendering module 605 is specifically configured to add a webpage end font to a font database of a target application program of a webpage end version, where the font database is configured to manage the font, obtain a font family corresponding to the webpage end font in the webpage end font file, set the webpage end font in the font database in a font instance according to the font family, and render a user interface through the font instance.
It should be understood that apparatus embodiments and method embodiments may correspond with each other and that similar descriptions may refer to the method embodiments. To avoid repetition, no further description is provided here. Specifically, the apparatus 600 shown in fig. 6 may perform the above method embodiments, and the foregoing and other operations and/or functions of each module in the apparatus 600 are respectively for implementing the corresponding flows in each method, which are not described herein for brevity.
The apparatus 600 of the embodiment of the present application is described above in terms of functional modules in conjunction with the accompanying drawings. It should be understood that the functional module may be implemented in hardware, or may be implemented by instructions in software, or may be implemented by a combination of hardware and software modules. Specifically, each step of the method embodiment in the embodiment of the present application may be implemented by an integrated logic circuit of hardware in a processor and/or an instruction in a software form, and the steps of the method disclosed in connection with the embodiment of the present application may be directly implemented as a hardware decoding processor or implemented by a combination of hardware and software modules in the decoding processor. Alternatively, the software modules may be located in a well-established storage medium in the art such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, and the like. The storage medium is located in a memory, and the processor reads information in the memory, and in combination with hardware, performs the steps in the above method embodiments.
Fig. 7 is a schematic block diagram of an electronic device 700 according to an embodiment of the present application.
As shown in fig. 7, the electronic device 700 may include:
a memory 710 and a processor 720, the memory 710 being configured to store a computer program and to transfer the program code to the processor 720. In other words, the processor 720 may call and run a computer program from the memory 710 to implement the method in the embodiment of the present application.
For example, the processor 720 may be configured to perform the above-described method embodiments according to instructions in the computer program.
In some embodiments of the application, the processor 720 may include, but is not limited to:
A general purpose Processor, digital signal Processor (DIGITAL SIGNAL Processor, DSP), application SPECIFIC INTEGRATED Circuit (ASIC), field programmable gate array (Field Programmable GATE ARRAY, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like.
In some embodiments of the application, the memory 710 includes, but is not limited to:
Volatile memory and/or nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable EPROM (EEPROM), or a flash Memory. The volatile memory may be random access memory (Random Access Memory, RAM) which acts as external cache memory. By way of example, and not limitation, many forms of RAM are available, such as static random access memory (STATIC RAM, SRAM), dynamic random access memory (DYNAMIC RAM, DRAM), synchronous Dynamic Random Access Memory (SDRAM), double data rate Synchronous dynamic random access memory (Double DATA RATE SD RAM, DDR SDRAM), enhanced Synchronous dynamic random access memory (ENHANCED SDR AM, ESDRAM), synchronous link dynamic random access memory (SYNCH LINK DRAM, SL DRAM), and Direct memory bus RAM (DR RAM).
In some embodiments of the application, the computer program may be partitioned into one or more modules that are stored in the memory 710 and executed by the processor 720 to perform the methods provided by the application. The one or more modules may be a series of computer program instruction segments capable of performing the specified functions, which are used to describe the execution of the computer program in the electronic device.
As shown in fig. 7, the electronic device may further include:
a transceiver 730, the transceiver 730 being connectable to the processor 720 or the memory 710.
The processor 720 may control the transceiver 730 to communicate with other devices, and in particular, may send information or data to other devices or receive information or data sent by other devices. Transceiver 730 may include a transmitter and a receiver. Transceiver 730 may further include antennas, the number of which may be one or more.
It will be appreciated that the various components in the electronic device are connected by a bus system that includes, in addition to a data bus, a power bus, a control bus, and a status signal bus.
The present application also provides a computer storage medium having stored thereon a computer program which, when executed by a computer, enables the computer to perform the method of the above-described method embodiments. Alternatively, embodiments of the present application also provide a computer program product comprising instructions which, when executed by a computer, cause the computer to perform the method of the method embodiments described above.
When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the computer can fully or partially execute the corresponding processes in the methods in the embodiments of the application and generate the functions that can be realized by the methods in the embodiments of the application. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line (Digit al Subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (Digital Video Disc, DVD)), or a semiconductor medium (e.g., solid state disk (Solid STATE DISK, SSD)), etc.
Those of ordinary skill in the art will appreciate that the various illustrative modules and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the several embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, and for example, the division of the modules is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple modules or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or modules, which may be in electrical, mechanical, or other forms.
The modules illustrated as separate components may or may not be physically separate, and components shown as modules may or may not be physical modules, i.e., may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. For example, functional modules in various embodiments of the present application may be integrated into one processing module, or each module may exist alone physically, or two or more modules may be integrated into one module.
Claims (9)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202411404026.2A CN119598970B (en) | 2024-10-09 | 2024-10-09 | Font processing methods, apparatus, devices and storage media |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202411404026.2A CN119598970B (en) | 2024-10-09 | 2024-10-09 | Font processing methods, apparatus, devices and storage media |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN119598970A CN119598970A (en) | 2025-03-11 |
| CN119598970B true CN119598970B (en) | 2025-12-16 |
Family
ID=94831355
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202411404026.2A Active CN119598970B (en) | 2024-10-09 | 2024-10-09 | Font processing methods, apparatus, devices and storage media |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN119598970B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114218890A (en) * | 2021-12-09 | 2022-03-22 | 北京百度网讯科技有限公司 | Page rendering method and device, electronic equipment and storage medium |
| CN117667084A (en) * | 2022-09-06 | 2024-03-08 | 腾讯科技（深圳）有限公司 | Page display method, device, equipment and storage medium |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115168774B (en) * | 2022-07-28 | 2025-08-19 | 济南浪潮数据技术有限公司 | Webpage rendering method, webpage rendering system, electronic equipment and computer readable storage medium |
| CN115758021A (en) * | 2022-11-17 | 2023-03-07 | 百度(中国)有限公司 | Webpage rendering method and device, electronic equipment and medium |
| CN118467056A (en) * | 2024-05-16 | 2024-08-09 | 天地（常州）自动化股份有限公司 | Mobile terminal APP embedded configuration graph rendering method, equipment and storage medium thereof |
-
2024
- 2024-10-09 CN CN202411404026.2A patent/CN119598970B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114218890A (en) * | 2021-12-09 | 2022-03-22 | 北京百度网讯科技有限公司 | Page rendering method and device, electronic equipment and storage medium |
| CN117667084A (en) * | 2022-09-06 | 2024-03-08 | 腾讯科技（深圳）有限公司 | Page display method, device, equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN119598970A (en) | 2025-03-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9161156B2 (en) | Tiles in a mobile application framework | |
| KR101424303B1 (en) | A method for providing a thin client software development environment, a method for sharing a server-based software development project, and a computer-readable medium | |
| US20170277524A1 (en) | Dynamic container deployment with parallel conditional layers | |
| WO2018095306A1 (en) | Method and device for processing application program page, and storage medium | |
| CN111740948A (en) | Data package release method, dynamic update method, apparatus, device and medium | |
| CN104636139A (en) | Visualized cross-platform mobile application development and generation system | |
| CN112835568B (en) | A project construction method and device | |
| CN110895471A (en) | Installation package generation method, device, medium and electronic equipment | |
| CN105786562A (en) | Method and device for integrating plug-in | |
| CN115629763A (en) | Target code generation method and NPU instruction display method and device | |
| US11347523B2 (en) | Updated shared library reloading without stopping the execution of an application | |
| US20080196009A1 (en) | Apparatus and method for componentizing legacy system | |
| CN112087370A (en) | Method, system, electronic device and computer-readable storage medium for issuing GitHub Issues | |
| CN114115871A (en) | Page data embedding method and device, storage medium and electronic equipment | |
| CN116150527A (en) | Component style isolation method, device, equipment, storage medium and product | |
| CN119598970B (en) | Font processing methods, apparatus, devices and storage media | |
| CN114911541A (en) | Configuration information processing method and device, electronic equipment and storage medium | |
| US10394610B2 (en) | Managing split packages in a module system | |
| CN112379885B (en) | Mini-program compilation method, device, equipment and readable storage medium | |
| CN112612531B (en) | Application program starting method and device, electronic equipment and storage medium | |
| CN118567996A (en) | Page automation test method and device, electronic equipment and medium | |
| CN114880632B (en) | Method for obtaining obfuscated resources, intelligent terminal and computer-readable storage medium | |
| CN119998786A (en) | Automatic packaging tool with guidance from example commands | |
| CN111596997B (en) | UI information request method, device, terminal and storage medium | |
| CN117453223A (en) | Image file generation method and device of operating system, computer equipment and medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |