基于设置条件的数据处理装置的制作方法

本发明涉及一种基于设置条件的数据处理装置。

背景技术：
使用打印机驱动进行的打印操作，或者，使用PC-FAX（计算机传真）驱动的传真传输操作，通过执行以下进程来实现：（1）用户通过使用应用程序的打印菜单来显示打印设置界面，并设置打印条件或传输条件。需要注意的是，尽管打印条件与传输条件的设置内容实际上并不相同，但是本文此后均采用“打印设置”来一并指代打印条件的设置和传输条件的设置。（2）用户通过使用应用程序指示开始打印。打印机驱动接收打印设置，在进程（1）中通过称为DEVMODE（开发模式）结构的数据库确定该打印设置。因此，打印机驱动根据打印设置，将从应用程序接收到的文档数据转换为打印机能够理解的打印数据。打印机驱动将打印数据传送至打印机或传真机。从而，打印机执行打印，传真机执行传真传输。在一种情况下，打印机驱动或PC-FAX驱动（此后一并称之为“打印机驱动”）从应用程序接收打印设置，该应用程序通过使用Windows的应用程序编程接口（API，ApplicationProgrammingInterface），将打印设置通知给Windows的图形设备接口（GDI，GraphicsDeviceInterface）。GDI为Windows型操作系统（WindowstypeOS）的一部分。GDI通过设备驱动程序接口（DDI，DeviceDriverInterface），将打印设置指令通知给打印机驱动。因为只有DDI的I/F被定义了，每个制造商（打印机驱动和PC-FAX驱动的制造商）能够设计一种DDI的实现方法（在DDI被调用时，打印机驱动执行的进程）。然而，即便制造商为打印机驱动定义一个独有的I/F，该I/F也不能被调用，因为Windows型OS无法识别该I/F。1、关于DEVMODE结构DEVMODE结构中存储有打印设置，DEVMODE结构被划分为公共区域和私有区域。图1为描述DEVMODE结构实例的示意图。图2为描述参考DEVMODE结构实例的示意图。公共区域为OS定义区域，因此，应用程序能够改变该公共区域。公共区域包括如下的项目即每个打印机驱动需要设置的例如“打印方向”或“纸张大小”。对每个制造商来讲，私有区域为独有区域，私有区域能够针对制造商或打印机驱动，定义所存储的数据种类。由于应用程序或Windows型OS无法获知私有区域所存储的是什么的种类数据，因此，改变私有区域的唯一方式是：使用打印机驱动的用户界面（UI）驱动来显示私有区域中的设置，并接受所显示的设置。私有区域包括如下的项目即：制造商特征或打印机类型特征，例如，“打印方法”或“身份认证”。用户设置由UI驱动生成的打印条件（例如，纸张大小、页数、双面打印），并根据打印条件指示执行打印。当用户进行操作来指令打印条件的设置时，应用程序通过制定GDI命令来调用GDI，并将DEVMODE结构发给GDI。图2中所示的应用程序为如文档生成程序的应用（如，MS-Word（注册商标））。当GDI从应用程序中获取DEVMODE结构时，该GDI通过制定DDI命令调用打印机驱动的渲染驱动（renderdriver），并将DEVMODE结构发送给渲染驱动。渲染驱动参考从GDI获取的DEVMODE结构，遵从打印设置生成打印数据，并将生成的打印数据发送给假脱机（Spooler），其中，该打印设置来自应用程序指示打印的文档数据。需要注意的是，打印数据包含有：绘图数据（例如，PDL数据）和控制数据（例如，PJL打印命令）。也就是说，UI驱动和渲染驱动均能够指向DEVMODE结构。进一步地，UI驱动能够显示私有区域并接受打印设置的改变。2、自动化需要因此，修改私有区域的唯一方式是使用打印机驱动来显示设置界面，并接受用户在显示界面上所进行的操作。因此，私有区域的改变需要用户的操作。然而，一些进程中要求完全自动完成，不需要任何用户的操作。例如，这样的进程包括：打印表格的进程或通过传真传输（发送）直接邮件（DM）的进程。对于这些进程来讲，即便每次打印的打印设置保持相同的情况下，如果每次打印表格或通过传真发送文档，用户都不得不通过在设置界面上的操作来改变私有区域的话，其可操作性将会被降低。因此，希望在不需要用户操作的情况下，能够将存储在打印机私有区域的打印设置，改变为适用于给定应用程序的打印设置。为了达到上述的要求，一些制造商提供打印机驱动的扩展I/F，以便应用程序能够与打印机驱动直接通信（例如，参见日本专利公开号为2005-148928的文件）。并且，开发了一些适用于给定进程的应用程序，以满足用户的要求。图3为描述扩展I/F、应用程序、DEVMODE结构的示意图，图3所示的应用程序适用于用户或应用程序至少调用扩展I/F的进程。图3所示的应用程序调用扩展I/F来改变私有区域的打印设置。因此，在用户执行指示通过应用程序开启打印的操作之后，能够在完全没有用户的操作下，完成打印。3、关于存储在DEVMODE结构中的打印设置有些打印机驱动在用户已经指示开始打印的操作后，重新显示设置界面，这样，在打印数据传输之前，能够接受打印设置的改变。图4为示出了重新显示的设置界面（在图4所示的实例中，为显示机密打印功能的界面）的示意图。在图4所示的实例中，在用户指示开始打印后，机密打印功能要求输入用户ID和密码。用户除非输入用户ID和密码，否则不能按OK按钮51。在输入用户ID和密码之后，按下OK按钮51，用户ID和密码被传送至打印机。用户ID和密码的组合预先在打印机中注册。因此，当注册的密码组合与传送过来的用户ID和密码不匹配时，打印机不执行打印。在使用机密打印功能时，每次打印均需要输入密码，以便提升保密性。当用户按下取消按钮502时，则取消打印。图5为示出PC-FAX驱动的地址确认界面实例的示意图。PC-FAX驱动显示出地址确认功能界面，并要求用户输入传真发送的地址（例如，传真号码）。在传真发送中，考虑到每次传送的地址会经常不同，PC-FAX驱动显示如图5所示的界面，以防止因疏忽而造成错误的传送。当用户输入传真号码并按下发送按钮时，传真机通过传输执行传真发送，例如，图像数据。在用户按下取消按钮504时，传输取消。在以下情况下使用在图4和图5中所示的实例中所适用的设置，即如果为了在打印（任务）单元中输入或确认，每次执行打印进程要求用户输入密码（这样，以提升保密性能），或者，每次执行传真发送时要求用户确认指定地址（这样，可以防止因疏忽而造成传真发送错误）。在指示开始打印进程后得以修改打印设置，意味着不必通过UI驱动，执行这样的进程——在该进程中，应用程序确定打印设置（DEVMODE结构），并根据打印设置指示执行打印进程。也就是说，通过渲染驱动获取并使用在指示开始打印进程后已被修改的打印设置，在不参考DEVMODE结构情况下就能够进行打印。因此，打印设置的存储位置并不仅限于DEVMODE结构。例如，在实际的PC-FAX驱动中，打印设置如传真发送地址数据存储在文件或除DEVMODE结构之外的结构中。有些打印机驱动在除DEVMODE结构之外的结构中存储所有的设置。图6为示出了可存储在DEVMODE结构之外的打印设置实例的示意图。例如，传真发送过程中使用的地址数据或打印过程中使用的个人数据为可存储在DEVMODE结构之外的打印设置实例。打印设置不存储在DEVMODE结构中，不仅是因为打印设置不必存储在DEVMODE结构中，还有其他的原因。例如，即便打印设置能够存储在DEVMODE结构中，但也有这样一种情况，就是打印设置有意不存储在DEVMODE结构中。如上所述，通过UI驱动，打印设置可存储在DEVMODE结构中，或者通过例如显卡驱动在DEVMODE结构中为打印设置制定参考(reference)。在DEVMODE结构中存储打印设置或参考(referto)DEVMODE结构，应用程序是转变DEVMODE结构的根源。实际上，当打印设置存储在DEVMODE结构时，应用程序设置安全的内存空间，通过Windows型操作系统的方式，向UI驱动提供DEVMODE结构，并且，在DEVMODE结构中设置数据。在参考DEVMODE结构的情况下，应用程序通过Windows型操作系统的方式执行打印，显卡驱动参考DEVMODE结构中的数据。因此，当应用程序不删除DEVMODE结构的情况下，用户初始设置的打印条件保留在DEVMODE结构中。所以，这存在DEVMODE结构中的文件被转移给其他用户的风险。尽管大部分的应用程序在打印进程完成后删除DEVMODE结构，但是仍然有一些应用程序即便在打印进程完成后，也不删除DEVMODE结构。DEVMODE结构中，这些保留在DEVMODE结构中的个人数据可能会被传送至预期之外的用户。这就导致安全性的降低。因此，有这样的打印机驱动，他们不在DEVMODE结构中存储个人数据。在使用打印机驱动执行打印中，Windows型操作系统中存在两种类型的打印体系结构。一种是RAW假脱机类型(spooltype)，另一种是EMF假脱机类型。当使用RAW假脱机类型进行打印时，应用程序将打印机驱动获得的文档数据转换为打印机（应用程序进程）能够理解的RAW数据。从用户角度来讲，在打印进程完成后，用户才能操作应用程序。当使用EMF假脱机类型进行打印时，应用程序将通过Windows型操作系统获取的文档数据转换为EMF数据（其为打印机不相关联的数据）（应用进程），并假脱机(spool)EMF数据（假脱机进程）。然后，打印机驱动将假脱机的EMF数据转换为打印机能够理解的RAW数据。从用户角度来讲，用户能在文档数据转换为EMF数据后，操作应用程序。以上所述的两种体系结构能够提供DDI实现方式，这种DDI实现方式允许在打印开始后，由打印设置界面显示打印设置。5、指向和打印接下来要描述的是，在打印开始后的打印设置与打印机驱动或PC-FAX驱动的安装方式之间的关系。在Windows型操作系统打印机驱动中，有一种称为“指向和打印(Point&Print)”的安装方式。图7为描述指向和打印方式的系统实例的示意图。在图7所示的系统中，打印机、服务器端PC和客户端PC连接至网络。在服务器端PC和客户端PC中安装Windows型操作系统。服务器端PC安装的Windows型操作系统为服务器专用的操作系统。通过服务器端PC作为打印服务器的方式，客户端PC请求打印机执行打印。在这样的系统中，客户端PC和服务器端PC安装有同样的打印机驱动。如此，导致这样的问题，为网络中的每个客户端PC安装打印机驱动，会占用管理者等的大量时间和工作量。指向和打印是通过允许客户端PC从服务器端PC下载并安装打印驱动来解决上述问题的方法。指向和打印为包含在标准Windows型操作系统的功能。在使用指向和打印的打印进程中，共同存在RAW假脱机类型和EMF假脱机类型。打印体系结构的类型为EMF假脱机类型时，用户可决定渲染进程（由渲染驱动执行的进程）由客户端PC执行还是由服务器端PC执行。客户端PC执行的渲染进程是指“客户端的渲染”，而服务器端PC执行的渲染进程是指“服务器端的渲染”6、64位操作系统在很多用户使用的客户端PC安装有常规的32位操作系统的情况下，64位操作系统的使用已开始推广。作为一个原则，64位操作系统仅执行64位的应用程序。尽管如此，Windows型操作系统提供一种方案（是指WOW64（即WindowsONWindows64）），以允许运行已售出和分配的32位应用程序。然而，与应用程序不同的是，在64位操作系统中，生成64位的打印机驱动。因此，在客户端PC中安装64位的打印机驱动。当32位应用程序与WOW64一同运行时，可通过以下方式进行打印：·splwow64.exe作为WOW64运行·通过splwow64.exe将渲染指令从32位应用程序通知给64位打印机驱动。在Windows型操作系统中，存在这样一种方案，安装“替代驱动”以共享打印机（指向和打印）。在这种系统中，安装在服务器上的打印机驱动也安装在客户端PC上。与打印机兼容的打印机驱动未安装于客户端PC的情况下，客户端PC安装有合适的打印机驱动。这种情况下，32位的打印机驱动能够在64位的操作系统中得以注册。但是，以上所述的常规技术存在以下的难题：A、使用扩展I/F的情况甚至在使用扩展I/F情况下，也存在打印设置无法存储的情况。如图3所示，当应用程序通过扩展I/F（由打印驱动进行扩展的）改变打印设置时，应用程序有必要执行这样的进程，即：将DEVMODE结构输入至打印机驱动的扩展I/F中，在改变打印设置后接收输出的DEVMODE结构，并且，在开始打印时，将接收到的DEVMODE结构传送至渲染驱动。换句话说，当使用扩展I/F，并且打印设置存储在DEVMODE结构以外的位置处时，打印机驱动无法通过扩展I/F获取打印设置。因此，必须将所有的打印设置安置在DEVMODE结构中。相应地，当打印机驱动关联个人数据时，或在指示开始打印后，打印机驱动确定/改变打印设置时，可能很难适当地执行打印设置。在这些情况下，打印机驱动可能无法在DEVMODE结构中存储所有的打印设置（设置条目）。因此，存在这样一种情况，即便扩展I/F增设至UI驱动中，但仍然不能存储打印设置。B、将打印设置临时存储在DEVMODE结构之外的位置处的情况鉴于以上所述，例如，存在这样一种打印机驱动，其将打印设置输出至文件夹、地址薄或共享内存空间。图8为描述一种打印设置存储方式实例的示意图，其中，通过打印机驱动的扩展I/F，将该打印设置存储在DEVMODE结构之外的位置处。在图8中，部分或全部的打印设置存储在称为“设置存储区域”的空间中。根据图8所示的方式，对没有存储在DEVMODE结构中的打印设置进行存储成为可能，从而解决上述条目A中的难题。然而，不使用DEVMODE结构，难题发生在下面的三种实例中。这三种实例包括：实例一（使用EMF假脱机时的打印序列实例）、实例二（使用安装有指向和打印的打印机驱动时的打印序列实例）、实例三（使用64位操作系统时的实例）。1、实例一使用DEVMODE结构的方法能够在RAW假脱机期间执行，该方法在打印期间使用DDI调用序列。然而，在使用不同的假脱机类型的情况下，DDI调用序列（由Windows型操作系统调用）发生改变。EMF假脱机包括：将来自于应用程序的文档数据转换为EMF数据的进程，以及，将EMF数据转换为打印机能理解的渲染数据的进程。因此，在Windows型操作系统内部，执行两次打印进程序列。然而，对于将文档数据转换为EMF数据的进程以及将EMF数据转换为打印机能理解的渲染数据（RAW数据）的进程，执行两次的打印进程序列使用不同的进程来完成。在如Windows型操作系统的系统中，资源的可访问性由进程的授权决定（如，系统授权和系统授权之外的授权）。所以，根据存储打印设置的文件夹或地址薄的位置，当打印机翻译打印数据时，由扩展I/F设置的打印设置可能从所存储的位置获取不到。进一步地，使用新近的Windows型操作系统时，从安全角度来讲，如果授权不同的话，访问可能被彻底拒绝。2、实例二使用扩展I/F的方法，能够通过将打印机驱动安装至本地环境中的用户的PC的方式来执行。然而，通过使用上述指向和打印的方式安装打印机驱动时，会出现在不同位置（在服务器端渲染时）运行I/F驱动和渲染驱动的情况。在客户端渲染时，UI驱动和渲染驱动均在客户端PC上运行。但是，在服务器端渲染时，UI驱动运行在客户端PC上，而渲染驱动运行在服务器端PC上。在服务器端渲染时，由于运行的PC彼此之间物理上各不相同，因此打印机驱动，无法获取通过打印机驱动的扩展I/F的方式临时存储在设置存储区域（例如，文件夹、地址薄）的打印设置。3、实例三如上所述，WOW64为Windows型操作系统提供的方案，仅在执行打印时，运行sp1wow64.exe。由于Windows型操作系统不支持32位应用程序访问64位扩展I/F，所以不能运行sp1wow64.exe。因此，32位应用程序不能使用具有64位扩展I/F的打印机驱动。图9为描述使用扩展I/F时是否能传递打印设置的实例的示意图。图9示出了传递打印设置是困难的，如果：i）使用EMF假脱机，安装环境为本地；ii）使用EMF假脱机，安装环境为指向与打印，并且渲染位置为服务器；iii）在64位的操作系统中运行32位的应用程序。

技术实现要素：
本发明可提供一种基于打印设置条件的数据处理装置，实质性地消除一个或多个由相关技术的缺点或局限所引发的问题。本发明的特征和优势在下面的叙述中进行说明，并且在结合叙述和附图使其中一部分变得明显，或者，根据本发明的叙述提供的教导，实践本发明而知晓。本发明的主题或特征及优势可从基于打印设置条件的处理数据的装置或计算机可读记录介质中实现或获得。特别地，在说明书中指出完整、清晰、简洁、准确的术语，使在本领域的普通技术人员能够实践本发明。为实现本发明的这些及其他优势，根据本发明的目的，如此处所述的实施和大体描述，本发明的实施方式提供一种数据处理装置，该数据处理装置包括：设置接受单元，配置为通过使用基本程序通过第一程序接受第一打印设置条件；图像处理单元，配置为通过使用所述基本程序获取来自应用程序的文档数据，并将所述文档数据转换为打印数据；接口，配置为在不使用所述基本程序的情况下通过所述第一程序接受来自应用程序的第二打印设置条件，并通过所述第一程序输出所述第二打印设置条件至第三程序，所述第三程序能够处理打印数据；其中，所述图像处理单元配置为：根据由所述第一程序接受的所述第一打印设置条件和由第二程序接受的所述第二打印设置条件中的至少一个，通过所述第二程序将所述文档数据转换为打印数据。在结合附图及随后的详细叙述中，本发明的其他主题、特征和优势会变得更为明显。附图说明图1为表示DEVMODE结构实例的示意图；图2为表示参考DEVMODE结构的实例的示意图；图3为表示扩展I/F、应用程序、DEVMODE结构的实例的示意图；图4为表示重新显示设置界面的实例的示意图；图5为表示PC-FAX驱动的地址确认界面的实例的示意图；图6为表示可能存储在DEVMODE结构之外的打印设置的实例的示意图；图7为表示指向和打印方法的描述系统的实例的示意图；图8为表示打印设置的存储方式的实例的示意图，其中，打印设置通过打印机驱动的扩展I/F的方式存储在DEVMODE结构之外的位置处；图9为表示使用扩展I/F时传递打印设置是否可能的实例的示意图；图10为表示根据本发明实施方式的打印机驱动的特征的示意图；图11A为表示根据本发明实施方式的打印系统的配置的示意图；图11B为表示根据本发明实施方式的客户端PC的硬件配置的示意图；图12为表示根据本发明实施方式的客户端PC和打印机驱动的功能或功能元件的方框图；图13为表示根据本发明另一实施方式的客户端PC和打印机驱动的功能或功能元件的方框图；图14为表示根据本发明实施方式的打印机驱动的扩展I/F单元、应用程序和操作系统之间关系的示意图；图15为表示根据本发明实施方式的Windows型操作系统的打印体系结构的渲染驱动和UI驱动的示意图；图16为表示根据本发明实施方式的语言监视器的操作的示意图图17为表示根据本发明实施方式的将打印设置（打印条件）安置在扩展I/F单元的实例的示意图；图18为表示根据本发明实施方式的将打印设置安置在扩展I/F单元的实例的示意图；图19A为表示根据本发明实施方式的“SendRecvvBidiDataFromPort()”的格式实例的示意图；图19B为表示根据本发明实施方式的“PBIDI_REQUEST_CONTAINER”结构的格式实例的示意图；图19C为表示根据本发明实施方式的“BIDI_REQUEST_DATA”结构的格式实例的示意图；图20为表示根据本发明实施方式的应用程序31（31A）通过扩展I/F单元将打印（传真发送）条件设置在UI驱动的顺序图；图21为表示根据本发明实施方式的将打印设置安置于扩展I/F单元的实例的示意图；图22-24为表示根据本发明实施方式的批量发送操作的示意图；图25为表示根据本发明实施方式的关于多个逻辑打印机的打印设置的运行实例的示意图图26为表示根据本发明实施方式的具有指向和打印的打印环境的配置的示意图；图27为表示根据本发明实施方式的在指向和打印环境中语言监视器的运行实例的示意图；图28为表示根据本发明实施方式的语言监视器的运行实例的示意图，这里，32位的应用程序运行于64位的操作系统。具体实施方式这里，结合附图对本发明的示例性实施方式进行说明：图10示出了根据本发明实施方式下述的打印机驱动30的特征。（1）下述打印机驱动30的UI驱动38为应用程序提供独特的扩展I/F单元382。扩展I/F单元382为除Windows型OS（操作系统）定义的DDI（设备驱动接口）之外的接口。UI驱动38能够接受（接收）通过扩展I/F单元382的方式改变的打印设置。（2）UI驱动38将由扩展I/F单元382接受的打印设置存储在语言监视器32中。由应用程序通过UI驱动38的方式设置打印设置时，打印设置存储在DEVMODE结构中。但是，存储在例如语言监视器32中的打印设置和存储在DEVMODE结构中的打印设置，此后统称为“打印设置”。也就是说，不管打印设置的存储位置，均使用术语“打印设置”。语言监视器32能针对打印机驱动30的每个逻辑打印机存储打印设置。语言监视器32为API（应用程序编程接口）类型。因此，在以下记载的实施方式中，直接从UI驱动38等此类装置向语言监视器32设置打印条件，是指UI驱动38等诸如此类装置通过API的方式设置打印条件。（3）当应用程序31输出执行打印（打印执行指令）的指令给Windows型操作系统时，打印机驱动30的渲染驱动39从语言监视器32中读取打印设置。在DEVMODE结构中注册打印设置时，渲染驱动39也从DEVMODE结构中读取打印设置。（4）根据获取的打印设置，渲染驱动39生成给打印机（打印机任务语言（PJL））的命令，或生成将在打印机打印的打印数据（打印机描述语言（PDL））。由于应用程序31通过扩展I/F单元382设置打印设置，因此，无需在DEVMODE结构中存储高度机密数据。通过使用语言监视器32，不管打印系统结构采用RAW假脱机还是EMF假脱机，渲染驱动39都能够获取打印设置。也就是说，例如，能够预防因使用不同进程而导致的拒绝访问，这是因为，语言监视器32为Windows型操作系统的功能的一部分。进一步地，即使在服务器端执行渲染，渲染驱动39能访问语言监视器32，这是因为，如下所述，语言监视器32为由Windows型操作系统支持的功能。因此，甚至在打印机驱动30通过指向与打印的方式安装于下述的客户端PC中时，渲染驱动39能够获取打印设置。配置图11A为了根据本发明实施方式的打印系统400的配置的示意图。图11B为根据本发明实施方式的数据处理装置（本实施方式中为客户端PC）100的硬件配置的示意图。在图11A和图11B中，客户端PC100和图像形成装置（本实施方式中，打印机）200通过网络300相互连接。本实施方式中，打印机200可为一台或多台打印机。在客户端PC100接受来自用户的操作时，应用程序31请求使用如GDI、DDI和打印机驱动30来执行打印。打印机驱动30通过执行下述的进程生成打印数据，并将生成的打印数据传输给打印机200。只要打印机200包含图像形成功能，打印机200的名称不限于打印机，也可以为如复印机（copymachine）、复制机（duplicatingmachine）或传真机（图像传输装置）。客户端PC100和打印机200可直接相互连接，例如，通过USB（通用串行总线）电缆。客户端PC100通过总线连接至CPU11、ROM（只读存储器）12、RAM（随机访问存储器）13、扩展I/F14、通信设备15、输出设备16、显示控制单元17和存储设备18。CPU11从存储设备18中读取操作系统10、应用程序31和打印机驱动30，并将RAM103作为运行空间，运行操作系统10、应用程序31和打印机驱动30。只要应用程序31能请求打印机200进行打印，应用程序31可为任意类型的软件或程序。例如，应用程序31可为文档生成软件、浏览器如软件或展示文档生成软件。进一步地，应用程序31可为任意类型的软件或程序，只要应用程序31能够生成、显示并管理文档数据（打印目标），使文档数据能够被打印出来。文档数据（打印目标）并限于包含字符（字母）、符号或数字的数据，还可以为包括图像或照片的数据。RAM13为运行空间（主存储内存），可在其中临时存储必要的数据。例如，ROM12中存储有BIOS、初始设置数据以及启动程序。扩展I/F14为设置有电缆（USB电缆）或便携记录介质20的接口。通信设备15根据CPU11的指令，将数据包（本实施方式中，打印数据）发送给打印机200。例如，通信设备15可为LAN（本地局域网络）卡或以太网（注册商标）卡。输入设备16为用户接口，从用户那接受各种操作（指令）。例如，输入设备16可为键盘、鼠标、触摸板或自动输入设备。显示控制单元17根据应用程序31指定的屏幕数据，通过控制如分辨率或色彩数，控制显示器19的渲染。显示器19可为包括如液晶显示器或有机电致发光显示器的FPD（平板显示器）。存储设备18为存储有操作系统10、打印机驱动30和应用程序31的非易失性存储器（non-volatilememory）。例如，存储设备18可为HDD（硬盘驱动）或闪存。操作系统10优选为Windows型操作系统。但是，也可以使用其他具有与Windows型操作系统实质性相同功能的操作系统。例如，客户端PC使用的Windows型操作系统可为WindowsNT、Windows98、Windows2000、WindowsME、WindowsXP、WindowsVista、Windows7、Windows7以及Windows型操作系统的其他后续版本。例如，服务器端使用的Windows型操作系统可为Windows2000Server、Windows2003Server、Windows2008Server以及Windows型操作系统的其他后续版本。例如，存储介质20为如SD（安全数字）卡或USB内存的非易失性存储器。打印机驱动30可静态分布记录于记录介质20或从服务器（未示出）下载。在使用指向和打印时，打印机驱动30从服务器端PC（图11中未示出）下载。图12为显示客户端PC100和打印机驱动30的各功能或功能元件的示意图。客户端PC100包括由Windows型操作系统运行的应用程序30、打印机驱动30、语言监视器32以及通信单元40。由于语言监视器32为Windows型操作系统提供的功能，因此，广义上来讲，语言监视器32可以看作是Windows型操作系统的一部分。尽管附图中未示出，如GDI、spooler及打印机处理器等器件，也与Windows型操作系统一同安装在客户端PC100中。打印机驱动30包括UI驱动38和渲染驱动39。进一步地，UI驱动38包括显示单元381和扩展I/F单元382。在用户输入文档打印操作至应用程序31情况下，UI驱动38的显示单元381在显示器19上显示打印设置界面（也称为“打印对话框”）。用户可通过操作打印设置界面设置打印条件，如“页数”、“双面打印”、“多页合并打印（N-upprinting）”、“图书合并（bookbinding）”、“缩小/放大”。进一步地，显示单元381可在用户指示开始打印后显示打印设置界面并接受打印设置的改变。打印设置存储在称为DEVMODE结构（此后将其简称为DEVMODE）的数据表（数据结构）中。DEVMODE为成员可变的数据结构，定义这些可变值，是为了允许打印条件通常由运行在Windows型操作系统的各种打印机驱动30进行设置。进一步地，UI驱动38包括的扩展I/F单元382在无需Windows型操作系统介入的情况下，接受来自应用程序31的打印设置。一般来讲，为了使应用程序31访问UI驱动38，应用程序31调用GDI，并通过Windows型操作系统访问UI驱动38。扩展I/F单元382为通向打印机驱动30的独特接口，该打印机驱动30允许UI驱动38接受来自应用程序31（无需Windows型操作系统介入）的打印设置及在打印进程中的设置（如，批量传输设置）。渲染驱动39参考DEVMODE（在打印设置包含于该DEVMODE时）和打印设置（以及在打印设置被接受时，下述的操作设置），并根据打印设置通过将文档数据（打印目标）转换为打印数据的方式生成打印数据。语言监视器32包括数据存储单元321和通信单元322。在打印机驱动30向通信单元40传输打印数据时，通信单元322控制数据通信（发送/接收）。通信单元322控制客户端PC100的语言监视器32与通信单元40之间的数据通信。通信单元322通过通信单元40接收来自打印机200的消息。数据存储单元321中存储打印设置，打印机驱动30通过使用语言监视器32的功能实现数据存储单元321。因此，这不需要改变或基本不需要改变Windows型操作系统。需要注意的是，下面对数据存储单元321进行详细描述。客户端PC100的通信单元40为与打印机驱动200通信的功能器件。通信单元40使用如TCP/IP协议。尽管图12中在UI驱动38内示出扩展I/F单元382，但只要扩展I/F单元382包含于打印机驱动30中，扩展I/F单元382也可以位于UI驱动38外部。因此，如图13所示，扩展I/F单元382可从UI驱动38中分离（独立）出来。图14为示出打印机驱动30的扩展I/F单元382、应用程序31和操作系统（本实施方式中，Windows型操作系统）10之间关系的示意图。假设在UI驱动38不包括扩展I/F单元（诸如扩展I/F单元382）的情况下，应用程序31和打印机驱动（包括UI驱动38和渲染驱动39）30将一直通过操作系统10进行数据传递。然而，通过在打印机驱动30中设置扩展I/F单元382，能够实现应用程序31与打印机驱动30之间的直接数据传递。也就是说，应用程序31和打印机驱动30能够在没有操作系统10介入的情况下，进行数据传递。因此，应用程序31能够直接向打印机驱动30中设置打印设置（打印条件）。图15为示出根据本发明实施方式的Windows型操作系统的打印体系结构中的渲染驱动39和UI驱动38的示意图。Windows型操作系统的GDI34通过向打印机驱动30制定DDI命令，调用打印机驱动30的UI驱动38和渲染驱动39。UI驱动38和渲染驱动39互相不直接通信。然而，由于DEVMODE在DDI（作为用于从Windows型操作系统调用打印机驱动的I/F）的参数中，UI驱动38和渲染驱动39均可参考DEVMODE。Windows型操作系统调用的UI驱动38接受来自用户的打印设置，并将打印设置存储在DEVMODE中。当开始准备打印时，DEVMODE从Windows型操作系统传递至渲染驱动39。也就是说，当开始准备打印时，通过与UI驱动38确定“打印设置”并通过与渲染驱动39接受“打印设置”，根据打印设置能够生成打印命令或渲染数据。这是Windows型操作系统的打印体系结构的基本打印序列。因此，如果使用只遵从Windows型操作系统打印体系结构的打印机驱动，渲染驱动39则无法参考没有存储在DEVMODE中的打印设置。但是，根据本发明实施方式的打印机驱动30，打印机驱动30能够参考DEVMODE中的打印设置和为语言监视器32设置的打印设置。图16为示出根据本发明实施方式的语言监视器32的运行示意图。语言监视器32接收从打印处理器41传送的打印数据，并将打印数据传送给通信单元40（端口监视器41和端口驱动43）。打印处理器41包括假脱机功能。端口监视器42根据传输协议执行进程，并将打印数据传输给端口驱动43。端口驱动43控制打印机200和客户端PC100之间的连接接口（如，USB、NIC），并将打印数据传送给打印机200。根据Windows型操作系统，打印机驱动30能够使用Windows型操作系统提供的语言监视器32和制造商（打印机制造商、传真机制造商）提供的语言监视器32。根据本发明实施方式的语言监视器32可包括商用的语言监视器和制造商提供的语言监视器。使用实例图17为示出根据本发明实施方式的将打印设置（打印条件）向扩展I/F单元382设置的示意图。应用程序31包括扩展I/F调用单元，用于调用扩展I/F单元382以及向UI驱动38设置打印设置。技术上来讲，向UI驱动38设置的设置是传输设置。然而，本实施方式中，传输设置也称为(refertoas)打印设置。由于扩展I/F制造商公开扩展I/F单元382的规范（API），第三方（即，除制造商之外的团体或个人）可制造扩展I/F调用单元311。进一步地，制造商可制造扩展I/F调用单元311或包括扩展I/F调用单元311的应用程序31，并提供制造的扩展I/F调用单元或应用程序31。应用程序31使用扩展I/F调用单元311调用打印机驱动30的扩展I/F单元382（在Windows型操作系统不介入的情况下），并将打印设置设置至扩展I/F单元382。如上所述，例如，没有设置至DEVMODE中的数据可以是具有高机密性的数据。在图17所示的实例中，从安全角度来讲，用户姓名（个人数据）和密码是不存储在DEVMODE中的数据。UI驱动38通过扩展I/F单元382接收应用程序31设置的打印设置，并将接收的打印设置存储在语言监视器32中。在本进程中，使用被称为“SendRecvvBidiDataFromPort()”的Windows型操作系统的API（应用程序编程接口）。下面会对“SendRecvvBidiDataFromPort()”进行详细描述。通过Windows型操作系统10，将打印的执行从应用程序31通知给渲染驱动39。由于打印设置已经存储在（注册）在语言监视器32中，因此不必在显示器19上为UI驱动38显示打印设置界面。通过执行打印操作，将存储在DEVMODE中的打印设置传递（以在DEVMODE中的存储状态）至渲染驱动39。进一步地，渲染驱动39从语言监视器32中获取借助扩展I/F单元382设置的打印设置。然后，渲染驱动39生成打印机200能够理解的打印数据。本实施方式中，除那些关于安全性之外的打印设置存储在DEVMODE中，并通过Windows型操作系统以存储在DEVMODE中状态传递给渲染驱动39。可替换的是，所有打印设置通过扩展I/F单元382的方式，可存储于语言监视器382中。如图17所示，图17的实例中并没有使用DEVMODE。图18为示出根据本发明实施方式的向扩展I/F单元382设置打印设置的设置实例的示意图。图18示出设置应用程序31A，与用于生成文档数据的应用程序31相互独立。与图17所示的应用程序31类似的是，设置应用程序31A包括扩展I/F单元311，扩展I/F单元311用于调用扩展I/F单元382单元以及向UI驱动38设置打印设置。本实施方式中，将要设置打印机驱动（PC-FAX）30的打印设置包括地址（指示传真传输目标的地址）、发送者数据（指示传真传输的发送者的数据）。UI驱动38在语言监视器32中存储（注册）打印设置。也就是说，设置应用程序31A为关于打印机驱动30的打印设置（即，设置打印条件）专用的应用程序。图18中，应用程序A和应用程序B为生成文档数据的应用程序31。在应用程序（应用程序A和应用程序B）31生成文档数据之前，设置应用程序31A能够执行打印设置。在应用程序31指示打印的执行情况下，渲染驱动39从语言监视器32获取打印设置，将打印设置转换为打印机200能够理解的数据，并将转换的数据传输至打印机200。为了执行在扩展I/F单元382中的打印设置之外的目的，图18所示的设置应用程序31可独立于应用程序31而设置。在打印机驱动30设置有打印条件的情况下，设置应用程序31可独立于应用程序31设立。在打印机驱动30设置有打印条件的情况下，设置应用程序31A可独立于应用程序（应用程序A和应用程序B）31而设置，或者，与应用程序31（即，包括于图17中所示的应用程序31）形成联合体。将设置应用程序31独立于应用程序（应用程序A和应用程序B）31设立的一个实例为：设置应用程序31为表格（form）打印应用程序。SendRecvvBidiDataFromPort()。图19A为示出“SendRecvvBidiDataFromPort()”的格式实例示意图。“SendRecvvBidiDataFromPort()”函数为加载在语言监视器32中的API。与打印机驱动30类似的是，语言监视器32包括由Windows型操作系统确定的I/F。“SendRecvvBidiDataFromPort()”函数为Windows型操作系统确定的I/F的一个实例。“SendRecvvBidiDataFromPort()”函数支持应用程序31和打印机200之间的双向通信以及应用程序31与假脱机器之间的双向通信。在图19A中，“hport”指示的是调用源模块的端口的操控。进一步地，“dwAccessBit”指示的是由调用源模块提供的存取屏蔽（ACCESS_MASK）结构（其允许访问打印机或打印服务器）。进一步地，“pAction”指示的是调用源模块提供的请求行为。“pReqData”指示的是包含有请求数据的PBIDI_REQUEST_CONTAINER结构的指针。进一步地，“ppResData”指示的是指向内存空间的指针，该内存空间用于接收包含有响应数据的PBIDI_REQUEST_CONTAINER结构的地址。图19B为“PBIDI_REQUEST_CONTAINER”结构的格式实例示意图。尽管图19B中未示出，“PBIDI_RESPONSE_CONTAINER”的结构与“PBIDI_REQUEST_CONTAINER”的结构实质相同。“PBIDI_REQUEST_CONTAINER”的结构为用于将“bidirequests”请求列表存储于其中的容器。Windows型操作系统提供“bidirequests”请求和响应方案，该方案包括：含有成对请求与响应的数据库的方案，其中，请求与响应用于打印机与应用程序之间的双向通信。在图19B中，“version”指示方案如“1”的版本。进一步地，“Flags”指示由系统（Windows型操作系统）保留的标示(flag)的集合。“Flags”的值可为0。进一步地，“Count”指示“aDatamember”的“bidirequests”数量。进一步地，“aData[]”指示“BIDI_REQUEST_DATA”的阵列（排列）。阵列的每个元素包括单一的“bidirequest”。图19C为BIDI_REQUEST_DATA结构的格式实例的示意图。BIDI_REQUEST_DATA结构包括单一的“bidirequest”。在图19C中，“dwReqNumber”指示请求的索引。“dwReqNumber”用于通过针对于响应的多请求来匹配一个操作的请求。进一步地，“pSchema”指示指向方案字符串的第一个位的内存位置的指针。进一步地，“data”指代配合方案的BIDI_DATA。“SendRecvvBidiDataFromPort()”函数用于在语言监视器32中设置条件，或者为语言监视器32制作请求（询问）。打印机驱动30通过“SendRecvvBidiDataFromPort()”调用语言监视器32，以便于语言监视器32用作存储空间。换句话说，语言监视器32及“SendRecvvBidiDataFromPort()”函数提供数据存储单元321。如上所述，语言监视器32并不必由制造商开发。标准的语言监视器32能够与Windows型操作系统共同使用。在语言监视器32不是由制造商开发的情况下，运行标准的语言监视器32。在制造商开发与预定的I/F对应的语言监视器32的情况下，语言监视器32增设有额外的功能。在本实施方式中，打印机驱动30或类似部件能够通过I/F如“SendRecvBidiDataFromPort()”与语言监视器32交换数据。更为具体地来讲，将“JOBID”设置于“IBidiRequest”（COM接口的实例)的“SetSchema()”中，以及将打印设置设置“IBidiRequest”的“SetInputData”。在UI驱动38设置IBidiRequest对象，并调用该SendRecv()，假脱机调用SendRecvBidiDataFromPort()并将打印设置设置预定参数（如，第三参数、第四参数）中。由此，打印设置设置在语言监视器32中。例如，在使用渲染驱动39读取打印设置情况下，打印机驱动30设置IBidiRequest对象，并调用SendRecv()。因此，打印设置存储于IBidiRequest中。相应地，渲染驱动39调用IBidiReqeust的GetOutputData()时，渲染驱动39能够接收存储在IBidiRequest中的打印设置。通过扩展I/F单元382的方式，设置打印（传真传输）条件的操作图20为示出了根据本发明实施方式应用程序31（31A）通过扩展I/F单元382将打印（传真传输）条件设置UI驱动38的顺序图。由于在设置打印（传真传输）条件的阶段执行这个操作，所以设置应用程序31A可独立于应用程序31或包含于应用程序31。步骤S1：应用程序31向打印机驱动30的扩展I/F单元382指定打印设置。与UI驱动38相同的方式，应用程序31能够显示打印设置界面，并接受来自用户的打印设置。步骤S2：应用程序31发送通知给打印机驱动30的扩展I/F单元382，指示所指定的打印设置需要被确认（确定）。步骤S2.1：打印机驱动30的扩展I/F单元382指示语言监视器32将所指定的打印设置存储在其中。更确切地讲，打印设置存储在“SendRecvBidiDataFromPort()”函数的预定参数中。方便起见，图20的顺序图示出：在步骤S2.1中，扩展I/F单元382访问语言监视器32。也可通过显示UI驱动38访问语言监视器32来示出步骤S2.1。步骤S3：在步骤S3或之后，应用程序31主要执行典型的打印操作。第一，应用程序31指示GDI开始打印进程的准备。更具体来讲，应用程序31使用CreateDC()函数将打印设置转换为参数，并调用GDI34。需要注意的是，例如，在传输进程完成后，应用程序31指示GDI开始打印进程的准备。步骤S3.1：GDI34通过调用与API对应的DDI，发送打印设置的打印进程给渲染驱动39。从应用程序31传递至GDI34的打印设置，以“CreateDC”(DEVMODE)的形式，存储于“DrvEnablePDEV()”的参数中，并通知给渲染驱动39。那么，渲染驱动39能够参考打印设置，直到任务完成（即，直到设备描述表（devicecontext）清除）。步骤S4：当GDI34通知应用程序31打印进程的准备完成时，应用程序31指示GDI34启动打印进程。更确切地讲，例如，应用程序31通过使用“StartDoc()”将“DocINFO”转换为参数，并调用GDI34。步骤S4.1：GDI34指示渲染驱动39启动打印进程。更确切地讲，GDI34发送“DrvStartDoc()”函数给渲染驱动39。步骤S4.1.1：通过“DrvStartDoc()”调用打印机驱动30的渲染驱动39时，渲染驱动39询问是否存在与应用程序31设置的打印设置相对应的打印设置。更确切地讲，渲染驱动39为SendRecvBidiDataFromPort()的参数设置查询指示值，并将“SendRecvBidiDataFromPort()”的参数发送给语言监视器32。当由应用程序31设置的打印设置存在于语言监视器32中时，语言监视器32将该设置设置“SendRecvBidiDataFromPort()”，并将“SendRecvBidiDataFromPort()”发送给渲染驱动39。打印机驱动30的渲染驱动39根据从语言监视器32获得的打印设置（以及，当打印设置存储在DEVMODE中时，还根据DEVMODE），生成打印数据，并将生成的打印数据发送给打印机200。步骤S5：当GDI34通知应用程序31完成打印进程的启动时，应用程序31以页为单位（即逐页）重复下面的进程：第一，应用程序31指示GDI34接受新的页面。更确切地讲，应用程序31将“StartPage()”发送给GDI34。步骤S5.1：GDI34将“DrvStartPage()”发送给渲染驱动39。然后，GDI34将从应用程序31获得的渲染函数（文档数据）发送给渲染驱动39。然后，渲染驱动39根据所获取的打印设置将文档数据转换为打印数据。然后，渲染驱动39将打印数据发送给打印机200。步骤S6：当渲染驱动39通知应用程序31一页渲染进程（单页渲染(asinglepageworthofrendering)）完成时，应用程序31通知GDI34一页写入（单页写入(asinglepageworthofwriting)）完成。更确切地讲，应用程序31发送“EndPage()”给GDI34。步骤S7：当所有页的渲染进程完成时，应用程序31通知GDI34打印任务完成。更具体地来讲，应用程序31发送“EndDoc()”给GDI34。步骤S8：应用程序31将“DeleteDC()”通知给GDI34，并清除设备描述表。在本阶段，如果应用程序31指示再次启动打印进程，渲染驱动39使用与前次打印进程相同的打印设置，生成打印数据，这是因为，语言监视器32的打印设置尚未改动。步骤S9：在完成打印进程之后，应用程序31通知打印机驱动30的扩展I/F单元382取消打印设置。步骤S10：打印机驱动30的扩展I/F单元382将指示取消的值设置为“SendRecvBidiDataFromPort()”的参数。然后，扩展I/F单元382（UI驱动38）指示语言监视器32取消（清空）打印设置。图20所示的步骤S2.1中，打印设置（打印条件）通过一次通信来进行设置。但打印设置也可通过多次通信来进行设置。类似地，在步骤S4.1.1中，不仅可通过一次通信读取数据，还可以通过多次通信读取数据。进一步地，步骤S2.1中的进程可在步骤S1中执行。如图20所示，当调用“DrvStartDoc()”时，打印机驱动30的渲染驱动39从语言监视器32中获取扩展I/F单元382的设置数据（打印设置）。如上所述，对于RAW假脱机和EMF假脱机，Windows型操作系统的操作顺序和进程是不同的。然而，在RAW假脱机和EMF假脱机中，即便打印机驱动的操作不同，但访问语言监视器32的方式是相同的。因此，设计渲染驱动39，以便在“DrvStartDoc()”运行时，语言监视器32能够获取打印设置。也就是说，设计打印机驱动30的进程不必考虑假脱机类型。这样，通过在相同DDI执行相同进程，不管假脱机的类型差别，均能使用语言监视器32。如上所述，参照图20，当调用“DrvStartDoc()”时，打印机驱动39从语言监视器32中获取打印设置。但是，打印机驱动39也可在其他时刻获取打印设置，只要该时刻在将要传输至打印机200的打印数据生成之前。在设置打印设置（操作设置）之后的传输操作当用户通过运行设置应用程序31A，来设置打印设置（打印条件）的情况下，用户还能设置操作设置（操作条件）。操作设置为包含于打印设置中的项目。本实施方式中，操作设置为指定打印机200执行操作或进程的设置（条件）。图21为示出向扩展I/F单元382设置打印设置的实例的示意图。在设置应用程序31A为打印条件和对UI驱动38的操作方面，图21所示的实例与图18所述的实例不同。图21所示实例的其他方面（例如，包含于UI驱动38的扩展I/F单元382）与图17所示的基本相同。图21所示的设置应用程序31A设置如下的操作条件：操作设置：批量传输设置在从打印机执行用于发送多个文档的传真传输情况下，应用程序每指示执行一次打印，就收取一次接通费（connectionfee）。因此，通过一次连通后传输所有文档的数据，而不是重复进行连通和断开的方式，能够节省连通费。例如，“批量传输设置”是用于节省连通费的操作设置。批量传输设置是一种指示渲染驱动39成批执行来自多个应用程序的文档（任务）的数据的传输操作设置。在图21中，在接受用于传真传输的打印设置时，设置应用程序31A向UI驱动38设置打印设置。然后，设置应用程序31A通过打印机驱动30的扩展I/F单元382，为传真传输设置打印设置（例如，地址数据、发送者姓名）以及操作设置（本实例中，批量传输设置）。在向UI驱动38设置批量传输设置之后，由应用程序（A、B）31执行打印进程。因此，渲染驱动39从语言监视器32中读取打印设置和操作设置，并生成打印机200能够理解的打印数据。然后，根据批量传输设置，渲染驱动39将打印数据成批地传送给打印机200。相应地，对于相同地址（目标）传真传输能够通过一次连通完成。应用程序（A、B）31可单独传输，也可与多个文档的数据在一批中传输。在图21中，设置应用程序31A可与应用程序（A、B）31组成联合体。在另一实例中，存在这样一种操作设置，其允许相同文档可传输至多个地址（广播）。图22-24为描述批量传输的操作的示意图。在图21-24中，设置应用程序31A和应用程序（A、B）31一并称为“应用程序31”。S1：应用程序31向打印机驱动30的扩展I/F单元382设置操作设置。与UI驱动38的方式相同，应用程序31能够在显示器19上显示操作设定界面。进一步地，应用程序31能够从用户那接受操作设置。S2：然后，应用程序31在打印机驱动30的扩展I/F单元382设置打印设置。S3：应用程序31发送通知给打印机驱动30的扩展I/F单元382，指示确认（定义）所指定的打印设置和操作。步骤S3.1：打印机驱动30的扩展I/F单元382指示语言监视器32存储所指定的打印设置和操作设置。更确切地讲，将打印设置和操作存储在“SendRecvBidiDataFromPort()”函数的预定参数中。由于操作设置会被维持（存储）直到操作设置被清除，所以操作设置处于锁定状态。步骤S4：在步骤S4或之后，应用程序31主要执行典型的打印操作。第一，应用程序31指示GDI34开始打印进程的准备。更确切地说，应用程序31通过使用“CreateDC()”函数将打印设置转换为参数，并调用GDI34。步骤S4.1：GDI34通过调用与API对应的DDI，发送打印设置的打印进程给渲染驱动39。打印设置以“CreateDC”(DEVMODE)参数的形式从应用程序31传递至GDI34，存储在“DrvEnablePDEV()”的参数中，并通知给渲染驱动39。然后，渲染驱动39能够参考打印设置，直到任务完成（即，设备描述表清除）。步骤S5：当GDI34通知应用程序31打印进程的准备完成时，应用程序31指示GDI34启动打印进程。更确切地讲，例如，应用程序31使用“StartDoc()”函数将“DocINFO”转换为参数，并调用GDI34。步骤S5.1：GDI34指示渲染驱动39启动打印进程。更确切地讲，GDI34发送“DrvStartDoc()”函数至渲染驱动39。步骤S5.1.1：通过“DrvStartDoc()”调用打印机驱动30的渲染驱动39时，渲染驱动39询问是否存在与应用程序31设置的打印设置和操作设置相对应的打印设置和操作设置。更确切地讲，渲染驱动39设置询问“SendRecvBidiDataFromPort()”的参数的指示值，并向语言监视器32发送“SendRecvBidiDataFromPort()”的参数。当应用程序31设置的打印设置和操作设置存在于语言监视器32中时，语言监视器32给“SendRecvBidiDataFromPort()”设置打印设置和操作设置，并发送“SendRecvBidiDataFromPort()”至渲染驱动39。打印机驱动30的渲染驱动39根据从语言监视器32获取的打印设置（如果打印设置存储于DEVMODE中，还根据DEVMODE），生成打印数据，并将生成的打印数据发送给打印机200。S6：当GDI34通知应用程序31打印进程启动完成时，应用程序31以页为单位（即逐页）重复以下的进程。在图22所示的实例中，只单页打印。第一，应用程序31指示GDI34接受新页面的打印数据。更确切地讲，应用程序31发送“StartPage()”至GDI34。S6.1：GDI34发送“DrvStartPage()”至渲染驱动39。S7：然后，GDI34发送从应用程序31获取的渲染函数（文档数据）给渲染驱动39。然后渲染驱动39根据所获取的打印设置，将文档数据转换为打印数据。如果没有设置批量传输设置，渲染驱动39根据从语言监视器32获取的打印设置生成打印数据，并将打印数据传送给打印机200。但是，当渲染驱动39检测到已设置有批量传输设置，渲染驱动39维持（存储）打印数据，暂不传输打印数据。S8：当GDI34通知应用程序31一页渲染进程（单页渲染）完成时，应用程序31通知GDI34一页写入（单页写入）完成。更确切地讲，应用程序31发送“EndPage()”至GDI34。S8.1：GDI34发送“DrvSendPage()”至渲染驱动39。S9：当所有页的渲染进程完成，应用程序31通知GDI34打印任务完成。更确切地讲，应用程序31发送“EndDoc()”至GDI34。S9.1：GDI34发送“DrvEndDoc()”至渲染驱动39。S10：应用程序31将“DeleteDC()”通知给GDI34，并清除设备描述表。S10.1：GDI34传输“DrvDisiblePDEV”至渲染驱动39。然后，渲染驱动39清除DEVMODE。在本阶段，完成一个任务的执行（单个文档的数据传输完成）。在批量传输中，应用程序不传输打印数据给打印机200而执行下一个任务。步骤S11-S17的进程实质上与步骤S4-S10的相同。应用程序31能够任意次数地重复步骤S4-S10的进程。在本实施方式中，一批传输两个任务的数据（两个文档数据）。S18：应用程序31指示打印机驱动30的扩展I/F单元382取消批量传输设置。例如，用户登记多个文档（传输目标）的文档数据时，应用程序31在所有文档传输完成后，指示取消批量传输设置。这样，在某些情况下，优选应用程序31（生成文档数据）和设置应用程序31A（设置打印设置/操作设置）组成联合体。在应用程序31和设置应用程序31A单独设立（即，未组成联合体）的情况下，应用程序31可根据用户的操作取消批量传输设置。可替换地，批量传输设置的取消也可自动执行。例如，批量传输设置可在设置批量传输设置之后的预定的时间段后进行取消，或者在某一具体时间进行取消。S18.1：在步骤S18.1中或之后，扩展I/F单元382主要执行典型的打印操作。可替换地，在步骤S18.1中或之后，应用程序31可替代扩展I/F单元382，执行典型的打印操作。首先，扩展I/F单元382指示GDI34启动打印进程的准备。更确切地说，扩展I/F单元382通过使用“CreateDC()”函数将打印设置转换为参数，并调用GDI34。S18.1.1：GDI34通过调用与API对应的DDI，发送打印设置的打印进程给渲染驱动39。打印设置以“CreateDC”(DEVMODE)参数的形式，从扩展I/F单元382传递至GDI34，该打印设置存储于“DrvEnablePDEV()”的参数中，并将该打印设置通知给渲染驱动39。然而，由于没有传输文档数据，渲染驱动39不能通过参考DEVMODE来生成打印数据。S18.2：GDI34通知扩展I/F单元382打印进程的准备完成时，扩展I/F单元382指示GDI34启动打印进程。更确切地讲，例如，扩展I/F单元382通过使用“StartDoc()”函数将“DocINFO”转换为参数，并调用GDI34。S18.3：扩展I/F单元382将“ExtEscape()”传输给GDI34。“ExtEscape()”函数为允许访问不能通过GDI34（本实例中，渲染驱动39）被访问的模块的API。在GDI34不介入的情况下，可使用“ExtEscape()”函数从应用程序等向驱动传输数据，或者，在GDI34不介入的情况下，可使用“ExtEscape()”函数从驱动获取数据。“ExtEscape()”可包括用于将积累（存储）的打印数据传输给打印机200的请求。S18.3.1：GDI34将“ExtEscape()”转换为DDI，即“DrvStartPage()”，并将“DrvStartPage()”传输给渲染驱动39。S18.3.2：进一步地，GDI34将“DrvEscape()::PASSTHROUGH()”传输给渲染驱动39。根据“DrvEscape()::PASSTHROUGH()”中的指令，渲染驱动39将积累的打印数据传输给打印机200。S18.4：当扩展I/F单元382从GDI34得知打印数据已传输时，扩展I/F单元382通知GDI34打印任务完成。更确切地讲，扩展I/F单元382将“EndDoc()”发送给GDI34。S18.4.1：GDI34将“DrvEndDoc()”传输给渲染驱动39。S18.5：扩展I/F单元382将“DeleteDC()”通知给GDI34，并清除设备描述表。S18.5.1：GDI34将“DrvDisiblePDEV”传输给渲染驱动39。然后，渲染驱动39清除DEVMODE。S19：当扩展I/F单元382通知应用程序31操作完成时，应用程序31指示打印机驱动30的扩展I/F单元382取消打印设置。S19.1：打印机驱动30的扩展I/F单元382在“SendRecvBidiDataFromPort()”的参数中设置取消的指示值。然后，扩展I/F单元382指示语言监视器32取消（清空）打印设置。从而，扩展I/F单元382清除存储在语言监视器32打印设置和操作设置。相应地，取消操作的锁定状态。因此，即使操作设置不是存储在DEVMODE中的项目，打印机驱动30的操作指定（操作设置）能够在语言监视器32中注册。在步骤S18中，打印机驱动30的扩展I/F单元382通过GDI34（常规打印任务）向渲染驱动39发送取消批量传输设置的指令（通知）。可替换地，扩展I/F单元382可直接发送指令给渲染驱动39。多个逻辑打印机的身份标识在一些情况下，多个逻辑打印机可在一个客户端PC上注册。在本实施方式中，逻辑打印机为在Windows型操作系统的打印机文件夹中标示为打印机图标的逻辑打印机。Windows型操作系统针对一个打印机驱动30能够生成多个逻辑打印机。从应用程序31的角度看，逻辑打印机为虚拟输出目标。由打印机驱动30渲染的打印数据输出至用户指定的逻辑打印机，并通过Windows型操作系统从逻辑打印机传输至物理打印机。每个逻辑打印机都可以分配一个名称。例如，逻辑打印机的名称可由用户分配，也可以根据打印机驱动中的包装名称(nameofapackage)进行自动分配。例如，可以将指示功能的设置、按指示是否共享打印机的设置、按假脱机类型的设置或按指定选项配置（optionconfiguration）的设置配置给逻辑打印机。换句话说，每个物理打印机初始设置是能够改变的。对多个逻辑打印机注册于一个客户端PC的情况，针对每个逻辑打印机设置进行打印设置和操作设置的设置是比较方便的。在一种配置中，一旦扩展I/F单元382设置打印设置之后，多个应用程序31使用相同的打印设置。在另一种配置中，一旦扩展I/F单元382设置操作设置之后，多个应用程序31使用相同的操作设置。比较理想的是，针对每个逻辑打印机存储打印设置和操作设置。因此，扩展I/F单元382在语言监视器32中注册打印设置和操作设置，将逻辑打印机名称（此后也可称为“逻辑打印机ID”）作为密钥。图25为示出针对多个逻辑打印机设置打印设置的操作实例的示意图。对于多个逻辑图标（逻辑打印机）注册在一个客户端PC100上的情况，打印设置注册在语言监视器32中，使用逻辑打印机ID作为密钥。图25中的应用程序31是作为由应用程序31A和应用程序（A、B）31组成的联合体的实例。如下所述，应用程序31使用打印机驱动30的扩展I/F单元382。在本实例中，应用程序31向逻辑打印机名称（逻辑打印机ID）A设置打印设置AB，应用程序31向逻辑打印机名称（逻辑打印机ID）B设置打印设置MN。逻辑打印机ID为用户指定作为输出目标的逻辑打印机的ID。因此，由应用程序31、UI驱动38和渲染驱动39检测逻辑打印机ID（将其作为参考）。因此，UI驱动38能够向语言监视器32设置打印设置，并使用逻辑打印机ID（对应于输出目标的逻辑打印机）作为密钥。渲染驱动39将逻辑打印机ID作为密钥询问语言监视器32，并获取与询问对应的打印设置。因此，能针对每个逻辑打印机、传真打印及传真传输来指定打印设置或操作设置。需要注意的是，即便在进行批量传输时，能针对每个逻辑打印机来设置打印设置/操作设置。采用指向和打印安装方式的语言监视器接下来要说明的是，使用采用指向和打印安装方式的语言监视器32管理打印设置和操作设置的方法。图26为示出具有指向和打印环境的打印系统400的配置的示意图。在该打印系统400中，四个客户端PC100通过网络B连接于服务器端PC110。尽管在图26中，打印机200连接至服务器端PC110，但打印机200可连接至网络B。打印机驱动30安装于服务器端PC110。服务器端PC110复制打印机驱动30和将该复制分配至各客户端PC100。因此，通过服务器端PC110和各客户端PC100之间的协同操作，打印机驱动30在不烦扰用户的情况下也能够安装。下面的实例为：客户端PC100与服务器端PC110连接且使用指向和打印安装方式来安装打印机驱动30。在指向与打印环境的服务器端执行渲染中，由于客户端PC100（本实例中，客户端PC1）接受用户设置的打印设置，服务器端PC110和客户端PC100可能很难共享打印设置等。然而，由于上述语言监视器32是Windows型操作系统内部的功能（功能元件），安装有指向与打印的客户端PC1的Windows型操作系统，能够将打印设置传输给服务器端PC110。因此，服务器端PC110能够通过Windows型操作系统的打印体系结构的方式，从客户端PC1获取打印设置和操作设置。图27为在指向与打印环境中语言监视器32的操作实例的示意图。语言监视器32为安装在Windows型操作系统的打印体系结构中的模块。因此，在指向与打印环境中，即使在UI驱动38分配至客户端PC100时，或者在渲染驱动39的进程分配至服务器端PC110时，只有在服务器端PC提供的语言监视器32允许运行。尽管在客户端PC100也提供语言监视器32，但是客户端PC100的语言监视器32不运行。客户端PC1的打印机驱动30和服务器端PC110的打印机驱动30被配置为只访问一个语言监视器32。通过使用如RPC（远程程序调用），客户端PC100的Windows型操作系统和服务器端PC110的Windows型操作系统，在客户端PC100和服务器端PC110之间建立通信。当UI驱动38访问客户端PC100的语言监视器32时，客户端PC100的语言监视器32不运行，但客户端PC的假脱机35将打印设置传输给服务器端PC110的语言监视器32。由于客户端PC100和服务器端PC110上安装的是相同的Windows型操作系统，客户端PC1和服务器端PC110均可共享使用Windows型操作系统的打印体系结构的语言监视器32。因此，能够预防如因不同制造商开发的特有模块而造成的访问受限和通信错误等问题。进一步地，由于客户端PC100和服务器端PC110上安装的是相同的Windows型操作系统，客户端PC100和服务器端PC110对于Windows型操作系统具有亲和力。虽然RAW假脱机和EMF假脱机作为假脱机类型，包含于指向与打印环境中，但当然RAW假脱机作为假脱机类型时，不能在服务器端执行渲染（服务器端渲染）。这是因为，作为应用程序31的进程，RAW假脱机限制能够执行渲染的位置。另外，如图27所示，对于执行使用RAW假脱机类型的客户端渲染、使用EMF假脱机类型的客户端渲染、使用EMF假脱机类型的服务器端渲染，能够使用语言监视器32。在64位操作系统中运行32位应用程序的实例图28为示出在64位操作系统中运行32位应用程序时，程序语言监视器32的操作实例的示意图。在下文中，假定为传真传输设置打印设置的设置应用程序31A为32位应用程序，Windows型操作系统为64位操作系统。当应用程序31执行打印进程时，根据WOW64方案来执行“sp1wow64.exe”。因此，应用程序31可以是32位应用程序，也可以是64位应用程序。与Windows型操作系统类似的是，打印机驱动30也设计成64位。这样，渲染驱动39为64位驱动。在UI驱动38也为64位驱动，并安装于客户端PC1100中。但是，当设置应用程序31A（32位应用程序）试图访问扩展I/F单元382时，“sp1wow64.exe”并不运行。因此，设置应用程序31A不能访问扩展I/F单元382。在这种情况下，通过使用称为替换安装的方案，Windows型操作系统将32位打印机驱动（其预先注册为64位打印机驱动的兼容替代）注册至客户端PC1100中。在图28所示的实例中，注册32位打印机驱动是指注册32位打印机驱动，不是64位打印机驱动。由于使用32位扩展I/F单元382的设置应用程序31A设计成32位，所以将32位UI驱动38加载至32位扩展I/F单元382。因此，UI驱动38能够从32位的设置应用程序31A接受打印设置等。通过的API作为“SendRecvBidiDataFromPort():”的方式，扩展I/F单元382与语言监视器32进行通信。因此，在不考虑设置应用程序31A和Windows型操作系统结合（例如，32/64位应用程序、32/64位操作系统）的情况下，扩展I/F单元382能够在64位语言监视器32中存储打印设置等。也就是说，因为使用API“SendRecvBidiDataFromPort():”，所以设置应用程序31A和Windows型操作系统无论是32位还是64位都没有问题。进一步地，当执行打印进程时，使用称为“SendRecvBidiDataFromPort():”的API，64位渲染驱动39与语言监视器32进行通信。因此，在不考虑设置应用程序31A和Windows型操作系统结合（例如，32/64位应用程序、32/64位操作系统）的情况下，渲染驱动39能够从语言监视器32中读取打印设置等。因此，根据本发明上述的实施方式，即使32位应用程序在具有打印机驱动30的64位操作系统中运行，也能够通过扩展I/F单元382的方式，使用设置应用程序31A设置打印设置，并且，也能从渲染驱动39中读出打印设置。因此，根据本发明上述实施方式的打印机驱动30，当应用程序31使用扩展I/F单元382并设置打印设置时，能够达到下述效果：1）不管使用的是RAW假脱机还是EMF假脱机，都能够根据打印机驱动30的扩展I/F单元382指示的打印设置，执行打印；2）在不依赖于假脱机类型的情况下，能够根据（通过指向和打印方式安装的）打印机驱动30通过扩展I/F单元382的方式指示的打印设置，执行打印；3）即使在32位应用程序在64位操作系统中运行的情况下，根据打印机驱动39的扩展I/F单元382指示的打印设置，执行打印。进一步地，打印机驱动30能够将打印设置存储在DEVMODE中。进一步地，打印机驱动30能够将全部的打印设置存储在语言监视器32中。通过本发明的上述实施方式，无论操作环境如何，打印机驱动能够提供扩展I/F单元，并且应用程序能够通过使用该扩展I/F单元来设定例如打印设置。本发明并不限于具体公开的实施方式，并且在不背离本发明范围的情况下，可以进行变化和修改。