About Device Drivers

About Device Drivers

INTRODUCTION

This white paper describes the typical architectures of device drivers used with the Ergosoft RIP and provides an overview of the associated data workflows for the supported device interfaces. It also defines common technical terminology used and outlines typical causes of recurring issues or operator‑related configuration errors.

Scope

The device drivers covered in this write down primarily target output devices operated by the Ergosoft RIP, including digital printers and contour cutters/plotters (and milling machines). Where applicable, the same interface concepts and data‑handling principles also apply to supported spectrophotometers.
To operate an output device through the Ergosoft RIP, a dedicated device driver is required. The device driver is responsible for generating device‑specific output data in accordance with the manufacturer’s format specification and for supporting the defined data transmission method(s).

Job Data and Output Structure

A single print or cut operation is referred to as a job. Depending on the device and interface, a job may consist of either a single output file or a defined set of multiple files. In multi‑file workflows, a job often includes:
  1. One or more files containing (often as) binary print or cut data
  2. Additional control information, commonly referred to as a job ticket (if not a part of the binary data)
  3. An optional preview or thumbnail representation (if not a part of the binary data)
The exact job structure and file contents are determined by the device manufacturer and implemented by the corresponding Ergosoft device driver.

Interface Types

Two principal interface categories are distinguished:

A. File‑Based Interfaces

With file‑based interfaces, the Ergosoft RIP generates the complete job data and writes it to storage drive. Job selection and subsequent transmission to the output device are performed by manufacturer‑supplied control, spooler, or device management software.

B. Direct Interfaces

With direct interfaces, the Ergosoft RIP transmits job data directly to the output device via streamed communication. Common interface standards include TCP/IP and USB; legacy or less frequently used interfaces include FireWire, SCSI, and parallel or serial (COM) connections, as well as proprietary wired communication protocols.

FILE BASED INTERFACES

Interfacing with an output device via file exchange represents the most common integration model in the digital printing and cutting industry. Accordingly, the majority of Ergosoft device drivers are implemented using a file based interface.

Main Characteristics 

An interface is classified as a file based interface when the following conditions apply:
  1. Operation of the output device requires manufacturer supplied third party control software.
  2. The Ergosoft RIP generates the complete job output and writes the resulting file set to storage drive.
  3. The user manually loads the print or cut job files from storage drive into the third party control software.
  4. Device control, job processing, and output execution are performed independently of the Ergosoft RIP.
  5. Job generation and job print and/or cut execution occur sequentially; the job must be fully generated before it can be loaded and processed by the device.

Data Flowcharts – Examples of File Based Interfaces

The following examples illustrate typical data flows for file based interfaces, ranging from minimal to more complex implementations.

A. Minimal File Based Interface

In the simplest file based scenario, the output device contains an integrated PC running a Windows operating system. The RIP software can be installed on this system alongside the manufacturer supplied printer control software (PCS).
The device driver does not require additional device information from the PCS or from local configuration files. Job output consists exclusively of greyscale image files (e.g. TIFF, BMP), typically one file per color plane. No preview data or additional print instructions are /can be included in these file formats; all relevant print parameters must be configured manually by the operator within the PCS. Workflow example:

1. The PrintQueue generates halftoned TIFF files and writes them to a local Windows folder. 
2. Using the PCS, the operator loads the TIFF files corresponding to the print job:
      2.1 The operator defines the number of copies.
      2.2 The operator configures all required print parameters.
3. Upon the operator’s print command, the PCS transmits the print data to the print head controller electronics.

B. Common PRN/PRT File Based Interfaces

In a typical PRN/PRT file based configuration, the output device is operated by a dedicated Windows PC, often physically integrated into the device. Both the RIP software and the manufacturer supplied printer control software (PCS) are installed on this system.
The device driver does not require additional device information from the PCS or from local configuration files. Job output consists of greyscale, halftoned PRN or PRT files. Depending on the supported header command set, basic print instructions may be embedded directly in the file, commonly including number of colors, resolution, dot size, and print area dimensions.
If extended print instructions are required (e.g. number of copies or pass mode) and can be passed from the RIP to the PCS, they are written to a separate job ticket. If a preview is available, it is stored as an additional file on the storage drive. All remaining print parameters must be configured manually by the operator within the PCS. Workflow examples:

One Windows PC – most common

Operation and Data Flow:
1. The PrintQueue generates halftoned PRN/PRT files and writes them to a local Windows folder.
      1.1. In most cases, the PRN/PRT is written directly without additional libraries.
      1.2. In some implementations, a manufacturer supplied DLL is used to generate the final print file format.
2. Using the PCS, the operator loads the PRN/PRT print file:
      2.1. The operator defines the number of copies.
      2.2. The operator configures all required print parameters.
3. Upon the operator’s print command, the PCS transmits the print data to the printer over a wired connection.

Two Separate PCs
Using two separate PCs for the RIP software and the PCS is the second most common configuration. The PCS PC often comes with the machine, preconfigured by the manufacturer. The PC for the RIP software is the end user’s responsibility.
Pro: Lower risk of production issues caused by hardware bottlenecks when ripping and printing occur simultaneously.

Operation and Data Flow:
1. The PrintQueue generates halftoned PRN/PRT files and writes them to a shared folder of the PCS PC.
2. Using the PCS, the operator loads the PRN/PRT print file:
      2.1. The operator defines the number of copies.
      2.2. The operator configures all required print parameters.
3. Upon the operator’s print command, the PCS transmits the print data to the printer over a wired connection.

The following data workflow variants of file-based scenarios also exist:
Online Mode
The PCS software offers an Online Mode, which technically turns the common folder of the PrintQueue (OUT) and the PCS (IN) into a hot/queue folder.
Using two separate PCs for the RIP software and the PCS is also possible.

Operation and Data Flow:
1. The PrintQueue generates halftoned PRN/PRT files and writes them to a local or shared Windows folder.
2. Upon completion of file creation, the PCS automatically and continuously:
      2.1. Loads PRN/PRT files of new print jobs.
      2.2. Adds new jobs to the PCS queue.
3. The PCS transmits the print data to the printer over a wired connection automatically.

One RIP – Multiple PCS
When using a single RIP PC while operating multiple printers with dedicated PCS simultaneously, RIP queue output is written to a shared location accessible by all printer PCS instances. The operator selectively loads and sends print jobs from this centralized queue folder to each printer.

Operation and Data Flow:
1. The PrintQueues generate halftoned PRN/PRT files and writes them to a shared network folder.
2. Using the PCS of each printer, the operator loads the PRN/PRT job files:
      2.1. The operator defines the number of copies.
      2.2. The operator configures all required print parameters.
3. Upon the operator’s print command, the respective PCS transmits the print data to the connected printer over a wired connection.

C. Complex File Based Interface

In general, device drivers based on file based interfaces are less complex than those using direct interfaces. However, certain file based implementations represent notable exceptions.
In this example scenario of a major brand, the output device contains an integrated PC running a Linux operating system. The Ergosoft RIP software, which runs on Windows, cannot be installed directly on the printer’s PC and therefore operates externally alongside the manufacturer supplied printer control software (PCS).
Unlike simpler file based interfaces, the device driver requires additional mandatory device information retrieved dynamically from the PCS. This typically includes media definitions and the print modes supported by the currently installed firmware.
The job output generated by the device driver consists of:
  1. Greyscale image files, typically one per color plane
  2. A complex preview representation
  3. Additional print instructions stored in a separate, structured job ticket (e.g. XML based)
Certain print parameters can be manually overridden by the operator within the PCS. In addition, the RIP provides a status monitoring component that retrieves live device information, including readiness state, firmware details, media information, ink levels, and other operational data.

Operation and Data Flow:
  1. The PrintQueue writes job data to a shared network folder on the printer PC, including halftoned TIFFs, preview files, and an XML job ticket.
  2. Using the PCS, the operator loads the job and may redefine copies or override selected print parameters. 
  3. Upon the operator’s print command, the PCS transmits the print data to the printer.
  4. The printer continuously reports live status information to the PCS. 
  5. Via a web service, the RIP Status Monitor continuously retrieves live printer status data.

Additional Characteristics of File‑Based Interfaces

File‑based interfaces can be considered offline print, or cut, (or measurement) workflows. Ergosoft RIP generates job output files and writes them to a storage drive. Manufacturer‑supplied third‑party software - commonly referred to as printer control software (PCS) or printer/cutter frontend software - monitors incoming job files and lists them in its graphical user interface (PCS UI).
This architecture results in the following typical characteristics and implications.

Limitations

  1. Production control is managed outside the RIP
  2. The user controls actual production within the PCS:
    1. The timing, sequence, and duration of print or cut jobs are outside the control of the RIP software.
    2. The number of copies can either not be controlled by the RIP or can only be predefined via an output file header or an additional job ticket. The PCS displays this value as a preselection, which can be modified by the operator at any time before job execution.
      As a result, production control capabilities within the RIP, as well as feedback and production reporting from the device to the RIP, are inherently limited.

Advantages

  1. Reduced software complexity
    From both RIP and machine manufacturer perspectives, file‑based interfaces are generally less complex to design and maintain (notable exceptions exist):
    1. Software development kits (SDKs) are easier to create, maintain, and distribute.
    2. Deployment of new PCS versions is often simpler and less risky than distributing new device firmware.
    3. Driver correctness and output validity can be verified by comparing generated output files against reference files, without requiring direct access to the physical device.
    4. No bidirectional file‑transfer or streaming protocol / additional modules need to be specified or implemented between sender and receiver.
  1. Simplified machine design
    From a machine manufacturer perspective, hardware and software design is less demanding and typically more cost‑effective when using a file‑based interface:
    1. Most implementations rely on standard PC hardware and a common operating system running the PCS.
    In contrast, devices using a direct interface typically require sophisticated firmware running on an embedded operating system, additional built‑in hardware resources (e.g. higher‑performance processors and increased memory), and specialized low‑level software development expertise.

    DIRECT INTERFACES

    Interfacing with an output device via a Direct interface is commonly used for printers operating at a (lower to) medium production volume capacity. Due to the increased requirements for embedded hardware components and more sophisticated firmware design, devices using direct interfaces are often positioned at the higher end of their respective product classes.
    The hardware and software architecture of such devices must support continuous streaming of job data while simultaneously distributing the data to individual print heads and managing all additional machine operations in real time.

    Main Characteristics

    Direct interfaces are primarily characterized by the following behavior:
          1. Direct job submission
          The user can select and send a print or cut job directly from the Ergosoft RIP to the output device, with immediate effect.
                - No third party software is required to select or initiate job processing.
          2. Real time job control
          During data transmission, the user can:
                - Abort the job currently being processed by the device, with immediate effect.
                - Pause the job currently being processed by the device, with immediate effect.
          3. Copy management within the RIP
          The number of copies is defined and managed directly within the Ergosoft PrintQueue.
          4. Parallel ripping and printing
          Depending on the configured buffer size (e.g. start printing after ripping), the device may begin output while the RIP continues ripping and streaming the remaining job data.
          5. Continuous status feedback
          Based on the device’s progress, status information (e.g. data sent and processing state) is continuously updated and displayed in the Ergosoft PrintQueue.

    Data Flowcharts – Examples of Direct Interfaces

    A. Direct Interface Based on Advanced Printer Firmware

    This represents the most common implementation of a printer using a direct interface.
    In this architecture, the device driver typically must retrieve additional device information from the printer firmware (1) to be fully functional. Available printer features may vary depending on the firmware version installed on the device.

    Upon the print command, the Ergosoft PrintQueue continuously streams job data in segments - typically over TCP/IP or USB - directly to the printer firmware. Printing of the job starts (almost) immediately. The PrintQueue progress display reflects the printer’s job progress in real time. Continuous data flow is ensured through buffering on both the sender side (2a - RIP) and the receiver side (2c - printer firmware memory).

    Most devices of this class additionally provide a feature rich third data channel, commonly referred to as Status Monitors (3) or sensors. These modules supply extensive real time device information, such as media details, general printer status, ink levels, firmware version, and related data. Depending on the device, these status sensors / monitors may be mandatory for operation or provided as optional functionality.


    Operation and Data Flows:
    1. The device driver retrieves relevant printer feature and capability information from the firmware and stores it in the Print Environment.
    2. Upon the user’s print command, the Ergosoft PrintQueue streams job data continuously to the printer firmware:
          2.1. The PrintQueue buffers job data locally.
          2.2. Buffered data is sent as a continuous data stream.
          2.3. The printer firmware buffers incoming data in device memory.
          2.4. The firmware streams data continuously to the machine hardware.
          Multiple copies result in repeated streaming of the job data by the PrintQueue.
    3. Depending on the device, a separate data channel provides real time status feedback:
          3.1. Ink status
          3.2. Printer status
          3.3. Media status and details
          3.4. Other device specific information
          This real time feedback may trigger events such as:
          3.5. Warnings
          3.6. Temporary pause of the data stream
          3.7. Abortion of the data stream

    B. Direct Interfaces via Third Party Libraries and/or PCS

    This data flow diagram illustrates common direct interface implementations used with various print head electronics and software solutions. Frequently, the printer manufacturer and the print head electronics including software (PCS) provider are separate entities.

    Upon the user’s print command, the Ergosoft PrintQueue streams job data continuously to the printer using one of the following methods:
    A. Localhost (IP 127.0.0.1) via local PCS
          1. The PrintQueue streams data over localhost (IP 127.0.0.1) to a locally running PCS.
          2. The PCS simultaneously forwards the data stream to the device.
    B. Local Third Party Library
          1. The PrintQueue streams data to a locally installed third party library.
          2. The manufacturer library forwards the data stream either: 
                i. To the PCS, which then forwards it to the device, or
                ii. Directly to the device.
    Multiple copies result in repeated streaming of the job data by the PrintQueue.

    ADDITIONAL INFORMATION

    Common Print File Formats

    The following file formats are most used for printers:
    TIFF – Tagged Image File Format
    1. The most widely used standardized print file format.
    2. Does not support embedded, device specific print instructions (e.g. pass modes, bi /uni directional printing, or dedicated previews).
      - If required, additional print parameters must be stored in a separate job ticket and/or preview file.
    3. Supports halftone print data:
      - 1 bit: one dot size
      - 2 bit: up to three dot sizes
      - 4 bit: up to 15 dot sizes
      - Higher bit depths depending on implementation
    4. Supports Contone print data:
      - 8 bit: 256 grey or ink levels per color plane
      - 16‑bit: 65’536 grey or ink levels per color plane
    5. Can be written as a composite multi channel file or as separate files per color plane.
    6. Supports file compression; supported compression types depend on the printer manufacturer’s software.
    7. Standard TIFF has a maximum file size limit of 4 GB.
      - Some manufacturer implementations exceed this limit, but such extensions are no longer supported by common graphic design software.
    8. BigTIFF (TIFF extension):
      - Extended industry standard allowing file sizes beyond 4 GB.
      - Typically not supported by graphic design software.
    RTL – Raster Transfer Language
    1. The second most commonly used standardized print file format.
    2. Supports embedded, device specific print instructions, including pass modes, bi /uni directional printing, dedicated previews, number of copies, and more.
    3. Almost exclusively used with halftoned print data.
    4. Supports file compression; supported compression types depend on the printer manufacturer’s software.
    Interoperability Note (RTL): Although RTL is a standardized file format, manufacturers implement and interpret RTL parameters in a device specific manner. Consequently, RTL files are not interchangeable between printers from different manufacturers, and typically not even between different printer series.

    PRN – Printer or PRT – Print File
    1. PRN: One of the most common print file extensions used.
    2. PRT: Less common alternative to PRN.
    3. Does not follow a uniform public file standard; format details are manufacturer specific.
    4. Supports limited device specific print instructions embedded in the file header (e.g. pass modes, bi /uni directional printing).
      - If a preview is available, it is stored in a separate file.
      - Due to the limited header command set (device specific), extended instructions such as number of copies must be stored in a separate job ticket.
    5. Supports halftone print data only:
      - 1 bit: one dot size
      - 2 bit: up to three dot sizes
    6. Typically uncompressed; no standardized compression schemes are known.
      - As a result, PRN files are usually very large.
      - Recommendation: Compress PRN files (e.g. ZIP) when exchanging output.
    Interoperability Note (PRN / PRT):
    PRN and PRT files are based on proprietary, manufacturer specific specifications. Header commands, raster interpretation, and supported parameters vary by device and firmware. As a result, PRN/PRT files are not interchangeable between printers from different manufacturers, and typically not even between different printer models or series.

    BMP – Bitmap
    1. Less frequently used in modern printing workflows compared to standardized formats such as TIFF or RTL.
      - Usage often indicates legacy device architectures.
    2. Does not support embedded device specific print instructions (e.g. pass modes, bi /uni directional printing, previews).
      - Additional print parameters must be stored in a separate job ticket and/or preview file.
    3. Supports halftone print data:
      - 1 bit: one dot size
      - 2 bit: up to three dot sizes
    4. Supports Contone print data:
      - 8 bit: 256 grey or ink levels per color plane
    5. Can be written as a composite RGB/CMYK file or as separate files per color plane.
    6. Typically uncompressed, resulting in very large file sizes.
      - Although RLE compression is theoretically supported by BMP, it is rarely used in printing workflows.
      - Recommendation: Compress BMP files (e.g. ZIP) when exchanging output.
    7. Standard BMP file size limit: 4 GB.
    USF – Universal Spool Format
    1. Proprietary Ergosoft print spool file format.
      - Specifications are not confidential but are not widely distributed.
    2. Supports limited device specific print instructions embedded in the file header (e.g. pass modes, bi /uni directional printing).
      - If a preview is available, it is stored in a separate file.
    3. Supports halftone print data:
      - 1 bit: one dot size
      - 2 bit: up to three dot sizes
      - 4 bit: up to 15 dot sizes
      - Higher bit depths depending on implementation
    4. Supports contone print data:
      - 8 bit: 256 grey or ink levels per color plane
    5. Can be written as a composite multi channel file or as separate files per color plane.
    6. Supports file compression.
      - Supported compression methods depend on the printer manufacturer’s software and firmware capabilities.





     










      • Related Articles

      • About Ergosoft File Output Drivers

        Starting with 17.3, Ergosoft offers a range of different file output Print Environments. These drivers output image files to a designated folder in a format depending on the driver that is used. Composite Contone Print Environments output all color ...

      • Latest Version of Ergosoft

        Release Process Ergosoft provides two major software releases per year. Spring Release: Typically published in April Winter Release: Typically published in October Each release includes: Updated and newly supported printer drivers New features and ...

      • Ergosoft RIP – Frequently Asked Questions

        1. What do I purchase when buying Ergosoft RIP? You purchase a perpetual license for Ergosoft RIP, including: A full-featured software suite (JobComposer, QueueManager, RIP Engines, etc.) One printer driver (Entry, Large, or XL) One Entry cutter ...

      • Ergosoft File Output Cut Environments

        Ergosoft offers a range of different file output Cut Environments. These drivers output cut files to a designated folder in a format depending on the driver that is used. They are intended for use with Cut Environments that are not technically ...

      • Ergosoft User Portal

        With the User Portal, Ergosoft introduces a new way to interact with its users and partners around the world! Active users with an Ergosoft Dongle can register for the User Portal and gain instant access to all the latest information, downloads and ...