指令打印与驱动打印随笔

本文对指令打印和驱动打印做了一个简要的介绍，分享了在开发客户端打印组件时的一些过程并提出了一个新轮子用于解决老的问题并引出更多的新问题。全文大概 3500 字无图，阅读大概需要 7 分钟。

驱动打印是指：使用 PrintDocument 进行打印。通过注册其 PrintPage 方法拿到 Graphics 对象使用 GDI+ 画图打印。

指令打印是指：利用打印机厂商提供的指令协议控制打印机直接打印。

驱动打印和 Windows 平台关联紧密，所以不能做到跨平台。驱动打印大部分情况不能即插即用，在第一次将某打印机链接到电脑时，可能需要安装对应的驱动程序系统才能正确的识别到该打印机。

绝大部分小票打印机都支持 ESC 指令，除了 ESC 外常见的还有 TSC、TSPL，PPLA等这与打印机厂商和型号相关。指令打印可以跨平台，且在不同的平台要向硬件发出的指令是相同的，无论链接方式是 USB、串口还是蓝牙。

从开发的角度来说，如果我们想兼容市面上大多数打印机并且想支持跨平台，那么这就会是一件需要仔细斟酌和权衡的事情：

1、仅采用驱动打印。那么我们不得不放弃对跨平台的支持。如果遇到过老的设备，它很可能没有提供对最新的操作系统（比如 Windows 10）的支持，所以单纯的驱动打印是玩儿不赢的。

2、仅采用指令打印。我们可以做到跨平台，无惧系统升级，但仍有无解的情况：如果客户的打印机没有指令打印或者指令协议很小众没必要做支持怎么办？这是真实发生的事情，有客户需要用传统的办公用打印机打印小票，真·谜一般的操作。

3、驱动打印和指令打印并行。这当然会解决上述问题，但同时会引入新的问题：你不得不写出多套不同的代码去完成一件相同的事情，更可怕的是在修改一个问题时很可能会改了这一套忘了那一套。

在项目起初，因为对各种打印方案并不熟悉所以带你部分经过了上述三个阶段的演变。当支持的打印机和打印格式越来越多，维护这部分代码就成为一件苦力活儿，而且非常容易出错。接手这部分代码的人会被怀疑是否能力有问题，毕竟开始的时候时那么的简单。

大概 2019 年 7 月份时，项目组对驱动打印进行了封装，该封装参考了网上的开源组件，构建出了一个名为 TicketDocument 的类型，并添加了一些基础操作：

TicketDocument 可以序列化为 JSON 字符串用于在网络间传输。所以可以将 TicketDocument 的生成放置在服务端，这样对打印格式进行微调时不需要更新客户端。

项目中对 TicketDocument 的调用类似如下，其中 doc 变量即 TicketDocument 实例：

doc.AddText($"来源:{g.SName}");
doc.AddNewRow();
doc.AddText($"出厂时间：{g.CommandDate:yyyy/MM/dd}");
doc.AddNewRow();
doc.AddText($"产品:{g.Items.Count(i => i.FXashId == 0)}件", width: 0.4f);
doc.AddText($"附件:{g.Items.Count(i => i.FXashId != 0)}件", width: 0.3f, offset: 0.4f,
alignment: StringAlignment.Center);
doc.AddText($"共计:{g.Items.Count}件", width: 0.3f, offset: 0.7f, alignment: StringAlignment.Far);

当项目不得不支持指令打印时， TicketDocument 的抽象定义就不能满足需求了：因为指令打印并不能提供类似于 GDI+ 这种强大的控制力。

驱动打印和指令打印并行的事情必须上马。因为指令各不相同，所以就编写了不同的代码对应不同的打印机，业务应用调用打印宿主时也采用多种不同的协议格式，因项目不同没有使用 TicketDocument 。这对驱动打印部分造成了影响，满天飞的硬编码，写死的数组下标，接着在对打印格式进行调整时，驱动打印罢工了。

于是，我们需要一个新的轮子：