CN103324450B

CN103324450B - 信息处理设备和信息处理方法

Info

Publication number: CN103324450B
Application number: CN201310087523.XA
Authority: CN
Inventors: 玉岛大辅
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2012-03-19
Filing date: 2013-03-19
Publication date: 2016-03-09
Anticipated expiration: 2033-03-19
Also published as: JP5919925B2; JP2013196372A; US8922823B2; CN103324450A; US20130242348A1

Abstract

本发明涉及信息处理设备和存储介质。一种非瞬态计算机可读记录介质，其中存储有程序，用于使计算机执行控制来自应用的文档的打印作业的方法。程序包括：控制程序，使用作业ID控制打印作业；设置接收程序，接收设置条件；图像处理程序，将文档转换为打印数据；以及打印数据处理程序，通过图像数据存储作业ID。该方法包括获取作业ID，生成图像数据，以及将作业ID和图像数据存储在由设置接收程序执行的打印数据处理程序中的步骤；并且包括获取文档和作业ID，接收图像数据，并且将图像数据和文档转换为由图像处理程序执行的打印数据的步骤。

Description

信息处理设备和信息处理方法

技术领域

本披露总地涉及信息处理设备，其运行具有如下步骤的程序：显示和接收打印设置条件的步骤和将文档数据转换为打印数据的步骤。

背景技术

通过传真机发送由个人计算机上的应用生成的文档数据是可能的。在这种情况下，应用调用打印机驱动器(精确地，其是PC-fax驱动器，尽管这里由于存在许多共同操作而被称为打印机驱动器)，该打印机驱动器与传真机交换数据，使得用户可以设置地址等。

打印机驱动器提供了增加附信(coverletter)的功能。这里，附信是其上具体指定了要被发送的文档数据的发送者、地址等的页，其是独立于文档数据生成的。

图1是示出附信的例子的示意图。这里，在“至”这行下面显示了公司名称、部门名称、接收者姓名等，并且在“来自”这行下面显示了公司名称、部门名称、发送者姓名、电话号码、传真号等。

如果当设置打印机驱动器的发送参数时激活了加入附信的功能，则打印机驱动器通过生成附信数据来启动发送作业，然后打印附信数据，并且最终打印文档数据。由此，附信被作为文档数据的附页发送。

然而，对于用户来说在用户开始了传真发送作业之后再设置地址等是困难的。为了应对这个问题，提出了若干技术(例如参见日本公开专利申请号2010-066876)。

<用于在WindowsOS上打印的机制>

为了解释现有技术，首先将描述用于在Windows(注册商标)OS上打印的机制。作为在WindowsOS上打印的机制，存在两种后台打印(spool)格式，一种是RAW后台打印格式，另一种是EMF后台打印格式。

使用RAW后台打印格式，应用处理执行打印操作，其中来自应用的打印数据被转换为可以由打印机解释的数据。从用户的观点，用户不能操作应用直到打印操作完成。

使用EMF后台打印格式，应用处理将来自应用的打印数据转换为后台打印的独立于设备的EMF数据格式(中间数据)。然后，后台打印程序处理执行打印操作，其中由应用处理后台打印的EMF数据被转换为可以由打印机解释的数据。从用户的观点，用户可以在由应用处理完成至EMF数据的转换之后操作该应用。

<指向&打印>(point&print)

对于在WindowsOS上工作的打印机驱动器来说，存在用于打印机驱动器的安装格式，称为指向&打印。

图2是示出指向&打印的示意图。在打印机、服务器PC和客户端PC通过网络彼此连接的系统中，指向&打印可以用于客户端PC来通过使用服务器PC作为打印机驱动器而在打印机上执行打印作业。

在这样的系统中，客户端PC需要具有被安装作为服务器PC的相同的打印机驱动器。花费很多时间和劳力来在网络上的各个客户端PC中的每一个上安装打印机驱动器。

指向&打印是这种不便的解决方案，其是用于从服务器PC向客户端PC下载和安装打印机驱动器的机制。指向&打印是WindowsOS的一个标准功能。

通过指向&打印在客户端PC上安装了打印机驱动器，用户可以设置是否在客户端PC或服务器PC上执行绘制操作。在客户端PC上执行绘制操作被称为客户端侧着色，而在服务器PC上执行绘制操作被称为服务器侧着色。

对于由指向&打印安装的打印机驱动器，存在RAW后台打印格式和EMF后台打印格式用于打印。

上面已经描述了背景，下面将描述开始发送传真之后使得用户能够设置地址等的三个技术。然而，这三个技术中的每一个都有其自己的问题。

1.用于通过绘制驱动器添加附信的方法

图3是示出了用于通过绘制驱动器添加附信的方法的示意图。UI(用户界面)驱动器显示了用于在开始打印作业之前设置打印条件的屏幕，用于接收用户的打印条件的设置。绘制驱动器从反映该设置的文档数据生成图像数据。

通过由绘制驱动器添加附信，当使用RAW后台打印程序、EMF后台打印程序和由指向&打印安装的打印机驱动器打印时，可以增加附信。这里，绘制驱动器已经增加了显示用于接收打印条件的设置的屏幕的功能。

然而，为了增加附信数据，绘制驱动器需要使用GDI(图形设备接口)调用，例如用于绘制字符的Textout()等，来对OS进行请求。当绘制驱动器操作时，其在OS的系统授权下操作。由此，进行GDI调用可以降低驱动器在OS之间的兼容性，因为一些OS可能不接收需要系统授权的GDI调用。

2.使用具有UI驱动器的DDI(设备驱动器接口)的DrvDocumentEvent()来添加附信的方法

图4是示出了用于通过UI驱动器添加附信数据的方法的示意图。在图4中，UI驱动器使用DrvDocumentEvent()生成附信数据，其被存储在要被绘制驱动器打印的文件或存储器中。

这里，使用DrvDocumentEvent()，UI驱动器的DDI。在DrvDocumentEvent()中，调用GDI。由于UI驱动器以与应用相同的授权等级操作，因此没有减小兼容性。然而，绘制驱动器和UI驱动器是分开的模块，二者不能彼此直接通信以交换信息，因为驱动器基本上仅由OS通过DDI调用。

由此，为了在UI驱动器和绘制驱动器之间交换数据，使用了临时文件。UI驱动器输出生成的附信数据至临时文件，并且绘制驱动器读取临时文件，这能够在UI驱动器和绘制驱动器之间交换数据。

然而，通过使用临时文件的方法，根据打印机驱动器的操作定时或对用户给出的授权等级可能不能安全地输出文件。

图5是示出了使用临时文件的问题的示意图。如图5所示，在多个应用操作的环境中，存在临时文件中写入的设置被覆盖的可能性。例如，在临时文件中存储的应用1的附信数据在应用1使用存储的数据之前被另一个应用2覆盖。从应用1的观点，在绘制驱动器读取用于发送由应用1生成的文档数据的内容之前，在附信数据已经由UI驱动器保存用于应用1之后，改变临时文件的内容。

为了解决这个问题，附信数据可以被保存在打印设置存储模块(例如DEVMODE结构)中，而不是临时文件中。

然而，即使使用该方法，也存在该问题不能被解决的如下两种情况：

2-1具有EMF后台打印的情况

2-2具有由指向&打印安装的打印机驱动器的情况

2-1.具有EMF后台打印的情况

是否可以使用用于存储打印设置的模块依赖于用于打印的DDI调用序列。使用RAM后台打印这是可能的。

然而，使用EMF后台打印，来自WindowsOS的DDI调用序列是不同的。使用EMF后台打印，存在两种打印处理序列作为OS中的内部操作，一种是将来自应用的打印数据转换为EMF数据的处理序列，另一种是将EMF数据转换为可以由打印机解释的数据的处理序列。由此，具有EMF后台打印的DDI调用序列与具有RAW后台打印的序列相比更复杂，这使得很难在期望的定时交换附信数据。

2-2具有由指向&打印安装的打印机驱动器的情况

可以在用户使用PC上安装的打印机驱动器的本地环境中使用利用打印设置存储模块的方法。

然而，如果打印机驱动器由指向&打印安装，并且使用服务器侧着色来操作打印机驱动器，则UI驱动器在客户端PC上操作，而绘制驱动器在服务器PC上操作。

服务器侧着色原本使用物理分离的PC，由此打印设置存储模块仅存在于客户端PC。在这种情况下，附信数据不能被交换，因为绘制驱动器不能从打印设置存储模块获取发送设置。

3.用于将附信数据添加到使用UI驱动器中的DrvDocumentEvent()接收的设备上下文的方法

图6A-6B是示出了用于将附信数据添加到设备上下文的方法的示意图。在该方法中，UI驱动器直接地将附信数据添加到使用DrvDocumentEvent()接收的设备上下文。从应用的观点，附信数据仅在时间文档打印之前由UI驱动器添加，由此一页看起来被添加到原始打印文档。

使用该方法，不会引起具有上述方法2的问题，因为在UI驱动器和绘制驱动器之间不存在数据交换。

然而，该方法具有使用64位WindowsOS的问题。如图6B所示，可以在64位OS上操作32位应用。为了在64位WindowsOS上运行32位应用，64位WindowsOS提供了称为WOW64(在Windows仿真子系统上的Windows)的机制。另一方面，部分设备驱动器在内核模式中操作，所以这使得64位符合64位OS本身。当打印时，64位WindowsOS运行被称为splwow64.exe的处理作为WOW64的功能。

在这种情况下，存在两种不同的设备上下文，一种是由语言监视器32位应用生成的设备上下文，另一种是UI驱动器对其进行写入操作的splwow64.exe的设备上下文。由此，UI驱动器不能接收附信数据。

发明内容

如上所述，现有的方法存在问题。本发明至少一个实施例的一般目的在于提供一种程序，其可以发送附信而不损失与OS的兼容性，并且不受后台打印格式、安装方法和OS之间的差异的影响。

根据本发明的至少一个实施例，一种非瞬态计算机可读记录介质，其中存储有程序，用于使计算机执行控制由应用生成的文档数据的打印作业的方法。程序是：控制程序，通过向打印作业分配ID来控制由应用生成的文档数据的打印作业的执行；设置接收程序，显示用于从用户接收打印作业的设置条件的屏幕；图像处理程序，从应用接收基于由设置接收程序接收的设置条件而要被转换成打印数据的文档数据；以及，打印数据处理程序，存储与图像数据相关联的打印作业的ID。该方法包括如下步骤：(a)从控制程序获取打印作业的ID，此步骤由设置接收程序执行；(b)如果设置条件中指定了用于生成图像数据的命令，则生成图像数据，此步骤由设置接收程序执行；(c)将与图像数据相关联的打印作业的ID存储到打印数据处理程序中，此步骤由设置接收程序执行；(d)从应用获取文档数据，并且从控制程序获取该ID，此步骤由图像处理程序执行；(e)通过控制程序接收与在打印数据处理程序中存储的该ID相关联的图像数据，此步骤由图像处理程序执行；以及(f)根据设置条件将图像数据和文档数据转换成打印数据，此步骤由图像处理程序执行。

根据本发明的至少一个实施例，可以提供一种程序，其可以发送附信而不损失与OS的兼容性，并且不受后台打印格式、安装方法和OS之间差异的影响。

附图说明

实施例的其他目的和进一步的特征将在结合附图阅读时从下面的具体实施方式中显而易见。

图1是示出附信的例子的示意图；

图2是示出指向&打印的示意图；

图3是示出用于通过绘制驱动器添加附信数据的方法的示意图；

图4是示出了用于由UI驱动器添加附信数据的方法的示意图；

图5是示出了使用临时文件的问题的示意图；

图6A-6B是示出了用于将附信数据添加到设备上下文的方法的示意图；

图7是示出了根据本发明的实施例的打印机驱动器的总体特征的示意图；

图8A是打印系统的总体配置图；

图8B是客户端PC的硬件配置图；

图9是客户端PC和打印机驱动器的功能框图；

图10是示出了语言监视器的行为的示意图；

图11是示出了在WindowsOS的打印框架中的绘制驱动器和UI驱动器的示意图；

图12是示出了在WindowsOS的打印框架中使用RAW后台打印的处理流程的示意图；

图13是在WindowsOS的打印框架(RAW后台打印)中的时序图；

图14是示出了使用WindowsOS的打印框架中使用EMF后台打印的处理流程的示意图；

图15是WindowsOS的打印框架(EMF后台打印)中的时序图；

图16A是示出了函数ExtEscape()的格式的示意图；

图16B是函数ExtEscape()的时序图；

图17A是示出了函数DrvDocumentEvent()的格式的示意图；

图17B是示出了函数SendRecvBidiDataFromPort()的格式的示意图；

图18A是结构PBIDI_REQUEST_CONTAINER的格式的示意图；

图18B是结构BIDI_REQUEST_DATA的格式的示意图；

图19是示出了由WindowsOS分配的作业ID的示意图；

图20是示出了在语言监视器中存储的作业ID和发送设置的示意图；

图21是WindowsOS的打印框架中的RAM后台打印的时序图；

图22是WindowsOS的打印框架中的EMF后台打印的时序图；

图23是提供有指向&打印的打印系统的总配置图；以及

图24是示出了在指向&打印环境中语言监视器的操作的示意图。

具体实施方式

下面将参考附图描述本发明的实施例。

[第一实施例]

图7是示出根据本发明的实施例的打印机驱动器的总体特征的示意图。在本实施例中，打印机驱动器的行为被看做示例，因为打印机驱动器和PC-fax驱动器具有共同的内部行为，一些不同之处在于用户界面和部分功能。打印机驱动器和PC-fax可以被用作多功能外围设备的设备驱动器。由此，打印机驱动器可以被称为PC-fax驱动器。在下文中，MFP被简称为打印机，假设打印机具有传真功能。

在图7中，假设应用运行在个人计算机上安装的WindowsOS上。在WindowsOS的打印构架中，来自应用的文档数据由打印驱动器的绘制驱动器处理，然后通过图7所示的软件层发送给打印机。这里，对后台打印格式没有进行区别。

用于客户端的WindowsOS包括WindowsNT、Windows98、Windows2000、WindowsMe、WindowsXP、WindowsVista、Windows7、Windows8和这些OS的后续版本。用于服务器的WindowsOS包括Windows2000服务器、2003服务器、2008服务器和这些OS的后续版本。在本实施例中，优选地使用WindowsOS，尽管OS不局限于此，但是可以使用与WindowsOS具有等效功能的任何其他OS。

下面是用于将数据发送给打印机的处理步骤。如图7所示，本实施例中的打印机驱动器具有它的一个功能：打印机驱动器使用语言监视器和作业ID来将图像数据从UI驱动器发送给绘制驱动器。

注意，本实施例中在“打印框架”、“打印开始”、“打印处理”等中使用的术语“打印”意味着绘制驱动器执行绘制处理，其被用于打印作业和传真发送作业。由此，术语“打印”的含义并不必须意味着通过打印机在纸张上打印。

1.一旦用户开始发送操作，应用通过WindowsOS调用UI驱动器。用户进入发送设置，包括地址等，然后按下执行按钮。

2.应用调用WindowsOS的GDIAPI函数(以分配用于打印机的设备上下文)。

3.WindowsOS分配作业ID至每个发送作业。分配的作业ID被指示给打印机驱动器30。

4.UI驱动器创建附信数据。附信数据是图像数据。

5.UI驱动器将从应用获得的发送设置和附信数据以及作业ID指示给语言监视器32。发送设置可以存储在DEVMODE中。由此，其可以不是必须存储在语言监视器32中。

语言监视器32存储附信数据和与WindowsOS生成的作业ID相关联的发送设置。语言监视器32使用作业ID作为关键词(key)来管理附信数据和发送数据。由此，这些可能不会由其他应用覆盖。

6.当绘制驱动器读取发送设置和附信数据时，它可以通过指定作业ID从语言监视器32获取发送设置和由UI驱动器生成的附信数据。如上所述，绘制驱动器可以唯一地识别附信数据。

如果使用打印构架中的EMF后台打印，则在两个打印处理序列中使用作业ID作为关键词来参考语言监视器32。由此，发送设置和附信数据可以被安全地互换。

7.绘制驱动器从文档数据和发送设置生成绘制数据(已经生成了附信数据)。

8.语言监视器32执行需要的操作。

9.端口监视器42根据打印机端口的类型(USB、TCP/IP等)输出所需的数据。

10.图像数据被发送给打印机。

因为语言监视器32是WindowsOS的功能，其可用在指示&打印环境中的服务器PC上。由此，UI驱动器可以使用WindowsOS的功能访问服务器PC上的语言监视器32，并且当服务器PC上的绘制驱动器执行绘制处理时，可以从语言监视器32获得使用作业ID指定的附信数据(和发送设置)。如上所述，在本实施例中的附信数据的管理在指示&打印环境中以及本地安装打印机驱动器30的环境中是有效的。

此外，如果32位应用在64位WindowsOS上运行，则64位UI驱动器使用语言监视器32，因为当32位应用开始打印作业时操作splwow64.exe的处理。由此，64位绘制驱动器可以在创建附信数据时访问语言监视器32。

由此，本实施例中的打印机驱动器可以发送附信而不损失与OS的兼容性，并且不受后台打印格式(RAW后台打印、EMF后台打印)、安装方法(本地安装、指示&打印安装)和OS(32位OS，64位OS)之间的差异的影响。

传统地，语言监视器32仅用作端口监视器42的接口。当使用WindowsOS时，打印机驱动器30可以使用由OS提供的语言监视器32或者由打印机、传真机等的制造商提供的语言监视器32。在本实施例中，可以使用由OS提供的语言监视器32或由制造商提供的语言监视器32。

[配置实例]

图8A是打印系统400的总体配置图。图8B是客户端PC100的硬件配置图。客户端PC100和打印机200通过网络300彼此连接。仅具有一个打印机200的另一个配置也是可能的。

客户端PC100接收用户操作，并且具有应用，例如文档创建软件，其使用GDI、DDI、打印机驱动器等进行打印作业的请求。打印机驱动器30使用后面描述的步骤生成打印数据，然后将打印数据发送给打印机200。如果具有传真功能，则打印机200可以被称为另一个名字，例如复印件、传真机等。在本实施例中，打印机200至少具有传真功能。此外，打印机200可以通过电子摄像或喷墨具有图像形成功能。此外，PC100和打印机200可以通过USB电缆等彼此直接连接。

客户端PC100具有通过总线彼此连接的CPU11、ROM12、RAM13、外部接口14、通信设备15、输入设备16、显示控制部17和存储设备18。CPU11从存储设备18读取OS10、应用31和打印机驱动器30，以使用RAM13作为工作存储器来运行这些程序。

应用31可以是对打印机200进行打印作业的请求的任何应用。例如，它可以是文档创建软件、浏览器、演讲材料生成软件等。其可以是请求打印由应用创建、编辑、显示或管理的文档数据的任何应用。这里，文档数据不仅包括字符、符号或数字，还包括图像、图片或任何其他可打印数据。

RAM13是用于存储所需数据的工作存储器(主存储器)。ROM12存储BIOS、初始化数据、引导程序等。

外部接口14是附接于电缆(例如USB电缆)或便携存储介质20的接口。通信设备15是LAN卡或以太网(注册商标)卡，其响应于来自CPU11的指示将帧数据(在本实施例中主要是打印数据)发送给打印机200。

输入设备16是用户接口设备，例如键盘、鼠标等，以从用户接收各种操作。输入设备可以包括触摸面板或语音识别设备。显示控制部17基于由应用31指示的屏幕信息使用预定的解析度或多个颜色来控制显示器19上的显示。显示器19可以是FPD(平板显示器)，例如LCD或有机EL显示器。

存储设备18是非易失性存储器，例如硬盘驱动器或闪存，以存储OS10、打印机驱动器30和应用31。

存储介质20是非易失性存储器，例如SD卡、USB存储器等。打印机驱动器30由存储介质20分发或者通过从服务器(未显示)下载来分发。

图9是客户端PC100和打印机驱动器30的功能框图。客户端PC100包括在WindowsOS上运行的应用31、打印机驱动器30、语言监视器32和通信部40。其中，语言监视器32具有WindowsOS。由此，其可以在广义上被看做WindowsOS的一部分。此外，后台打印程序、打印机驱动器等也和WindowsOS一起安装在客户端PC100上，这里省略了对其的解释。

打印机驱动器具有UI驱动器38和绘制驱动器39。此外，UI驱动器38具有数据生成部381。当用户对应用31进行发送文档的请求时，UI驱动器38在显示器19上显示发送设置屏幕。用户可以在发送设置屏幕上设置传真号、姓名、公司名称、部门名称和是否增加附信等。如果地址簿是可用的，则可以从地址簿选择传真号。

此外，在用户发出了开始发送的命令之后，UI驱动器38可以通过在显示器19上显示发送设置屏幕来接受对发送设置的改变。

数据生成部381生成附信数据，例如图1所示的附信数据。预先提供了附信的模板，其中在预定的位置可以提供发送者姓名、公司名称和部门名称以及接收者传真号、接收者姓名、公司名称和部门名称。数据生成部381在附信数据的模板上布置使用发送设置屏幕设置的发送设置，然后将布置的模板转换为绘制数据。通过预先准备发送设置屏幕和模板，可以将各种信息转换为图像数据。

此外，绘制驱动器39并不必须在作为附页的第一页中而是可以在第二页或后面的页中加入附信数据。此外，附信数据可以打印在多个页上，或者附信数据可以并入到文档数据中。例如，可以使用消息(例如“由传真发送的文档”)或图标来显示文档数据的全部页或部分页。

注意尽管附信数据通常不是在打印作业中生成的，但相同的UI驱动器38和绘制驱动器39可以被共同地用于打印作业和发送作业。由此，可以通过打印作业打印从打印设置或发送设置生成的图像数据。

发送设置存储在被称为DEVMODE结构(下文中称为DEVMODE)的结构(数据表)中。DEVMODE是对WindowsOS上操作的各种打印机驱动器30的共同设置的发送条件定义了成员变量的数据结构。

通过参考DEVMODE，绘制驱动器39从要由应用31打印的反映了发送设置的文档数据创建打印数据。这里，打印数据包括绘制数据(例如PDL数据)和控制数据(例如PJL的打印命令)。

语言监视器32具有数据保持部321和通信部322。当打印机驱动器将打印数据发送给通信部40(其也包括在现有语言监视器32中)时，通信部322控制通信。通信部322执行客户端PC100的语言监视器32和通信部40之间的数据的发送/接收控制。通信部322还可以通过通信部40从打印机200接收消息。另一方面，数据保持部321使用作业ID作为关键词来存储附信数据。使用语言监视器32的功能通过打印机驱动器30实现数据保持部321。由此，不需要改变WindowsOS或者很少改变。将在下面描述保持部321。

客户端PC的通信部40是与打印机200进行通信的部，其根据协议例如TCP/IP执行通信。

图10是示出了语言监视器32的行为的示意图。语言监视器32接收从打印处理器41发送的打印数据，并且将其发送给通信部40(端口监视器42和端口驱动器43)。打印处理器41具有后台打印的功能。打印处理器41基于通信协议执行操作以将打印数据发送给端口驱动器43。端口驱动器43控制打印机200和客户端PC100之间的连接接口(USB、NIC等)以将打印数据发送给打印机200。

[WindowsOS的传统打印构架]

图11是示出了在WindowsOS的打印构架中的绘制驱动器和UI驱动器的示意图。

WindowsOS的GDI34使用DDI调用来调用打印机驱动器30的UI驱动器38和绘制驱动器39。UI驱动器38和绘制驱动器39不能直接彼此通信。然而，这两个驱动器可以参考DEVMODE，因为当从WindowsOS对驱动器进行调用时，DEVMODE可以被指定为自变量。

*当从WindowsOS调用时，UI驱动器38接收用户的发送设置以存储在DEVMODE中。

*当开始准备打印作业时，DEVMODE信息被从WindowsOS传送给绘制驱动器39。即，当开始准备打印作业以基于发送设置生成打印命令和绘制数据时，UI驱动器38确定由绘制驱动器39接收的发送设置。这是WindowsOS的打印构架中的基本打印序列。由于绘制驱动器39在UI驱动器39之后开始其操作，因此通用打印机驱动器30不可能在从用户接收打印开始命令之后改变发送设置。

图12是示出了在WindowsOS的打印构造中使用RAM后台打印的处理流程的示意图。

(1)用户通过UI驱动器38提供的打印对话(GUI)改变发送设置(改变已经注册的初始值)。

(2)用户将打印开始命令发给应用31。

(3)应用31通过与UI驱动器38交换包括发送设置的DEVMODE信息来从用户接收发送设置。

(4)应用31将打印命令和DEVMODE信息传送给GDI34作为GDI调用。

(5)GDI34将GDI调用转换为要被传送给绘制驱动器39的DDI调用。

(6)绘制驱动器39向后台打印程序35发送被转换为可以由打印机200解释的语言的RAW数据。

(7)后台打印程序35将从绘制驱动器39接收的RAW数据发送给打印机200。

图13是与图12所示的流程相关的WindowsOS(RAW后台打印)的打印架构中的时序图。这里，没有显示在GDI34和UI驱动器38之间发生的通信或者在GDI34和绘制驱动器39之间发生的通信。从GDI34到UI驱动器38的消息由用户接口DDI函数指示，并且从GDI34到绘制驱动器39的消息由绘制DDI函数指示。

在图13的步骤S1之前，UI驱动器38已经接收了由用户设置的发送设置。在DEVMODE中存储的发送设置由从用户接收打印开始命令的应用31获得。

步骤S1：应用31指示GDI34开始准备打印作业。具体地，应用31通过具有发送设置(DEVMODE)作为自变量的函数CreateDC()来调用GDI34。

步骤S1.1：GDI34通过调用DDI的API函数来将发送设置发送给绘制驱动器39。从应用31传送给GDI34作为CreateDC()的自变量的发送设置被存储在要被指示给绘制驱动器39的DrvEnablePDEV()的自变量中。此后，绘制驱动器39可以参考发送设置直到打印作业完成(直到删除设备上下文)。

步骤S2：当GDI34向应用31指示完成打印作业的准备时，应用31指示GDI34开始打印作业。具体地，应用31使用具有DocINFO等作为自变量的函数StartDoc()来调用GDI34。

步骤S2.1：GDI34指示UI驱动器38开始打印作业。具体地，GDI34发送DrvDocumentEvent()DOCUMENTEVENT_STARTDOCPRE()至UI驱动器38。

步骤S2.2：GDI34指示绘制驱动器39开始打印作业。具体地，GDI34将函数DrvStartDoc()发送给绘制驱动器39。WindowsOS在预定定时通过函数CreateDC()生成作业ID。由于GDI34将作业ID设置为DrvStartDoc()的自变量，因此绘制驱动器39现在能够参考作业ID。

步骤S2.3：类似地，GDI34指示UI驱动器38开始打印作业。具体地，GDI34发送DrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()至UI驱动器38。由于GDI34将作业ID设置为该函数的自变量，因此UI驱动器38现在能够参考作业ID。

步骤S3：当GDI34向应用31指示完成打印作业的开始时，应用31以页为单位重复该操作。首先，应用31指示GDI34接收新页的打印数据。具体地，应用31将StartPage()发送给GDI34。

步骤S3.1：GDI34将DrvStartPage()发送给绘制驱动器39。

步骤S4：在从绘制驱动器39接收响应之后，应用31将绘制函数(文档数据)发送给GDI34。

步骤S4.1：GDI34将绘制函数(文档数据)发送给绘制驱动器39。绘制驱动器39根据发送设置将文档数据转换为打印数据。

步骤S5：在GDI34已经向应用31指示了一页文档数据的绘制操作完成之后，应用31向GDI34指示所述一页的写入操作完成。具体地，应用31将EndPage()发送给GDI34。

步骤S5.1：GDI34向绘制驱动器39指示所述一页的写入操作完成。具体地，GDI34将DrvSendPage()发送给绘制驱动器39。

步骤S6：在完成所有页的绘制操作之后，应用31向GDI34指示打印作业的完成。具体地，应用31将EndDoc()发送给GDI34。

步骤S6.1：GDI34向绘制驱动器39指示打印作业的完成。具体地，GDI34将EndDoc()发送给绘制驱动器39。

步骤S6.2：GDI34向UI驱动器38指示打印作业的完成。具体地，GDI34将DrvDocumentEvent()DOCUMENTEVENT_ENDDOCPOST()发送给UI驱动器38。

此后，删除设备上下文(应用向GDI34指示DeleteDC())，使得绘制驱动器39不能再参考发送设置(绘制驱动器39考虑到已经使用DrvDisablePDEV进行了DDI调用)。

图14是示出了在WindowsOS的打印构架中使用EMF后台打印的处理流程的示意图。

(2)用户将打印开始命令发给应用。

(3)应用通过与UI驱动器38交换包括发送设置的DEVMODE信息来从用户接收发送设置。

(4)应用将打印命令和DEVMODE信息传送给GDI34作为GDI调用。

(5)GDI34将EMF数据作为后台打印数据传送给后台打印应用程序。

(6)在应用31的打印数据被后台打印之后，后台打印程序35指示打印处理器41该数据要被非后台打印并且将后台打印数据传送给打印处理器41。

(7)打印处理器41出于总结、逆排序或出版目的，逐页编辑后台打印的数据，通过GDI调用将其指示给GDI34。

(8)GDI34将GDI调用转换为DDI调用以发送给绘制驱动器39。

(9)绘制驱动器39将RAW数据转换为可以由打印机解释的语言，然后发送给后台打印程序35。

(10)后台打印程序35将从绘制驱动器39接收的RAW数据发送给打印机200。

图15是WindowsOS(EMF后台打印)的打印架构中的时序图。这里，没有显示在GDI34和UI驱动器38之间发生的通信或者在GDI34和绘制驱动器39之间发生的通信。通过EMF后台打印，序列被划分为应用处理和后台打印程序处理。

在图15中的步骤S1之前，UI驱动器38已接收了由用户设置的发送设置。DEVMODE中存储的发送设置是由从用户接收打印开始命令的应用31获得的。在发送设置中设置使用哪一个后台打印，RAW后台打印或EMF后台打印。

步骤S1：应用31指示GDI34开始准备打印作业。具体地，应用31使用具有发送设置作为自变量的函数CreateDC()来调用GDI34。

步骤S1.1：GDI34通过调用DDI的API函数来将发送设置发送给绘制驱动器39。从应用31传送给GDI34作为CreateDC()的自变量的发送设置被存储在要被指示给绘制驱动器39的DrvEnablePDEV()的自变量中。此后，绘制驱动器39可以参考发送设置直到作业完成(直到删除设备上下文)。

步骤S2.1：GDI34指示UI驱动器38开始打印作业。具体地，GDI34发送DrvDocumentEvent()DOCUMENTEVENT_STARTDOC()至UI驱动器38。

步骤S2.2：GDI34发送作业ID至绘制驱动器38。具体地，GDI34将DrvDocumentEvent()DOCUMENT_STARTDOCPOST()发送给UI驱动器38。因为GDI34将作业ID设置为该函数的自变量，因此UI驱动器38现在能够参考作业ID。此时，绘制驱动器39还没有获得作业ID。

步骤S3：当GDI34向应用31指示开始打印作业的完成时，应用31以页为单位重复该操作。首先，应用31指示GDI34接收新页的打印数据。具体地，应用31将StartPage()发送给GDI34，通过StartPage()开始后台打印程序处理。

步骤S4：应用31将绘制函数(文档数据)发送给GDI34。GDI34根据发送设置生成EMF数据。

步骤S5：应用31向GDI34指示完成了一页的写入操作。具体地，应用31将EndPage()发送给GDI34。

步骤S6：在完成所有页的绘制之后，应用31向GDI34指示打印作业的完成。具体地，应用31将EndDoc()发送给GDI34。

由此，在完成应用处理之后，打印作业从应用31的观点看起来已经完成，即使打印还没有实际完成。此后，后台打印程序处理执行剩下的打印作业，其中EMF数据被转换为RAW数据。

WindowsOS监视应用31和GDI34之间的通信，以使后台打印程序35在预定定时开始后台打印处理，例如在StartPage()之后。

步骤S7：后台打印程序35指示打印处理器41开始准备打印作业。具体地，后台打印程序34将PrintDocumentOnPrintProcessor()发送给打印处理器41。

步骤S7.1：打印处理器41指示GDI34开始打印作业的准备。具体地，打印处理器41将GetJobAttributes()发送给GDI34。

步骤S7.1.1：GDI34将发送设置发送给绘制驱动器39。具体地，已经从应用31传送到GDI34作为CreateDC()的自变量的发送设置(DEVMODE)被存储为要被指示给绘制驱动器39的DrvEnablePDEV()的自变量。此后，绘制驱动器39可以参考发送设置直到完成作业(直到删除设备上下文)。

步骤S7.1.2：GDI34指示绘制驱动器39开始打印作业。具体地，GDI34将DrvStartDoc()发送给绘制驱动器39。WindowsOS使用函数CreateDC()在预定定时生成作业ID。由于GDI34将作业ID设置为DrvStartDoc()的自变量，因此绘制驱动器39现在能够参考作业ID。

步骤S7.2：打印处理器41以页为单位重复该操作。首先，打印处理器41指示GDI34接收新页的打印数据。具体地，打印处理器41将GdiStartPageEMF()发送给GDI34。

步骤S7.2.1：GDI34将DrvStartPage()发送给绘制驱动器39。

步骤S7.2.2：GDI34将绘制函数(文档数据)发送给绘制驱动器39。绘制驱动器39根据发送设置将文档数据转换为打印数据。

步骤S7.2.3：GDI34向绘制驱动器39指示新页的写入操作的完成。具体地，GDI34将DrvSendPage()发送给绘制驱动器39。

此后，以页为单元重复该操作。

[在本实施例中WindowsOS的打印架构]

下面将描述根据本实施例的WindowsOS的打印架构。首先将描述在本实施例中的打印构造中使用的API等。图16A是示出了函数ExtEscape()的格式的示意图。ExtEscape()是用于访问不能通过GDI访问的特定模块(对应于时序图或功能框图中的块)的API函数。如果应用31不使用GDI34发送数据到驱动器，或者应用31不使用GDI34从模块获取数据，则可以使用该函数。

*hdc是设备上下文的句柄。

*nEscape是用于检查或设置ExtEscape()的功能的自变量。

*cbInput是使用ExtEscape()发送的结构的尺寸。

*lpszInData是使用ExtEscape()发送的结构的指针。

*cbOutput是用于接收由ExtEscape()发送的结构的结构的尺寸。

*lpszOutData是用于接收由ExtEscape()发送的结构的结构的指针。

ExtEscape()是针对CreateDC()生成的设备上下文可以被调用的API函数。由此，UI驱动器38等可以调用ExtEscape()，只要存在序列中处理的设备上下文。

图16B是当从应用31调用时ExtEscape()的时序图。

(i)应用31使用ExtEscape()调用GDI34。

(ii)GDI34将ExtEscape()转换为DDI调用，DrvEscape()，以指示给绘制驱动器39。

此外，相反地，绘制驱动器39或UI驱动器38可以调用ExtEscape()。ExtEscape()可以从CreateDC()和DeleteDC()之间的模块调用，图16B中所示的时序可以被插入到图13或15所示的前面的时序图中的任意位置。

图17A是示出了函数DrvDocumentEvent()的格式的示意图。DrvDocumentEvent()是用于处理与文档数据的打印相关的特定事件的DLL。

*hPrinter是打印机的句柄。

*hdc是设备上下文的句柄。

*iEsc是分辨由调用模块提供的要被处理的事件的转义码。

*cbIn是pvIn发送的数据的尺寸。

*pvIn是发送数据的指针。

*cbOut在iEsc是DOCUMENTEVENT_ESCAPE时将使用该函数指定的值存储作为ExtEscape()的cbOutput参数，或者在iEsc是DOCUMENTEVENT_QUERYFILTER时存储由接收器接收的结构pvOut的尺寸。

*pvOut是由接收器接收出来的结构的指针。

在本实施例中，在DDI调用的过程中的恰当定时调用DrvDocumentEvent()，在DDI调用过程中GDI34等在CreateDC()之后的打印作业的过程中调用UI驱动器38。由于DrvDocumentEvent()是执行单个操作的DDI调用，因此其不能与DrvDocumentEvent()的之前或之后的调用共享数据。这一点不同于调用绘制驱动器39的DDI。DrvDocumentEvent()是用户界面DDI，其可以显示打印对话屏幕，或者可以生成数据，例如附信。

此外，因为具有设备上下文句柄(dhc)的自变量，因此在使用DrvDocumentEvent()调用DDI之后，模块可以调用需要设备上下文的API。例如，如果UI驱动器38使用设备上下文的自变量调用绘制API，则UI驱动器38可以向对应的绘制驱动器39指示绘制指令。

图17B是示出了函数SendRecvBidiDataFromPort()的格式的示意图。SendRecvBidiDataFromPort()是在语言监视器32中实现的函数。语言监视器32具有由WindowsOS确定的接口函数，与对于打印机驱动器30确定的相同。SendRecvBidiDataFromPort()是接口函数之一，其支持应用31和打印机之间的双向通信，或者支持应用31和打印服务器之间的双向通信。

*hPort是由调用模块给出的端口的句柄。

*dwAccessBit是调用模块给出的ACCESS_MASK结构，用于允许对打印机或打印服务器的访问。

*pAction是由调用模块给出的请求动作。

*pReqData是具有请求数据的PBIDI_REQUEST_CONTAINER结构的指针。

*ppResData是用于接收具有响应数据的PBIDI_RESPONSE_CONTAINER结构的地址的存储器位置的指针。

图18A是示出了结构PBIDI_REQUEST_CONTAINER的格式的示意图。结构PBIDI_RESPONSE_CONTAINER具有实质相同的格式。结构PBIDI_REQUEST_CONTAINER是存储“双向请求”列表的容器，而结构PBIDI_RESPONSE_CONTAINER是用于存储“双向响应”列表的容器。

WindowsOS提供了数据库计划，称为“双向请求和响应计划”，假设请求和响应对可以用于打印机和应用31之间的双向通信。

*版本是计划的版本，例如1。

*标志是为系统(WindowsOS)保留的一组标志，其值必须是零。

*计数是在aData成员的“双向请求”的数目。

*aData[]是BIDI_REQUEST_DATA结构的阵列，其中每个要素具有“双向请求”。

图18B是示出了结构BIDI_REQUEST_DATA的格式的示意图。BIDI_REQUEST_DATA结构存储“双向请求”。

*dwReqNumbers是请求的索引，其用于匹配多个操作请求和响应。

*pSchema是存储计划字符串的第一字节的存储器位置的指针。

*数据是根据计划的BIDI_DATA结构。

<在语言监视器中存储作业ID和附信数据>

传统地，WindowsOS以打印开始命令的接收顺序生成打印作业的唯一ID(作业ID)。使用RAW后台打印或使用EMF后台打印，存在绘制驱动器39或UI驱动器38获取作业ID的步骤。即，绘制驱动器39可以接收作业ID作为DrvStartDoc()的自变量。UI驱动器38可以接收作业ID作为DrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()的自变量。

图19是示出了由WindowsOS分配的作业ID的示意图。应用A和应用B任意发出打印开始命令1至3。

这里，WindowsOS将作业ID1分配给来自应用A的打印开始命令1，将作业ID2分配给来自应用B的打印开始命令2，并且将作业ID3分配给来自应用A的打印开始命令3。

绘制驱动器39或UI驱动器38获取确保了唯一性的这些作业ID。

在本实施例中，使用作业ID作为关键词将附信数据存储在语言监视器32中。

图20是示出了在语言监视器32中存储的作业ID和附信数据的示意图。应用A和B如下开始打印作业。作业ID由WindowsOS以打印作业的顺序分配。

1.应用A通过将附信增加功能设置为打开来开始打印作业。

2.应用B通过将附信增加功能设置为打开来开始打印作业。

3.应用A通过将附信增加功能设置为打开来开始打印作业。

UI驱动器38在已经开始打印作业之后通过显示发送设置屏幕来接收发送设置。因为附信增加功能被设置为打开，因此UI驱动器38生成附信数据。然后，UI驱动器38将发送设置与附信数据相关联，该附信数据使用作业ID作为关键词存储在语言监视器32中。如图20所示，语言监视器32可以以表状结构存储作业ID和附信数据对，以将作业ID与附信数据相关联。

当需要附信数据时，绘制驱动器39使用作业ID作为关键词将关于附信数据的询问发送给语言监视器32。

如上所述，唯一关键词由WindowsOS分配给打印作业，其用于通过语言监视器32存储信息。由此，如果多个应用任意地开始多个发送作业，则打印机驱动器30可以对每个发送作业管理附信数据。由此，通过使用WindowsOS的功能，在打印作业中未覆盖的作业ID可以被用作语言监视器32的数据保持部321中的关键词。

SendRecvBidiDataFromPort()用于在语言监视器32中设置以及对语言监视器32查询。一旦打印机驱动器30使用SendRecvBidiDataFromPort()调用语言监视器32，语言监视器32可以被用作附信数据的存储器。即，通过使用SendRecvBidiDataFromPort()在语言监视器32中实现数据保持部321。

如上所述，即使打印机等的生产商不提供特定语言监视器32，在WindowsOS中内建的标准语言监视器32也是可用的。如果制造商不开发语言监视器32，则可以使用标准语言监视器32。如果生产商愿意遵守预定接口开发语言监视器的话，其可以增加独特的功能。在本实施例中，打印机驱动器30等可以使用称为SendRecvBidiDataFromPort()的接口函数与语言监视器32交换数据。

具体地，在作为COM接口的例子的IBidiRequest的SetSchema()中设置作业ID。在IBidiRequest的SetInputData()中设置附信数据。当UI驱动器38通过设置IBidiRequest对象来调用SendRecv()时，后台打印程序调用SendRecvBidiDataFromPort()以在语言监视器32中设置作业ID和附信数据。例如，在SendRecvBidiDataFromPort()的第三个自变量pAction中设置作业ID，并且在第四个自变量pReqData中设置附信数据。

当绘制驱动器39读取附信数据时，绘制驱动器39通过设置IBidiRequest对象来调用SendRecv()，从而在IBidiRequest中存储附信数据。然后，绘制驱动器39可以通过调用IBidiRequest的GetOutputData()来获得附信数据。

尽管UI驱动器38和绘制驱动器39均没有直接调用SendRecvBidiDataFromPort()，但可以看做他们实际上调用了SendRecvBidiDataFromPort()。

<操作时序>

*RAW后台打印

图21是用于WindowsOS的打印架构中的RAM后台打印的时序图。这里，没有显示在GDI34和UI驱动器38之间发生的通信或者在GDI34和绘制驱动器39之间发生的通信。通过用户界面DDI函数来指示从GDI34到UI驱动器38的消息，并且由绘制DDI函数指示从GDI34至绘制驱动器39的消息。

在图21中的步骤S1之前，UI驱动器38已经接收了由用户设置的发送设置。DEVMODE中存储的发送设置是由从用户接收打印开始命令的应用31获得的。

步骤S2.2：GDI34指示绘制驱动器39开始打印作业。具体地，GDI34将函数DrvStartDoc()发送给绘制驱动器39。WindowsOS使用函数CreateDC()在预定定时生成作业ID。由于GDI34将作业ID设置为DrvStartDoc()的自变量，因此绘制驱动器39现在能够参考作业ID。

步骤S2.3：类似地，GDI34指示UI驱动器38开始打印作业。具体地，GDI34将DrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()发送给UI驱动器38。因为GDI34将作业ID设置为该函数的自变量，因此UI驱动器38现在能够参考作业ID。

步骤S2.3.1：这里，数据生成部381需要参考发送设置以生成(或者确定是否生成)附信数据，但是数据生成部381不能直接与绘制驱动器39通信。由此，数据生成部381将ExtEscape()发送给GDI34。

步骤S2.3.1.1：GDI34向绘制驱动器39指示DrvEscape()。绘制驱动器39通过GDI34将绘制驱动器39保持的发送设置发送给UI驱动器38。

步骤S2.3.2：通过执行ExtEscape()，UI驱动器38现在获得发送设置。如果附信数据被指定为在发送设置中生成，则UI驱动器38生成附信数据，例如图1中的附信数据。如果发送设置被指定为在发送设置中重新显示或修改，则再次显示发送设置。

步骤S2.3.3：当用户关闭打印对话时，UI驱动器38使用SendRecvBidiDataFromPort()::set将与作为关键词的作业ID相关联的附信数据发送给语言监视器32。这里，“：：”意味着“DOCUMENTEVENT”被缩写。由此，语言监视器32可以与作业ID相关联地存储附信数据。此时，也可以发送用户关闭的打印对话的方式，“确认”或“取消”。

步骤S3：当GDI34向应用31指示打印作业开始的完成时，应用31以页为单位重复该操作。首先，应用31指示GDI34接收新页的打印数据。具体地，应用31将StartPage()发送给GDI34。

步骤S3.1：GDI34将DrvStartPage()发送给绘制驱动器39。

步骤S3.1.1：绘制驱动器39仅当使用DrvStartPage()接收第一DDI调用时，使用作业ID作为关键词通过SendRecvBidiDataFromPort()::get向语言监视器32请求附信数据。这里语言监视器32保持关于用户关闭的打印对话的方式(“确认”或“取消”)的信息。如果用户使用“确认”进行了关闭，则绘制驱动器39根据发送设置生成打印数据。如果用户使用“取消”进行了关闭，则绘制驱动器39不向传真设备发送数据。

步骤S4：在从绘制驱动器39接收响应之后，应用31将绘制函数(文档数据)发送给GDI34。步骤S4.1：GDI34将绘制函数(文档数据)发送给绘制驱动器39。绘制驱动器39根据发送设置将文档数据转换为打印数据。剩下的步骤与前面类似。由此，省略其描述。

由此，绘制驱动器39可以从语言监视器32获取使用作业ID唯一识别的附信数据。

*EMF后台打印

图22是用于WindowsOS的打印架构中的EMF后台打印的时序图。这里，没有显示在GDI34和UI驱动器38之间发生的通信或者在GDI34和绘制驱动器39之间发生的通信。

在图22中的步骤S1之前，UI驱动器38已经接收了由用户设置的发送设置。DEVMODE中存储的发送设置是由从用户接收打印开始命令的应用31获得的。

步骤S2.2：GDI34将作业ID发送给UI驱动器38。具体地，GDI34将DrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()发送给UI驱动器38。由于GDI34设置作业ID作为该函数的自变量，因此UI驱动器38现在能够参考作业ID。此时，绘制驱动器39还没有获得作业ID。

步骤S2.2.1：这里，UI驱动器38使用设备上下文作为自变量通过ExtEscape()调用GDI34，以确定是否需要生成附信数据。

步骤S2.2.1.1：GDI34通过将使用DrvEcape()的DDI调用发送给绘制驱动器39，来请求由绘制驱动器39保持的发送设置。绘制驱动器39通过GDI34将绘制驱动器39保持的发送设置发送给UI驱动器38。

步骤S2.2.2：通过执行ExtEscape()，UI驱动器38现在获得发送设置。如果附信数据被指定为在发送设置中生成，则UI驱动器38生成如图1所示的附信数据。如果发送设置被指定为在发送设置中重新显示或修改，则发送设置被再次显示。

步骤S2.2.3：当用户关闭打印对话时，UI驱动器38使用SendRecvBidiDataFromPort()::set将与作为关键词的作业ID相关联的附信数据发送给语言监视器32。由此，语言监视器32可以保持与作业ID相关联的附信数据。此时，还发送用户关闭打印对话的方式，“确认”或“取消”。

下面的步骤S3至S6与上面描述的相同。由此，省略其描述。使用如上所述的步骤，应用处理完成其在打印作业中的角色(生成EMF数据)。

此后，后台打印程序35的处理执行剩下的打印作业，其中EMF数据被转换为RAW数据。WindowsOS监视应用31和GDI34之间的通信，以使后台打印程序35在预定定时开始后台打印处理，例如在StartPage()之后。

步骤S7：后台打印程序35指示打印处理器41开始准备打印作业。

步骤S7.1：打印处理器41指示GDI34开始打印作业的准备。

步骤S7.1.1：GDI34将发送设置发送给绘制驱动器39。具体地，已经从应用31传送到GDI34作为CreateDC()的自变量的发送设置被存储为要被指示给绘制驱动器39的DrvEnablePDEV()的自变量。此后，绘制驱动器39可以参考发送设置直到完成作业(直到删除设备上下文)。

步骤S7.2.1：GDI34将DrvStartPage()发送给绘制驱动器39。

步骤S7.2.1.1：仅当使用DrvStartPage()接收第一DDI调用时，绘制驱动器39使用作业ID作为关键词通过SendRecvBidiDataFromPort()::get向语言监视器32请求附信数据。这里，语言监视器32在步骤S2.2.2保持关于用户关闭打印对话的方式(“确认”或“取消”)的信息。如果用户使用“确认”进行了关闭，则绘制驱动器39根据发送设置生成打印数据。如果用户使用“取消”进行了关闭，则绘制驱动器39不向传真设备发送数据。

步骤S7.2.3：GDI34向绘制驱动器39指示新页的写入操作的完成。具体地，GDI34将DrvSendPage()发送给绘制驱动器39。此后，以页为单元重复该操作。

如上所述，通过使用作业ID作为关键词在语言监视器32中保持附信数据，如果在EMF后台打印已经开始第一个打印作业之后另一个作业生成附信数据，则不存在覆盖的风险。

由于后台打印格式的不同，图21和22中的打印时序看起来不同。然而，在下面每个函数中执行的操作对于RAW后台打印和EMF后台打印是相同的：

绘制驱动器39的

*DrvEnablePDEV()

*DrvStartDoc()

*DrvStartPage()

*DrvEscape()

UI驱动器38的

*DrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()

以及

语言监视器32的

*SendRecvBidiDataFromPort()::set

*SendRecvBidiDataFromPort()::get

由此，根据本实施例可以管理附信数据而不考虑后台打印格式。此外，在多个应用操作的环境中，通过使用语言监视器32，可以发送附信数据而不被其他应用破坏。此外，可以保持与WindowsOS的兼容性，因为绘制驱动器39不生成附信数据。

<在64位OS上运行32位应用的情况>

如果应用是32位应用并且WindowsOS是64位OS，则存在UI驱动器38使用WOW64作为splwow64.exe的处理操作的情况。即使应用是32位应用，对于这里为64位处理的绘制驱动器39来说，也可能访问语言监视器32来获取附信数据，因为UI驱动器38在作为64位处理运行的语言监视器32中记录作业ID和附信数据。

具体地，应用31由splwow64.exe替代，并且应用处理由splwow64处理替代，这导致图21和22中所示的时序图中没有变化。

由此，本实施例中的设备驱动器可以发送附信而不损失与OS的兼容性，并且不受后台打印格式(RAW后台打印、EMF后台打印)、安装方法(本地安装、指示&打印安装)和OS(32位OS、64位OS)之间的差异的影响。

[第二实施例]

在本实施例中，将描述在指向&打印环境中使用语言监视器32的附信数据的管理。

图23是提供有指向&打印的打印系统的总体配置图。四个客户端PC1-4通过网络与服务器PC110连接。打印机200与服务器PC110连接，其可以是通过网络连接。

打印机驱动器30被安装在服务器PC110中，其可以由服务器PC110复制并分发给客户端PC1-4。由此，无需用户的干涉，打印机驱动器30可以由服务器PC110和客户端PC1-4的协作而安装。下文中，假设客户端PC1与服务器PC110连接，并且打印机驱动器30由指向&打印安装。

通过在指向&打印环境中的服务器侧着色，很难共享发送设置，因为客户端PC接收用户的发送设置并且服务器PC执行绘制操作。

另一方面，在本实施例中，客户端PC1和服务器PC110在WindowsOS提供的打印构架中使用语言监视器32互换发送设置和附信数据。由此，服务器PC110可以从打印架构内的客户端PC1获得附信数据。

图24是示出了在指向&打印环境中语言监视器32的操作的示意图。语言监视器32是内建到WindowsOS的打印构架中的模块。由此，如果UI驱动器38在客户端PC1上运行，并且绘制驱动器39通过指向&打印在服务器PC110上运行，则语言监视器32仅在服务器PC110上运行。尽管语言监视器32也安装在客户端PC1上，但在这种情况下其不能操作。

由此，客户端PC1上的UI驱动器38和服务器PC110上的绘制驱动器39访问而单个语言监视器32。

客户端PC1的WindowsOS和服务器PC110的WindowsOS建立了用于客户端PC1和服务器PC110的通信路由(例如使用RPC(远程过程调用))。

由于客户端PC1和服务器PC110二者已分别安装了WindowsOS，因此他们可以共同地使用WindowsOS的打印构架中提供的语言监视器32。由此，不容易发生访问权限错误或通信错误，如果使用第三方制造商独立开发的模块，则很有可能发生这些错误。基于相同的原因，其与WindowsOS高度兼容。

注意，尽管指向&打印支持RAW后台打印和EMF后台打印，但服务器侧着色不提供给RAW后台打印。这是因为执行着色的PC是受限的，因为RAW后台打印是应用处理。

对于其他情况，即，使用RAW后台打印的客户端着色、使用EMF后台打印的客户端侧着色和使用EMF后台打印的服务器侧着色，语言监视器32可以如图34所示被使用。

如果32位应用在64位OS上运行，则splwow64.exe在客户端PC1上运行。由此，作业ID和附信数据如第一实施例中那样存储在服务器PC110的64位语言监视器32中。

如上所述，在根据本实施例的打印系统400中，可以发送附信而不受后台打印格式、安装方法和OS之间的差异影响。

此外，本发明不局限于这些实施例，可以进行各种变形和修改而不偏离本发明的范围。

本申请是基于2012年3月19日向日本专利局申请的日本优先权申请号No.2012-062742，其全部内容并入于此作为参考。

Claims

1.一种信息处理方法，用于使计算机执行控制由应用生成的文档数据的打印作业，该方法包括：

控制步骤，通过向打印作业分配ID来控制由应用生成的文档数据的打印作业的执行，

设置接收步骤，显示用于从用户接收打印作业的设置条件的屏幕，

图像处理步骤，从应用接收基于由设置接收步骤接收的设置条件而要被转换成打印数据的文档数据，和

打印数据处理步骤，存储与图像数据相关联的打印作业的ID，

其中，设置接收步骤包括图像数据生成步骤，以在设置条件中指定了用于生成图像数据的命令时生成图像数据；

其中设置接收步骤将分配给打印作业的ID与在图像数据生成步骤生成的图像数据相关联，以将与该ID相关联的图像数据存储在打印数据处理步骤中，并且

其中图像处理步骤从应用获取文档数据，从控制步骤获取该ID以及从打印数据处理步骤获取与该ID相关联的图像数据，以根据设置条件将图像数据和文档数据转换为打印数据。

2.根据权利要求1所述的信息处理方法，还包括以下步骤：

其中，设置接收步骤在从用户接收设置条件之后且在生成图像数据之前，将设置条件发送给图像处理步骤；

其中，图像数据生成步骤请求控制步骤从图像处理步骤发送设置条件；

其中，图像处理步骤将设置条件发送给控制步骤，以及

其中，图像数据生成步骤从控制步骤获取设置条件。

3.根据权利要求1或2所述的信息处理方法，其中，

图像数据生成步骤是在由控制程序指示开始打印作业之后，图像处理程序将文档数据转换为打印数据之前生成图像数据。

4.根据权利要求1或2所述的信息处理方法，其中，

该ID表示由控制步骤控制的多个打印作业或传真发送作业中的唯一作业，该ID是当打印作业的指定步骤正被执行时生成的。

5.根据权利要求1或2所述的信息处理方法，其中，

控制步骤还包括指定的API函数，以将设置条件存储在具有该ID作为关键词的打印数据处理步骤中，并且

其中，设置接收步骤调用该指定的API函数来存储设置条件。

6.根据权利要求1或2所述的信息处理方法，其中，

控制步骤还包括指定的API函数，以读取存储在具有该ID作为关键词的打印数据处理步骤中的设置条件，并且

其中，图像处理步骤调用该指定的API函数来读取设置条件。

7.根据权利要求1或2所述的信息处理方法，其中，

图像数据生成步骤从包括关于传真的发送者和接收者的信息的设置条件生成附信的图像数据。

8.根据权利要求1或2所述的信息处理方法，还包括：

图像处理步骤将图像数据作为封面添加到从文档数据转换的打印数据上，或者将图像数据添加作为包括一页或多页的打印数据的一部分。

9.一种信息处理设备，包括：

控制部，通过向打印作业分配ID来控制由应用生成的文档数据的打印作业的执行，

设置接收部，显示用于从用户接收打印作业的设置条件的界面，

图像处理部，从应用接收基于由设置接收部接收的设置条件而要被转换成打印数据的文档数据，和

打印数据处理部，存储与图像数据相关联的打印作业的ID，

其中，设置接收部包括图像数据生成部，以在设置条件中指定了用于生成图像数据的命令时生成图像数据；

其中设置接收部将分配给打印作业的ID与在图像数据生成部生成的图像数据相关联，以将与该ID相关联的图像数据存储在打印数据处理部中，并且

其中图像处理部从应用获取文档数据，从控制部获取该ID以及从打印数据处理部获取与该ID相关联的图像数据，以根据设置条件将图像数据和文档数据转换为打印数据。

10.根据权利要求9所述的信息处理设备，

其中，设置接收部在从用户接收设置条件之后且在生成图像数据之前，将设置条件发送给图像处理部；

其中，图像数据生成部请求控制部从图像处理部发送设置条件；

其中，图像处理部将设置条件发送给控制部，以及

其中，图像数据生成部从控制部获取设置条件。

11.根据权利要求9或10所述的信息处理设备，其中，

图像数据生成部在由控制部指示开始打印作业之后，图像处理部将文档数据转换为打印数据之前生成图像数据。

12.根据权利要求9或10所述的信息处理设备，其中，

该ID表示由控制部控制的多个打印作业中的唯一作业，该ID是当打印作业的指定步骤正被执行时生成的。

13.根据权利要求9或10所述的信息处理设备，其中，

控制部还包括指定的API函数，以将设置条件存储在具有该ID作为关键词的打印数据处理部中，并且

其中，设置接收部调用该指定的API函数来存储设置条件。

14.根据权利要求9或10所述的信息处理设备，其中，

控制部还包括指定的API函数，以读取存储在具有该ID作为关键词的打印数据处理部中的设置条件，并且

其中，图像处理部调用该指定的API函数来读取设置条件。

15.根据权利要求9或10所述的信息处理设备，其中，

图像数据生成部从包括关于传真的发送者和接收者的信息的设置条件生成附信的图像数据。

16.根据权利要求9或10所述的信息处理设备，其中，

图像处理部将图像数据作为封面添加到从文档数据转换的打印数据上，或者将图像数据添加作为包括一页或多页的打印数据的一部分。