A method and system for non-intrusive rendering of printed content

Abstract

The application discloses a non-invasive printing content presentation method and system, and relates to the technical field of printing, communication and information display. The method comprises the following steps: through an independently running non-invasive monitoring program, an operating system layer printing event triggered by a user performing a native printing operation or a native printing preview operation in software with a printing function is monitored; after capturing the printing event, printing content to be output is acquired; the printing content is converted into an electronic form output by a virtual printing device; after generating the electronic form output, a transmission module is automatically triggered by an output completion event, and the electronic form output is sent to a display device by a communication mode for screen presentation. The application overcomes the technical prejudice that printing only outputs paper or files, does not require a software interface, does not change the source code, and does not require original factory support. Even if the system has no API, no source code and no original factory maintenance, printing digitization and screen presentation can be realized, and the compatibility and expansion problem is solved. The user only needs to perform native printing, and full-link automation can be realized, the integration period is shortened, and the cost is saved.

Description

Technical Field

[0001] This invention relates to the fields of printing technology, communication and information display technology, and in particular to a non-intrusive method and system for presenting printed content. Background Technology

[0002] In enterprise information systems, printing is a common function across various business modules (such as inventory inquiry, document output, and report generation). Users use the printing function in the software to output data to physical paper for verification, archiving, or circulation. With the advancement of paperless office practices, how to digitize and electronicate printed content has become a focus of industry attention.

[0003] Traditional printing can only output to physical paper or PDF files, resulting in paper waste, inability to update information in real time, scattered printed content that is difficult to manage centrally, and lack of traceability. Existing improvement solutions, such as "print to PDF," can only save the file and still require manual transfer to the display device; wired projection is limited by physical cables and cannot be deployed flexibly.

[0004] More importantly, existing technical solutions output printed content to databases, files, or physical paper, failing to directly and automatically present the printed content to electronic display devices. Typically, expanding software functionality requires calling third-party software's proprietary APIs, modifying the software source code, or engaging in cumbersome integration with manufacturers. This not only results in long implementation cycles and high costs, but is also impossible for "three-no systems"—no API, no source code, and no original manufacturer maintenance—which can only rely on paper printing.

[0005] The published patent document CN102467480A, "Virtual Printing Transmission System," discloses a solution consisting of a printing computer, a receiving computer, and a virtual printing processing module. The virtual printing device collects printing data, converts it into a database format, and transmits it to the receiving computer's database for storage via 2.4G WiFi. The core purpose of this solution is to store printing data in a database for later analysis. Its output endpoint is the database, not an electronic display device, and it limits the specific hardware architecture (ARM processor, USB interface, flash memory chip) and communication protocol, resulting in a narrow scope of protection and easy circumvention. More importantly, this solution still adheres to the technological inertia of "printing → storage," failing to achieve real-time and intuitive presentation of the printed content.

[0006] In summary, a long-standing technological bias exists in this field: the view that the final physical medium for printing can only be paper or documents, and that even electronic conversion is merely for temporary archiving. No existing technology has proposed a solution for directly and non-intrusively presenting printed content on an electronic display device. Summary of the Invention

[0007] In order to overcome the above-mentioned defects of the prior art, the present invention provides a non-intrusive method and system for presenting printed content, so as to solve the problems existing in the background art.

[0008] This invention provides the following technical solution: a non-intrusive method for presenting printed content, comprising the following steps: The system monitors operating system-level printing events triggered by users performing native print operations or native print preview operations in software with printing capabilities through a standalone, non-intrusive monitoring program. After capturing the print event, obtain the print content to be output; The acquired print content is converted into electronic output through a virtual printing device; After the electronic output is generated, transmission is automatically triggered to output the electronic form to a display device for presentation.

[0009] Furthermore, the monitoring of operating system layer printing events includes monitoring at least one of print pool service events, print driver layer events, and print daemon process events, or monitoring files output by the print port; the acquisition of the print content to be output includes intercepting or reading the data stream of the print task.

[0010] Furthermore, the virtual printing device can be a virtual printer driver built into the operating system, a third-party virtual printer driver, or a custom print processor. After converting the printed content into electronic output, the virtual printing device can either directly output a digital copy of the original printed content for presentation, or process the electronic output before presentation. The processing includes, but is not limited to: OCR recognition and rearrangement, key data extraction and overlay printing, format optimization, layout adaptation, adding watermarks, adding headers and footers, and storing printed content. The core feature of this type of electronic output is that its visual content comes from the software's print data stream, rather than a real-time mirror displayed on the current screen.

[0011] Furthermore, the automatic triggering of transmission means that after the virtual printing device completes the generation of the electronic output, it generates an output completion event, which directly starts the transmission module without any manual intervention.

[0012] Furthermore, the communication methods include wireless communication and / or wired communication; the wireless communication methods include, but are not limited to, WiFi, Bluetooth, LoRa, ZigBee, NFC, 4G / 5G; the wired communication methods include, but are not limited to, Ethernet, LAN, WAN, HDMI cable, USB cable; the display devices include, but are not limited to, e-ink screens, LCD screens, LED screens, OLED screens, tablet computers, video walls, and smart TVs.

[0013] Furthermore, the native printing operation or native print preview operation includes: clicking the print button in the software with printing function, clicking the print preview button, using the system print shortcut key, or any user operation that calls the operating system's print interface.

[0014] Furthermore, the method also includes at least one of the following: during the generation and wireless presentation of the electronic output, writing relevant data of the electronic output or its printed content into an RFID electronic tag associated with the display device.

[0015] Furthermore, a non-intrusive system for presenting printed content is characterized by comprising: A non-intrusive acquisition module is used to listen to printing events at the operating system layer and acquire the print content to be output. The printing events are triggered by native printing operations or native print preview operations performed by the user in software with printing functions. The virtual printing module is used to convert the acquired print content into electronic output. An automatic triggering module is used to automatically trigger transmission after the electronic output is generated; A transmission module is used to output the electronic form to a display device; A display device for receiving and presenting the printed content contained in the electronic output.

[0016] Furthermore, the non-intrusive acquisition module, virtual printing module, automatic triggering module, and transmission module are deployed on the same computing device, or distributed across different computing devices connected via a network.

[0017] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any one of the preceding descriptions.

[0018] The technical effects and advantages of this invention are as follows: This invention breaks the technical prejudice that "data must intrude into the system." By monitoring printing events at the operating system layer, it achieves a non-intrusive design, requiring no modification to third-party software, no API calls, and no vendor integration, making it feasible even for "three-no" systems. It uses an event-driven mechanism to automate the entire process from native printing to screen display, is compatible with built-in operating system printers and various third-party virtual printers, and is applicable to any software with printing capabilities. It also supports both unmodified output and output processed with OCR extraction and watermark addition, providing preview capabilities for software lacking preview functionality. Furthermore, it supports enhanced printing content processing and confidentiality auditing, and can optionally be equipped with RFID writing to achieve an integrated "screen display + RFID" application. Attached Figure Description

[0019] Figure 1 This is a flowchart of a method according to an embodiment of the present invention.

[0020] Figure 2 This is a schematic diagram of the system architecture according to an embodiment of the present invention.

[0021] Figure 3 This is a schematic diagram of the operation of the virtual printing device in an embodiment of the present invention.

[0022] Figure 4 This is a schematic diagram of the display device in an embodiment of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments. It should be noted that the following embodiments are only for explaining the invention and are not intended to limit the scope of protection of the invention. Those skilled in the art should understand that the specific parameters and device models appearing in the embodiments are merely examples and do not constitute a limitation of the invention.

[0024] The core concept of this invention lies in using the user's native printing or print preview operation performed in third-party software as the sole trigger source. Print content is acquired by monitoring printing events generated at the operating system layer. After being converted into electronic output by a virtual printing device, the transmission module automatically triggers the transmission of this output to a display device for screen presentation. The entire process involves no modification to the third-party software code, no API calls, and no manufacturer cooperation. The term "third-party software" here refers to any application with printing functionality, and its developers are unrelated to the implementers of this invention.

[0025] A non-intrusive method for presenting printed content includes the following steps: The system monitors operating system-level printing events triggered by users performing native print operations or native print preview operations in software with printing capabilities through a standalone, non-intrusive monitoring program. After capturing the print event, obtain the content to be printed; The acquired print content is converted into electronic output through a virtual printing device; After generating the electronic output, the transmission is automatically triggered, and the electronic output is sent to the display device for presentation.

[0026] In one specific embodiment of the present invention, the above method is implemented on a computing device as follows. The computing device may be an industrial computer, an office PC, or an embedded host, running a Windows, Linux, or macOS operating system. An independently running listener is deployed on this computing device. This listener runs as a system service, daemon, or background process, and does not depend on the source code, API, or vendor support of the software with printing functionality (referred to as third-party software), thereby demonstrating a non-intrusive characteristic.

[0027] First, perform the steps to listen for operating system layer print events.

[0028] The listener registers to monitor print events in at least one of the following ways: In Windows systems, it monitors newly added print jobs in the print queue by calling print pool APIs such as FindFirstPrinterChangeNotification and FindNextPrinterChangeNotification, and can set notification flags such as PRINTER_CHANGE_ADD_JOB; alternatively, it writes a print driver filter, which is mounted in the print driver chain using the Windows print driver framework (such as the V4 print driver or XPSDrv filter) to directly intercept print job events; or it monitors file system changes of a specified print port (e.g., the output directory configured as the virtual printer FILE port), using the ReadDirectoryChangesW API to detect newly generated .spool, .spl, .xps, or .pdf print file events. In Linux systems, it can subscribe to print job creation and status changes by calling cupsCreateSubscription through the CUPS (Common UNIX Printing System) subscription mechanism, or monitor changes to job files in the / var / spool / cups directory using inotify. When a user performs a native printing operation in third-party software (such as clicking the "Print" button, pressing the Ctrl+P shortcut, or selecting the "File-Print" menu) or performs a native print preview operation (such as clicking the "Print Preview" button), the operating system generates a print job and triggers the corresponding print event, which the listener program can capture.

[0029] Next, after capturing a print event, the step of obtaining the print content to be output is executed. After capturing a print event, the listener obtains the print content data associated with that event. Specifically, if the monitor is monitoring the print port output directory, when a new file is generated and the file writing is completed (by checking that the file lock status is released or the file size remains unchanged within a set interval), the output file is read. The file format is usually EMF (Enhanced Metafile), XPS, PS, or PCL. If it is mounted on the print driver layer, the original print commands (such as GDI commands or XPS data streams) are intercepted from the print data stream received from the driver filter and reassembled into complete print content data for each page. If the monitor is through the print pool API, when the task status is detected to change to "spool complete", the job path is obtained through the API (such as GetJob), and then the contents of the spool file (.spl) are read. To improve reliability, in a preferred combination scheme, channel one listens for print job events and records job IDs through the print pool API, while channel two monitors the output directory of the port corresponding to the virtual printer. When a new file is detected, it is matched with a known job to accurately obtain the print content.

[0030] Subsequently, the process involves converting the acquired print content into electronic output via a virtual printing device. A virtual printing device is pre-installed or configured on the computing device. This device can be the operating system's built-in "Microsoft Print to PDF" function, a third-party virtual printer (such as Adobe PDF Printer, doPDF, etc.), or a custom-developed print processor. A monitoring program sends the acquired print content data stream to the virtual printing device: if the user selects the virtual printer, the content is automatically imported; if the user selects a physical printer, the monitoring program intercepts the data and redirects it to the virtual printing device. The virtual printing device parses the input format, for example, rendering EMF into bitmap or vector graphics using GDI playback functions, or extracting page content from XPS parsing packages, and then generates electronic output. The output format can be a PDF file, a PNG / JPEG image sequence, or a custom format document. During the generation process, open-source libraries (such as PDFium, libHaru, Poppler) can be used to write page instructions page by page into the PDF. The resulting electronic output is then stored in the output directory specified by the virtual printing device.

[0031] Finally, the process automatically triggers transmission and outputs the electronic output to the display device for presentation after its generation. After the virtual printer generates the electronic output, the operating system generates an output completion event (e.g., file closed, print job status changes to "printed"). A built-in event monitoring thread in the listener continuously monitors the status of files in the virtual print output directory; when a new file is detected and the file writing is complete (by checking if the file handle is released or the file size is consistent), the electronic output is considered generated. The monitoring thread immediately sends a signal to the main thread of the transmission module (e.g., a Windows Event object, condition variable, or path information via local socket communication). The transmission module is then awakened, reads the electronic file content, encapsulates it into a format suitable for transmission (e.g., HTTP POST request body, MQTT message payload), and sends it to the IP address or device identifier of the target display device via communication. The entire transmission process requires no manual intervention, with latency in the millisecond range. Upon receiving the data, the display device (e.g., e-ink screen, LCD advertising machine) uses its own rendering engine to display the PDF or image on the screen, thus completing the fully automated process from triggering the printing to displaying the content on the screen.

[0032] Specifically, it listens for printing events at the operating system level, including at least one of the following: print pool service events, print driver layer events, and print daemon events, or monitors files output from the print port; it obtains the content to be printed, including intercepting or reading the data stream of the print task.

[0033] In order to achieve the above-mentioned function of monitoring operating system layer printing events, in a specific embodiment of the present invention, the monitoring program can flexibly select the monitoring method according to the operating system type. It can use a single method or combine multiple methods to improve reliability and compatibility.

[0034] Taking the monitoring of print pool service events as an example, in Windows systems, the monitoring program runs as a system service. It calls the FindFirstPrinterChangeNotification function to register job change notifications for a specified printer or all printers. When a new print job is added, the system kernel notifies the monitoring program, which then calls EnumJobs to obtain information such as job ID, document name, and status, thereby enabling the monitoring of print pool service events.

[0035] Taking the monitoring of print driver layer events as an example, a print filter driver (such as based on XPSDrv Filter) can be developed in Windows. This filter is then attached to the print driver pipeline. When any third-party software calls the system print API to generate a print data stream, the filter obtains the complete XPS or EMF data stream during the rendering phase and passes the event to the service process of the listening program through inter-process communication, thereby achieving the capture of driver layer events.

[0036] Taking the monitoring of printing daemon events as an example, in a Linux system environment, the CUPS subscription mechanism is used to subscribe to events such as "job creation" and "job status change" by calling the cupsCreateSubscription interface. The CUPS daemon pushes the events to the listening program through D-Bus or HTTP notifications, and the listening program obtains the job ID and print file path accordingly.

[0037] Taking monitoring the output of the print port as an example, a virtual printer can be installed in the system and its port can be configured as a local file directory (such as the FILE port pointing to C:\PrintOut\). The listening program continuously monitors the directory through ReadDirectoryChangesW (Windows) or inotify (Linux). When a new file is detected to be generated and the file writing is completed, it is confirmed that a printing event has occurred, and the file is used as the carrier of the printed content.

[0038] When acquiring print content, corresponding to the above listening methods: if the task is captured through print pool service events or print daemon events, the spool file path is obtained via API, and then the .spl or .ps file data stream is read; if the event is captured through the monitoring port output file, the complete data stream of the output file (such as PDF, XPS, or PCL format) is read directly; if the event is captured through driver layer events, the original print instructions are intercepted in the filter pipeline and reassembled into a page-by-page data stream. All of the above methods achieve the interception or reading of the print task data stream, thereby completely acquiring the print content to be output.

[0039] Specifically, a virtual printing device can be a virtual printer driver built into the operating system, a third-party virtual printer driver, or a custom print processor. After converting the printed content into electronic output, the virtual printing device can either directly output a digital copy of the original printed content for presentation, or process the electronic output before presentation. Processing includes, but is not limited to: OCR recognition and rearrangement, key data extraction and overlay printing, format optimization, layout adaptation, adding watermarks, adding headers and footers, and storing printed content. The core feature of this type of electronic output is that its visual content comes from the software's print data stream, rather than a real-time mirror displayed on the current screen.

[0040] In this embodiment, the selection of the virtual printing device and the output mode are highly flexible.

[0041] Regarding specific selection: If it's a virtual printer driver that comes with the operating system, directly enable the "Microsoft Print to PDF" function in Windows or the "Save as PDF" function in macOS. This virtual printing function is built into the operating system and does not require additional installation. If it's a third-party virtual printer driver, install eDocPrinter or CutePDF Writer, which simulate a physical printer to receive GDI commands or XPS data and output as PDF or image files. If it's a custom print processor, develop a custom Print Processor dynamic library to replace the default WinPrint processor. This processor directly parses the EMF / XPS data in the spool file and calls PDF generation libraries (such as libHaru and PDFium) to generate electronic output page by page, allowing complete control over the output process.

[0042] After converting the printed content into electronic output, you can select the following specific output modes according to your needs: Original output mode: The custom print processor uses GDI functions (such as PlayEnhMetaFile) to play the EMF recording into the memory device context, obtains the device-independent bitmap, and then generates an electronic file that is completely consistent with the original print layout through a PNG encoder or PDF library, so that what the user sees is what they get.

[0043] OCR Re-sorting: The Tesseract OCR engine is used to recognize the text in the generated PDF or image, obtain the text and coordinates, reorder the recognition results according to the reading order, and regenerate it into plain text or simplified PDF format suitable for screen reading.

[0044] Key data extraction and printing: From OCR recognition results or original EMF text records, key fields such as document number, amount, and date are matched using regular expressions and automatically filled into preset HTML or PDF templates to generate card-style presentation content containing only key information.

[0045] Format optimization and layout adaptation: Based on the screen resolution and physical size of the target display device, the PDF pages are scaled, margins adjusted, rotated, or re-paged to ensure readability on devices such as e-ink screens and video walls.

[0046] Add watermarks and headers / footers: Use a PDF library to overlay watermark text such as "Internal Document" on the output page (set transparency), and write the printer's name and printing timestamp (obtained from the operating system's currently logged-in user and time) in the header or footer area for traceability and auditing.

[0047] Print content storage: In addition to being transmitted to a display device, electronic outputs are archived and stored in a local folder or database by time, user, and job name.

[0048] Regardless of the output mode mentioned above, the final visual content is derived from the third-party software through the operating system's print data stream (such as GDI commands and XPS data), rather than from screenshots or real-time mirroring. This is the essential characteristic that distinguishes it from screen recording or mirroring solutions.

[0049] Specifically, automatic triggering of transmission means that after the virtual printing device completes the generation of the electronic output, it generates an output completion event, which directly starts the transmission module without any manual intervention.

[0050] In this embodiment, the automatic triggering of the transmission process can be implemented as follows. After the virtual printing device converts the printed content into electronic output and completes the file writing, the operating system will generate a corresponding output completion event, such as the print job status changing from "Spooling" to "Printed", or the output file handle being closed.

[0051] The listener has a built-in event monitoring thread, which can use one or a combination of the following monitoring methods: File polling monitoring: The monitoring thread continuously scans the output directory of the virtual printing device. When a new file is detected, its size is checked periodically. If the file size does not change after two consecutive samplings (e.g., 200 milliseconds apart), and the file can be successfully opened in exclusive read mode (indicating that the file has been written and released), then the output is considered complete.

[0052] Print pool job status monitoring: The FindFirstPrinterChangeNotification listens for job status changes. When the job status changes to JOB_STATUS_PRINTED, the full path of the corresponding output file is obtained through the pre-established mapping relationship, and the existence of the file is verified.

[0053] Custom notification mechanism: If a custom print processor is used, the processor can send a completion message containing the file path to the local named pipe or socket after the electronic file has been generated. The listener can determine that the output has been completed after receiving the message.

[0054] Upon confirming the output completion event, the monitoring thread wakes up the main thread of the transmission module via an in-process signal (such as calling SetEvent to set a Windows event object, or std::condition_variable::notify_one). Once awakened, the transmission module automatically reads the electronic output from the path information carried by the event and initiates the network transmission process. The entire process, from output completion to transmission commencement, is completed automatically within milliseconds, requiring no manual intervention.

[0055] Specifically, the communication methods include wireless communication and / or wired communication; wireless communication methods include, but are not limited to, WiFi, Bluetooth, LoRa, ZigBee, NFC, 4G / 5G; wired communication methods include, but are not limited to, Ethernet, LAN, WAN, HDMI cable, USB cable; display devices include, but are not limited to, e-ink screen, LCD screen, LED screen, OLED screen, tablet computer, splicing screen, smart TV.

[0056] In this embodiment, the transmission module and display device support a variety of communication and hardware combinations to adapt to different application scenarios.

[0057] The specific communication methods supported by the transmission module are illustrated in the following examples: WiFi / Ethernet method: The computing device and the display device are connected to the same local area network. The transmission module uses the HTTP protocol to POST electronic outputs (such as PDF files) in multipart / form-data format to the HTTP server built into the display device (such as a lightweight service based on NanoHTTPD). The server triggers the display after receiving the file.

[0058] Bluetooth BLE method: Suitable for low-power e-ink labels. The transmission module divides the file into packets, each packet not exceeding the BLE MTU value (e.g., 20 bytes), and sends them sequentially via write-without-response operations using the GATT feature value. The receiving end reassembles the data and displays it.

[0059] LoRa / ZigBee method: Suitable for long-distance, low-data-rate scenarios. The transmission module compresses the electronic document or converts it into a text digest, which is then sent to the LoRa / ZigBee module via serial port for broadcast. Upon receiving the digest, the remote receiving module drives the e-ink screen to update.

[0060] 4G / 5G method: Both the computing device and the display device are connected to the Internet. The transmission module publishes files to a topic on the cloud platform via the MQTT protocol. The display device subscribes to the topic to receive files, thus completing the remote push.

[0061] HDMI / USB wired mode: The transmission module recognizes the display device as an extended screen through the operating system API and automatically displays electronic outputs in full screen on the monitor or tablet connected via HDMI or USB (such as pushing files via ADB and broadcasting the intention to open).

[0062] Specific embodiments regarding the display device are as follows: E-Ink Screen: This tablet features a 13.3-inch Android E-Ink screen with built-in WiFi. It runs a receiving service program, which receives files and then calls PdfRenderer for full-screen display. It has low power consumption and is suitable for long-term fixed display.

[0063] LCD / LED video wall: Directly connected to an industrial control computer via HDMI for full-screen display; or the video wall has a built-in Android system that receives and displays push notifications via the network.

[0064] Tablets / Smart TVs: In a WiFi environment, receive pushed PDF or image files and display them in full screen using the system's built-in document viewer or photo album application.

[0065] Based on the above description, those skilled in the art can freely choose the communication method and display device type according to actual needs.

[0066] Specifically, native print operations or native print preview operations include: clicking the print button in third-party software, clicking the print preview button, using the system print shortcut key, or any user operation that calls the operating system's print interface.

[0067] In this implementation, the monitoring program does not need to distinguish the specific user interface. Any user action that can cause the operating system to generate a print job or print preview job can be captured.

[0068] Specifically, the operating system layer will trigger a printing event when a user performs any of the following operations: Click the "Print" button in the toolbar or ribbon of the third-party software (usually associated with the ID_FILE_PRINT command); Click the "File" → "Print" menu item in the menu bar; Use the standard printing shortcut keys of the operating system, such as Ctrl+P in Windows / Linux, or Cmd+P in macOS; Click the "Print Preview" button to enter the preview window, and then click the "Print" button in the preview window; In the file manager, right-click the document file and select the "Print" shortcut command; You can call the system printing interface through automated scripts or command lines, such as using ShellExecute to specify the print action in Windows, or calling APIs such as StartDoc.

[0069] All of the above operations eventually enter the operating system's printing subsystem, generating print jobs or data streams. Therefore, the monitoring mechanism of this method only needs to monitor the print pool, print driver layer, or print port to fully capture any of the above operations, ensuring that triggering is achieved without omission.

[0070] Specifically, the method also includes at least one of the following: simultaneously outputting the electronic output to a physical printer or a virtual printer; writing the relevant data of the electronic output or its printed content into an RFID electronic tag.

[0071] This implementation method provides a means to implement extended functionality.

[0072] Simultaneous output to the physical printer: After capturing the print content data stream, the monitoring program simultaneously sends it to both the virtual printing device and the physical printer. Specifically, it calls OpenPrinter to open the target physical printer, then starts the document with StartDocPrinter, writes the previously intercepted raw print data (such as RAW or EMF format) through WritePrinter, and finally uses EndDocPrinter, allowing the physical printer to output paper as normal. This process runs in parallel with the virtual printing of the electronic file, eliminating the need for the user to choose between paper output and screen display.

[0073] Simultaneously output to another virtual printer: Similarly, print data can be simultaneously sent to another virtual printer used for archiving (such as a virtual printer that generates archived PDFs), so that the same operation not only drives the screen display, but also completes electronic archiving in the background.

[0074] Writing to RFID tags: An external RFID reader / writer (e.g., an ISO 15693 high-frequency reader / writer connected via USB) is connected to the computing device. Once the electronic output is generated, the monitoring program extracts key information from the printed content (such as the document number and amount obtained through OCR, or the document name, printer, and printing time obtained from the print job information). Then, it calls interfaces such as WriteBlock in the RFID reader / writer SDK to write these information strings into a designated storage block of the RFID tag associated with the display device or related item. Subsequently, staff can use a handheld RFID reader to scan the tag, quickly obtaining the source of the currently displayed content and the printing record, achieving traceability between the physical world and digital information.

[0075] The above-mentioned extended functions can be implemented individually or in combination, all of which can further enhance the system's usability and traceability.

[0076] Specifically, a non-intrusive printed content presentation system is characterized by comprising: The non-intrusive acquisition module is used to listen for printing events at the operating system layer and acquire the print content to be output. Printing events are triggered by native printing operations or native print preview operations performed by the user in software with printing capabilities. The virtual printing module is used to convert the acquired print content into electronic output. An automatic triggering module is used to automatically trigger transmission after the electronic output is generated; The transmission module is used to output electronic data to the display device; A display device for receiving and presenting printed content contained in an electronic output.

[0077] In one specific embodiment of the present invention, the various components of the system are implemented as follows: The non-intrusive acquisition module runs as a standalone system service (Windows Service) or daemon (Linux Daemon), internally containing a print pool listening submodule, an optional driver filter submodule, and a port file monitoring submodule. It is configured to listen on the print queue corresponding to the virtual printing module (e.g., a virtual printer named "Screen Presenter"). When any third-party software triggers a print operation, this module captures the print event using one or more of the methods described above and obtains print content data in EMF, XPS, PS, or other formats.

[0078] Virtual printing module: Implemented as a virtual printer (which can be a virtual printer built into the operating system, a third-party virtual printer, or a custom print processor), with its output port set to a local directory. After the non-intrusive acquisition module sends the print content to the virtual printer, the virtual printer converts the content into electronic output (such as PDF or PNG) and stores it in the output directory.

[0079] Automatic triggering module: Integrated within the non-intrusive acquisition module, it monitors the output directory of the virtual printing module through a file system monitoring interface (such as ReadDirectoryChangesW). Once the completion of file writing is detected, a trigger signal is automatically generated, and the file path is passed to the transmission module via an in-process callback or IPC (such as a named pipe).

[0080] The transmission module, as an independent background process or thread, reads the electronic file after receiving the file path, encapsulates the file via an HTTP client (such as libcurl) or an MQTT client, and sends it to the address of the display device.

[0081] Display device: A screen device with network communication and image rendering capabilities, such as an Android e-ink tablet. It runs a receiving service to receive and parse pushed PDF or image files, and uses its rendering engine to display the printed content on the screen.

[0082] The above modules work together to realize the entire process from print triggering to screen display, and the whole process has zero intrusion into third-party software.

[0083] Specifically, the non-intrusive acquisition module, virtual printing module, automatic triggering module, and transmission module are deployed on the same computing device or distributed across different computing devices connected via a network.

[0084] This system supports a flexible deployment architecture. In a single-device deployment, all modules are deployed on the same industrial computer or office PC, such as an industrial control computer running Windows 10. The non-intrusive acquisition module and the automatic triggering module are integrated into a Windows service, the virtual printing module uses the operating system's built-in virtual printer, and the transmission module runs as an independent thread within the service. Modules communicate directly through memory variables and shared queues, resulting in extremely low latency. The industrial control computer connects to an e-ink screen via WiFi or directly to a display device via HDMI, forming an independent and complete working unit.

[0085] In a distributed deployment scheme, the system is divided into acquisition and distribution ends. The acquisition end is deployed on the user's office PC or dedicated industrial control computer, including a non-intrusive acquisition module and a virtual printing module; the distribution end is deployed on the central server, including an automatic triggering module and a transmission module. After generating electronic output, the acquisition end synchronizes the file to the shared directory of the central server via network sharing (such as SMB or FTP); the central automatic triggering module monitors new files in the directories of each acquisition end, and the transmission module pushes the content to various display devices based on file metadata. The display devices receive and display the data via network connection. This deployment method is suitable for scenarios with multiple acquisition points and multiple display terminals. The modules work collaboratively through the network, achieving centralized management and flexible expansion.

[0086] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described above.

[0087] In this embodiment, the computer program is implemented using a hybrid C++ and C# programming approach. The core print monitoring component is written in C++ to directly call operating system APIs, while the service framework and transmission logic can be implemented in either C# or C++. The program project includes a print monitoring module, a virtual print support module (optionally integrating a custom Print Processor dynamic library, or calling an external virtual printer command line), an automatic triggering module, and a transmission module (integrating libcurl for HTTP / HTTPS communication, or integrating the Paho MQTT C library for MQTT push). All modules are compiled into a single executable file or a set of dynamic libraries, and packaged together with the necessary configuration files into an installer.

[0088] The computer program and its dependent files can be stored on various computer-readable storage media, such as: solid-state drives (SSDs) inside industrial control computers, which are pre-installed in a designated directory on the system disk and configured as system services that start automatically at boot; USB flash drives as portable installation media, which can be inserted into the target computer to run the installation script to complete the deployment; SD memory cards are used for embedded ARM Linux devices (such as Raspberry Pi), where the system image is burned and the program runs automatically when the system starts; they can also be stored on optical discs or network storage devices for remote download and installation.

[0089] When a computing device containing a processor (such as an x86 industrial computer or an ARM embedded host) loads and executes the computer program from the aforementioned storage medium, the program controls the hardware to perform all of the steps described above, including listening for printing events, acquiring printed content, converting electronic output, automatically triggering transmission, and driving the display device to present the printed content, thus fully realizing the function of non-intrusive screen presentation of printed content.

[0090] Example 1 In a typical warehouse management scenario, operators use the ERP system for daily inbound and outbound operations. When an outbound task needs to be processed, the operator clicks the "Print" button on the outbound order interface in the ERP system as usual to perform the native printing operation, and the operating system then generates a print event.

[0091] The non-intrusive monitoring program of this invention captures the printing event at the operating system layer and obtains the print data stream of the outbound order to be output; it converts the print data stream into PDF and then into an electronic output in image format page by page through a virtual printing device; after the electronic file image is generated, it automatically triggers the transmission module and sends the electronic output to the e-ink screen installed in the warehouse via WiFi.

[0092] The e-ink screen displays complete outbound order information in real time, including key details such as product name, specifications, quantity, target location, and outbound time, facilitating picking and outbound verification. The entire process requires no modification to the ERP system, no API calls, no source code changes, and no cooperation from the original manufacturer. Operators can maintain their existing operating habits, truly achieving a non-intrusive, end-to-end automation of "native printing → automatic screen display."

[0093] The above are merely specific embodiments of this application. The specific parameters and device models used in the embodiments are merely illustrative examples and are not intended to limit the scope of this invention. The scope of protection of this invention is not limited thereto. Equivalent variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technical concept disclosed in this application should all be included within the scope of protection of this invention.

[0094] It is particularly important to clarify that regardless of whether the printed content is output as is or processed by OCR recognition, format conversion, watermarking, etc., before output, as long as the final content is derived from the obtained printed content, it falls within the protection scope of this invention, and others may not claim that it does not constitute infringement on the grounds that "additional processing was performed".

[0095] The terms "wireless communication method" and "wireless display device" mentioned in this invention should be understood to refer to all transmission and implementation methods that can transmit electronic outputs to a display terminal, and should not be limited to the wireless medium itself. Any attempt to circumvent the scope of protection of this invention by simply replacing the transmission medium based on differences in physical form, wired versus wireless methods, or network link configurations will not affect the determination of infringement.

[0096] Furthermore, in infringement determination, factors such as whether the third-party software itself has an API, whether its source code has been modified, whether its manufacturer has provided technical support, and whether the third-party integrator has called its API, do not constitute valid defenses against infringement. The sole criterion for infringement determination is whether the operation triggered by the user is a native printing operation or a native print preview operation. As long as this condition is met, it falls within the protection scope of this invention.

[0097] The solution described in this invention has strong versatility and is applicable to any software system with printing functionality, including but not limited to ERP systems, OA systems, WPS / Office software, industrial control systems, medical management systems, warehouse management systems, and older systems without APIs, source code, or original manufacturer maintenance; it is applicable to any operating system, including Windows, Linux, macOS, Android, and various embedded operating systems; it is not limited by whether the software has open interfaces, whether the source code can be modified, or whether it has original manufacturer technical support.

[0098] Regardless of the hardware environment, communication method, or display device used, as long as the core steps of listening to native printing events at the operating system layer → acquiring the printed content → converting it into electronic output → automatically transmitting it to the display device for presentation are employed, they all fall within the protection scope of this invention. In summary, the scope of protection of this application shall be determined by the scope of the claims.

Claims

1. A non-intrusive method for presenting printed content, characterized in that, Includes the following steps: The system monitors operating system-level printing events triggered by users performing native print operations or native print preview operations in software with printing capabilities through a standalone, non-intrusive monitoring program. After capturing the print event, obtain the print content to be output; The acquired print content is converted into electronic output through a virtual printing device; After the electronic output is generated, transmission is automatically triggered to output the electronic form to a display device for presentation.

2. The method for presenting non-intrusive printed content according to claim 1, characterized in that: The monitoring of operating system layer printing events includes at least one of the following: monitoring print pool service events, print driver layer events, and print daemon process events; or monitoring files output from the print port. The process of obtaining the print content to be output includes intercepting or reading the data stream of the print task.

3. The method for presenting non-intrusive printed content according to claim 1, characterized in that: The virtual printing device can be a virtual printer driver built into the operating system, a third-party virtual printer driver, or a custom print processor. After converting the printed content into electronic output, the virtual printing device can either directly output a digital copy of the original printed content for presentation, or process the electronic output before presentation. The processing includes, but is not limited to: OCR recognition and rearrangement, key data extraction and overlay printing, format optimization, layout adaptation, adding watermarks, adding headers and footers, and storing printed content. The core feature of this type of electronic output is that its visual content comes from the software's print data stream, rather than a real-time mirror displayed on the current screen.

4. The method for presenting non-intrusive printed content according to claim 1, characterized in that: The automatic triggering of transmission means that after the virtual printing device completes the generation of the electronic output, it generates an output completion event, which directly starts the transmission module without any manual intervention.

5. The method for presenting non-intrusive printed content according to claim 1, characterized in that: The communication methods include wireless communication and / or wired communication; the wireless communication methods include, but are not limited to, WiFi, Bluetooth, LoRa, ZigBee, NFC, 4G / 5G; the wired communication methods include, but are not limited to, Ethernet, LAN, WAN, HDMI cable, USB cable; the display devices include, but are not limited to, e-ink screens, LCD screens, LED screens, OLED screens, tablet computers, splicing screens, and smart TVs.

6. The method according to any one of claims 1 to 5, characterized in that: The native printing operation or native print preview operation includes: clicking the print button in the software with printing function, clicking the print preview button, using the system print shortcut key, or any user operation that calls the operating system's print interface.

7. A method for presenting non-intrusive printed content according to any one of claims 1 to 5, characterized in that: The method further includes at least one of the following: during the generation and wireless presentation of the electronic output, writing relevant data of the electronic output or its printed content into an RFID electronic tag associated with the display device.

8. A non-intrusive system for presenting printed content, characterized in that, include: A non-intrusive acquisition module is used to listen to printing events at the operating system layer and acquire the print content to be output. The printing events are triggered by native printing operations or native print preview operations performed by the user in software with printing functions. The virtual printing module is used to convert the acquired print content into electronic output. An automatic triggering module is used to automatically trigger transmission after the electronic output is generated; A transmission module is used to output the electronic form to a display device; A display device for receiving and presenting the printed content contained in the electronic output.

9. The system according to claim 8, characterized in that: The non-intrusive acquisition module, virtual printing module, automatic triggering module, and transmission module are deployed on the same computing device or distributed across different computing devices connected via a network.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images