A printing system, device and method directly driven by Microsoft system

Abstract

The present application discloses a printing system, device and method directly driven by a Microsoft system, providing a series of interface functions specified by DDI for GDI to call, and implementing a printer control language in these functions to drive the printer to work. Unlike other display device drivers, the printer driver does not directly manipulate the hardware, but sends the data stream to the spool component, and the GDI call is passed to the GDI graphics engine, which processes the drawing instructions offline into an EMF file (enhanced metafile) or directly connects to the printer driver, and then passes the print image to the spool system, and the spool component sends the data to the corresponding port and finally to the printer device; the present invention directly drives the printer in the Microsoft system (without using the original driver), realizes a simple, efficient and targeted printing output function, and gets rid of the dependence on the printer brand and its driver.

Description

Technical Field

[0001] The present application relates to the field of printers, and more particularly to a printing system, device and method directly driven by a Microsoft system. Background Art

[0002] The printer driver is a device that supports various operating systems including (95, 98, 2000, 2003, XP, Vista, Win7, Win10) and integrates more than 90% of the printer drivers on the market;

[0003] Although Microsoft has provided a universal printer driver to simplify the development of printer drivers (or control software), the universal printer driver has a complex structure and there are implicit dependencies between the components. Referring to the published patent CN215552024U, its functions are cumbersome and not flexible enough. Developers cannot add their own color separation, digital halftone, color matching and other algorithms that are crucial to improving the quality of print output to the graphics engine. Therefore, developers urgently need to design their own printer drivers in order to grasp the driver as a whole and add the various algorithms they need. Summary of the invention

[0004] The embodiments of the present application provide a printing system, device and method directly driven by a Microsoft system, which directly drives a printer in a Microsoft system (without using an original driver), realizes a simple, efficient and targeted printing output function, and gets rid of dependence on printer brands and their drivers.

[0005] A printing method directly driven by a Microsoft system, characterized in that it comprises the following steps:

[0006] Interface calling step: the printer driver provides the interface function specified by DDI for GDI to call;

[0007] In the transfer step, the GDI call is passed to the GDI graphics engine, which processes the drawing instructions offline as an EMF file, or directly connects to the printer driver and passes the print image to the spool system. At this time, the application completes the task of printing the document.

[0008] A checking step, wherein the spool system adds page layout information and job control instructions to a data stream and then sends the data stream to a print processor, the print processor checks the format of the file received by the print spool, plays back each page of the EMF file content to the GDI, the GDI decomposes the GDI command into drawing primitives defined by the DDI, and transmits the drawing primitives to the printer driver;

[0009] In a data transmission step, the printer driver converts the drawing primitives into raw data in a printer language format and transmits the raw data to the spooler system;

[0010] Instruction sending step, the spooler system sends data to the port monitor through the language monitor, and the port monitor uses the OS file system API to write the data to the hardware port. Finally, the data is sent to the printer and a print instruction is sent.

[0011] Preferably, the printer driver comprises a printer driver rendering module, a printer driver model configuration module, a driver storage module and a printing device communication module, and the printer driver comprises the following steps:

[0012] In the page description step, the printer driver rendering module presents the print job into the page description language of the printing device, and the printer driver model configuration module uses the XPSDrv Render module;

[0013] Configuration module step, the printer driver model configuration module connects print config, advanced constraint processing, JavaScript files supported by PrintTicket and PrintCapabilities, AutoConfig and DevModeMap;

[0014] Instruction capturing step, the driver storage module captures the printer setting instructions through the list file;

[0015] In the communication step, the printing device communication module communicates with the printing device using the printer's two-way communication and Web services.

[0016] Preferably, it also includes a background processing program, which is set on a local computer or a remote network print server; the two-way communication includes the following steps:

[0017] Send request step, if you send a single request to the printer, the printer driver first writes the request and then calls the IBidiSpl::SendRecv method. To send multiple requests, the driver will write a request list and then call the IBidiSpl::MultiSendRecv method;

[0018] A request transmission step, after receiving the request, the client part of the background processing program transmits the request to the server-side background processing program;

[0019] Request analysis step: The background processing program receives the request, analyzes the data in the request, and fills the BIDIREQUESTCONTAINER structure;

[0020] Address filling step, the background processing program calls SendRecvBidiData or SendRecvBidiDataFromPort, when either function returns, its ppResData parameter points to a memory location that contains the address of the filled BIDIRESPONSE__CONTAINER structure of the printer response;

[0021] In the data conversion step, the background processing program converts the data in the BIDIRESPONSE__CONTAINER structure into a form suitable for use by an application or driver, and passes the form back to the background processing program, and finally returns it to the requester.

[0022] Preferably, the printer driver rendering module print filter pipeline configuration file manages and controls the XPSDrvRendering process.

[0023] Preferably, the filter pipeline includes an IHV presentation filter, an IHV functional filter, and a standard XPS filter;

[0024] The IHV rendering filter performs the rendering from XPS to device PDL output, supporting devices that can use XPS as PDL without any rendering filter;

[0025] The IHV function filter performs preprocessing, watermarking or page reordering on the print file;

[0026] The Standard XPS filter supports built-in conversion from XPS to PCL6.

[0027] Preferably, the port monitor is composed of a plurality of port monitoring servers in user mode, providing communication between a print spooler in user mode and a port driver in kernel mode for accessing I / O hardware ports, the port monitor also being responsible for managing and configuring a printer port of a server;

[0028] Wherein for Windows, each of the port monitors is divided into a port monitor UI DLL and a port monitor server DLL;

[0029] The port monitoring server DLL includes a user interface and is executed on the print client system. The port monitoring server DLL resides in the System32 subdirectory of the client system. The port monitoring server DLL includes a port communication function and is executed on the print server.

[0030] Preferably, the printer notification is driven by Bidi and DriverEvent XML files, using the DriverEventXML file to describe the Bidi query, which then triggers the driver event.

[0031] A printing system driven directly by a Microsoft system, including a user layer component, a system user state component, a windows executive body and a system bottom layer component;

[0032] The user layer component calls a standard library, which is provided by a development language and is adaptively adjusted according to different platforms;

[0033] The Windows system function of the system user state component is provided by the corresponding dynamic link library. The application calls the system function, and the system function further calls the intermediary function provided by the ntdll dynamic link library to enter the kernel state from the user state and specify the location of the function with the same name called when entering the kernel state;

[0034] The windows executive body includes x86, DEC Alpha, MIPS and PowerPC instruction sets. After the mediating function inside the windows executive body enters the kernel through the system call instruction, the I / O manager, one of the components in the executive body, generates an I / O request packet according to the request and delivers it to the driver.

[0035] The system bottom layer component sends the request sent by the I / O manager to the lower-level driver attached to it. The I / O request flows through the entire driver stack and feeds back to the manager at all times.

[0036] Preferably, the Windows executive body and the kernel constitute an Ntoskrnl.exe file, and the Ntoskrnl.exe file manipulates the request packet. When the request packet is finally delivered to the bus driver at the bottom of the driver stack, the bus driver calls the corresponding hardware abstraction layer function and communicates with the hardware.

[0037] A printing device directly driven by a Microsoft system comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor applies the following steps when executing the computer program:

[0038] Interface calling step: the printer driver provides the interface function specified by DDI for GDI to call;

[0039] In the transfer step, the GDI call is passed to the GDI graphics engine, which processes the drawing instructions offline as an EMF file, or directly connects to the printer driver and passes the print image to the spool system. At this time, the application completes the task of printing the document.

[0040] A checking step, wherein the spool system adds page layout information and job control instructions to a data stream and then sends the data stream to a print processor, the print processor checks the format of the file received by the print spool, plays back each page of the EMF file content to the GDI, the GDI decomposes the GDI command into drawing primitives defined by the DDI, and transmits the drawing primitives to the printer driver;

[0041] In a data transmission step, the printer driver converts the drawing primitives into raw data in a printer language format and transmits the raw data to the spooler system;

[0042] Instruction sending step, the spooler system sends data to the port monitor through the language monitor, and the port monitor uses the OS file system API to write the data to the hardware port. Finally, the data is sent to the printer and a print instruction is sent. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0044] Figure 1 A schematic diagram of a method for directly driving a printer in a Microsoft system in an embodiment of the present application;

[0045] Figure 2 This is an AOI interaction structure diagram of a method for directly driving a printer in a Microsoft system in an embodiment of the present application;

[0046] Figure 3 This is a diagram of the overall system architecture in the embodiment of this application. DETAILED DESCRIPTION

[0047] In the embodiments of the present application, a printing system, device and method directly driven by a Microsoft system are provided to meet the needs of directly driving a printer in a Microsoft system without using an original driver, thereby achieving a simple, efficient and targeted printing output function and getting rid of dependence on printer brands and their drivers.

[0048] The following is combined with the reference Figure 1-Figure 3 The printing system, device and method directly driven by a Microsoft system provided in the embodiments of the present application are further described.

[0049] refer to Figure 1-Figure 3In order to drive the printer directly without using the original driver, the printer driver provides a series of interface functions specified by DDI for GDI to call, and implements the printer control language in these functions to drive the printer to work. Unlike other display device drivers, the printer driver does not directly manipulate the hardware, but sends the data stream to the spooler component, which then sends the data to the corresponding port and finally to the printer device.

[0050] The printer driver relies heavily on data files and JavaScript to achieve extensibility. The core of its architecture is divided into four parts:

[0051] 1. Printer driver rendering, that is, presenting the print job to the page description language of the printing device. The print driver model uses the XPSDrv Render module.

[0052] 2. Printer driver model configuration layer. The configuration layer supports four types of configurations: print config (i.e., GPD / PPD configuration file); JavaScript files that support advanced constraint processing and PrintTicket and PrintCapabilities support, AutoConfig (GDL configuration file), and DevModeMap (XML configuration file).

[0053] 3. The print driver model uses a new installation mode, and the print driver runs directly from the driver store, which eliminates the possibility of file conflicts and improves installation performance. The installation model continues to use INF files, but also adopts new manifest files to capture printer-specific setting instructions.

[0054] 4. The printer driver connection model allows communication with printing devices using bidirectional and Web Services for Devices (WSD).

[0055] The GDI call is passed to the GDI graphics engine, which processes the drawing instructions offline into an EMF file (Enhanced Metafile) or directly connects to the printer driver, and then passes the print image to the spool system. At this point, the application has completed the task of printing the document, and the user is free to use the application to complete other tasks, while the print spool ensures that the document is printed. The print spool adds page layout information and job control instructions to the data stream, and then sends the data stream to the print processor. The print processor checks the format of the print spool file. For EMF files, it plays back each page of the content to GDI. GDI decomposes the GDI commands into drawing primitives defined by DDI (Graphics Device Interface) and sends the drawing primitives to the printer driver. The printer driver draws the drawing primitives into raw data in the printer language format, such as PCL, etc., and then the raw data is sent to the print spool system. Then the print spool sends the data to the language monitor, the language monitor sends the data to the port monitor, the port monitor uses the OS file system API to write data to the hardware port, and finally the data is sent to the printer.

[0056] In order for the driver to send one or more requests to the printer and for the printer to respond to these requests, bidirectional communication is used to implement communication between the driver and the printer. The bidirectional communication interface is implemented: IBidiSpl COM interface, as well as IBidiRequest and IBidiRequestContainer COM interfaces. The SendRecvBidiData function is implemented in the print provider DLL, and the SendRecvBidiDataFromPort function is implemented in the language monitor server DLL and the port monitor server DLL. If a single request is sent to the printer, the printer driver first writes the request and then calls the IBidiSpl::SendRecv method. If multiple requests are to be sent, the driver writes a request list and then calls the IBidiSpl::MultiSendRecv method. After receiving the request, the client part of the spooler (Winspool.drv) passes it to the server-side spooler (spoolsv.exe). The server-side spooler can be located on the local computer or on a remote network print server. The server-side spooler receives the request, analyzes the data in the request, and fills in the BIDI_REQUEST The server-side spooler then calls SendRecvBidiData or SendRecvBidiDataFromPort. When either function returns, its ppResData parameter points to a memory location that contains the address of a filled BIDI RESPONSE__CONTAINER structure that contains the printer's response. The server-side spooler converts the data in this structure into a form suitable for use by the application or driver and passes it back to the client-side spooler and, ultimately, back to the initiator of the request.

[0057] The Print Filter Pipeline Configuration File manages and controls the XPSDrv Rendering process.

[0058] IHV rendering filter: This filter completes the rendering from XPS to device PDL output; in the absence of any rendering filter, devices that can use XPS as PDL are supported;

[0059] Among them, IHV function filter: IHV function filter supports processing multiple functions, such as pre-processing, watermarking or page reordering of multiple functions. Windows provides a standard XPS filter to support built-in conversion from XPS to PCL6. The print driver supports customization in Windows desktop UI and Microsoft Store UI.

[0060] To better manage battery life and minimize interruptions, notifications are only displayed when the user is printing. Printer notifications are driven by Bidi and DriverEvent XML files.

[0061] In order to avoid long-term CPU occupation during background sending and quickly return control to the user for other operations, the print spooler is connected to the printer driver, receives the data stream created by GDI, and outputs it to a specific type of printer. It selects the first available physical printer in the logical printer queue and converts the spool format data stream (such as EMF) into a format that can be sent to the printer hardware.

[0062] All print providers offer a common set of print provider capabilities for sending print jobs directly to local or remote print devices. These capabilities are defined by a set of API functions that are called by the spooler (spoolss.dll); many of the functions defined by the print provider require a printer handle as input. The spooler client obtains a printer handle by calling OpenPrinter() in winspool.drv, which calls the API server (spoolsv.exe). The spooler (spoolss.dll) calls each print provider's OpenPrinter() function until one of the functions provides a printer handle and returns a value indicating that the print provider recognizes the specific printer name. The sender then returns its handle to the API server. The sender's handle includes the printer handle as well as the print provider handle. The handle is returned to the application so that subsequent calls from the application can be directed to the correct provider and printer.

[0063] The print provider mainly completes the following functions:

[0064] Print queue management: add, delete, open, close, enumerate and set parameters of print queues, and provide notifications of print queue status changes.

[0065] Printer driver management: Add, delete, enumerate, and specify a directory of printer drivers.

[0066] Print job creation: Start and end a document, start and end a document page, write the job's data stream to a port, and read printer status information.

[0067] Print job scheduling: schedule, enumerate, and set parameters for print jobs.

[0068] Table management: add, delete, enumerate and set parameters for printing tables.

[0069] Print processor management: add, delete, enumerate, and specify directories and data types supported by print processors.

[0070] Print monitor management: add, delete and enumerate print monitors.

[0071] Port Management: Add, delete, configure, enumerate and set parameters of printer ports.

[0072] Registry Management: Create, delete, and enumerate registry keys and values ​​associated with print providers.

[0073] Other capabilities: displaying a message box, closing the print provider, reading a memory-imaged spool file, and providing a communication channel between the port monitor user interface DLL and the port monitor server DLL. These capabilities are implemented according to a set of functions defined by the print provider.

[0074] In order to convert the spooled data of the print job to the format of the print monitor, the spooled data of the print job is contained in a spool file. The print processor reads these files, performs conversion operations on the data stream, and writes the converted data to the spool. The spool then sends the data stream to the appropriate print monitor. The default print processor provided by Microsoft is WinPrint, which supports two spool file formats: raw and enhanced metafiles. If printer developers need to process other file formats, they need to develop and use print processors themselves.

[0075] For printers that support two-way communication, developers need to provide their own language monitor, while for printers that only support one-way communication (only support one-way information transmission from the host to the printer), print job language monitor is not required. The language monitor mainly provides the following two functions:

[0076] (1) Provides a full-duplex communications channel between the print spooler and the bidirectional printer, thereby providing software-accessible status information.

[0077] (2) Add printer control information to the data stream, such as commands defined by the printer job language. Language monitors are optional and are only relevant to the specific printer type contained in the printer's .inf file. If a language monitor is associated with a printer, the language monitor receives the printer's data stream from the print processor, modifies it and passes it to the printer's port monitor.

[0078] To provide communication between the user-mode print spooler and the kernel-mode port driver that accesses the I / O hardware ports, the Windows user's view of "printers" is actually a print queue to which one or more physical printer devices can be connected. A port is a physical connection between a print queue and a single printer device. Each port monitor supports one or more instances of one or more port types. For example, the localmon.dll example port monitor can support all of the server's local COM and LTP ports. For a printer queue that represents multiple printer devices (through multiple ports), the spooler sends each print job to the first available port. If the port monitor indicates that an available port is busy or encounters an error, the spooler resubmits the job to the queue, specifying another available port supported by the port monitor. In addition to localmon.dll, Windows provides several additional port monitors. Each of these port monitors is described in the Windows Server Resource Kit.

[0079] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they are aware of the basic creative concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present application.

[0080] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these changes and variations.

Claims

1. A printing method directly driven by a Microsoft system, characterized in that: The following steps are involved: Interface calling step: the printer driver provides the interface function specified by DDI for GDI to call; In the transfer step, the GDI call is transferred to the GDI graphics engine, which processes the drawing instructions offline into an EMF file, or directly connects to the printer driver and transfers the print image to the spooler system. At this time, the application completes the task of printing the document. In a checking step, the spool system adds page layout information and job control instructions to a data stream and then sends the data stream to a print processor, the print processor checks the format of the file received by the print spool, plays back each page of the EMF file content to the GDI, the GDI decomposes the GDI command into drawing primitives defined by the DDI, and transmits the drawing primitives to the printer driver; In a data transmission step, the printer driver converts the drawing primitives into raw data in a printer language format and transmits the raw data to the spooler system; Instruction sending step, the spooler system sends data to the port monitor through the language monitor, and the port monitor uses the OS file system API to write the data to the hardware port. Finally, the data is sent to the printer and a print instruction is sent.

2. The printing method according to claim 1, characterized in that: The printer driver comprises a printer driver rendering module, a printer driver model configuration module, a driver storage module and a printing device communication module, and the printer driver comprises the following steps: In the page description step, the printer driver rendering module presents the print job into the page description language of the printing device, and the printer driver model configuration module uses the XPSDrv Render module; Configuration module step, the printer driver model configuration module connects print config, advanced constraint processing, PrintTicket and PrintCapabilities supported JavaScript files, AutoConfig and DevModeMap; Instruction capturing step, the driver storage module captures the printer setting instructions through the list file; In the communication step, the printing device communication module communicates with the printing device using the bidirectional communication of the printer and the Web service.

3. The printing method according to claim 2, characterized in that: It also includes a background processing program, which is set on a local computer or a remote network print server; the two-way communication includes the following steps: Send request step, if you want to send a single request to the printer, the printer driver will first write the request and then call the IBidiSpl::SendRecv method; if you want to send multiple requests, the driver will write a request list and then call the IBidiSpl::MultiSendRecv method; A request transmission step, after receiving the request, the client part of the background processing program transmits the request to the server-side background processing program; Request analysis step: The background processing program receives the request, analyzes the data in the request, and fills the BIDI REQUESTCONTAINER structure; Address filling step, the background processing program calls SendRecvBidiData or SendRecvBidiDataFromPort, when either function returns, its ppResData parameter points to a memory location that contains the address of the filled BIDIRESPONSE__CONTAINER structure of the printer response; In the data conversion step, the background processing program converts the data in the BIDIRESPONSE__CONTAINER structure into a form suitable for use by an application or driver, and passes the form back to the background processing program, and finally returns it to the requester.

4. The printing method according to claim 2, characterized in that: The printer driver rendering module print filter pipeline configuration file manages and controls the XPSDrv Rendering process.

5. The printing method according to claim 4, characterized in that: The filter pipeline includes an IHV presentation filter, an IHV function filter, and a standard XPS filter; The IHV rendering filter performs the rendering from XPS to device PDL output, supporting devices that can use XPS as PDL without any rendering filter; The IHV function filter performs pre-processing, watermarking or page reordering on the print file; The Standard XPS filter supports built-in conversion from XPS to PCL6.

6. The printing method according to claim 1, characterized in that: The port monitor is composed of multiple port monitoring servers in user mode, providing communication between the print spooler in user mode and the port driver in kernel mode for accessing the I / O hardware port, and the port monitor is also responsible for managing and configuring a server's printer port; For Windows, each of the port monitors is divided into a port monitor UI DLL and a port monitor server DLL; The port monitoring server DLL includes a user interface and is executed on the print client system. The port monitoring server DLL resides in the System32 subdirectory of the client system. The port monitoring server DLL includes a port communication function and is executed on the print server.

7. The printing method according to claim 1, characterized in that: The printer notifications described are driven by Bidi and DriverEvent XML files, using the DriverEvent XML file to describe the Bidi query, which then triggers the driver event.

8. A printing system directly driven by a Microsoft system, characterized in that: Includes user-level components, system user-mode components, windows executives, and system bottom-level components; The user layer component calls a standard library, which is provided by a development language and is adaptively adjusted according to different platforms; The windows system function of the system user state component is provided by the corresponding dynamic link library. When the application calls the system function, the system function further calls the intermediary function provided by the ntdll dynamic link library, enters the kernel state from the user state, and specifies the location of the function with the same name called when entering the kernel state; The windows executive body includes x86, DEC Alpha, MIPS and PowerPC instruction sets. After the intermediary function inside the windows executive body enters the kernel through the system call instruction, the I / O manager, one of the components in the executive body, generates an I / O request packet according to the request and delivers it to the driver; The bottom layer component of the system sends the request sent by the I / O manager to the lower-level driver attached to it. The I / O request flows through the entire driver stack and is always fed back to the manager.

9. The printing system according to claim 8, characterized in that: The windows executable body and the kernel constitute the Ntoskrnl.exe file, and the Ntoskrnl.exe file manipulates the request packet. When the request packet is finally delivered to the bus driver at the bottom of the driver stack, the bus driver calls the corresponding hardware abstraction layer function and communicates with the hardware.

10. A printing device directly driven by a Microsoft system, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the printing method according to any one of claims 1 to 7 is applied.

Images