【套打】批次打印页数与上限截断页数

测试环境：PT145060 2019/12/31

前置知识：

<1>MaxNotePrintPage，套打最大页数，在common.config中配置，默认值为500。

<2>GetReport，套打操作的一次前后端数据传输。

<3>单个打印任务子项，通过套打模板中的公式（第X/Y页可以验证，带等号）。

在不设置任何其他条件的情况下，单个打印任务子项拥有其独立的页数范围

普通连续套打中，每个单据单独作为一个打印任务子项；合并套打，所有单据共享作为一个打印任务子项；节纸打印，所有单据作为一个打印任务子项。

简单验证如下，从数据源拖入页码公式到文本控件进行验证，放入数据表格，数据行放入单据头字段，设置报表型每页固定行数为1（在以下没有声明其他套打模板的前提下，均使用该套打模板，）。

这里我们针对节纸打印分离两个页数概念，

逻辑页数：套打计算得出的页数；物理页数：真实的打印纸张页数（输出页页数），物理页数小于等于逻辑页数。

结论（不想看分析过程的可以直接看结论）：

<1>在套打打印的打印交互界面中，只有当物理页数能够在一个批次直接发送下才能够进行打印页面选择范围（不进行服务端分批发送）。

<2>MaxNotePrintPage在套打中既作为单个打印任务子项中的最大逻辑页数，也作为默认前端与服务端批次物理页数数量，默认为500。

<3>单个打印任务子项具有独立的上限截断逻辑页数判断。普通连续套打每个单据独立判断；合并套打和连续节纸打印整体判断。

推论，普通连续套打上限页数最大为上限截断逻辑页数*单据数量；

合并套打上限页数最大为上限截断逻辑页数（所有在你使用合并套打时，打出了上限截断页数，那么就需要确认数据是否完整）；

连续节纸打印上限页数最大为上限截断逻辑页数（与合并套打同理，当节纸每页仅能放一个小块时最大，但通常小于上限截断页数）。

场景一（批次打印页数）：验证打印交互页面，通过普通连续套打验证即可。

普通连续套打，MaxNotePrintPage没有修改，默认值为500，没有设置批次打印页数。

<1>物理页数小于等于500页，在预览过程中，进行了一次数据传输，一次数据传输即可完成；打印交互界面能够干预页码范围。

<2>物理页数大于500页，在预览过程中，进行了两次数据传输。第一次前端请求套打页面，从0开始取全部页（-1），服务端返回500页数据，告诉其批次大小limit以及总页数count；前端收到后根据总页数判断是否所有数据获取完毕，根据批次获取下一个数据范围的确定，示例中为（500,500，从第500页开始再取500页）。针对其打印交互界面，其打印页面选择范围不可干预。

通过以上两例可以得知大于500页则无法修改打印页码范围；大胆假设，在套打打印时，以同样的数据进行套打预览，当只需要一次数据传输GetReport，就可以修改打印页码范围，当需要多次数据传输，就代表需要分批取数，不可以修改打印页码范围，接下来验证下是否与传输批次有关，我们在套打设置调整对应的批次打印数量。

<3>物理页数大于批次打印页数，需要进行多次数据传输。设置批次打印页数为2，物理页数为6测试；6页数据进行了3次数据传输，对应的第二次传输请求为(2,2，从第2页开始取2页)；对应的打印交互界面页码范围不可修改。

<4>物理页数小于批次打印页数（这里两者均大于500与<2>对照），值批次打印页数为600，物理页数为507页进行测试；预览一次数据传输即可完成，对应的打印交互打印页码可以修改。

这里得出结论，在套打打印的打印交互界面中，只有当物理页数能够在一个批次直接发送下才能够进行打印页面选择范围（不进行服务端分批发送）。同时一定要注意的是，不要过度的追求一次数据传输完成，非常考验网络带宽和性能，将成百页内容一次发送给前端；在某些客户场景中，我们同样的会通过设置批次打印页数变小（看页面大小和内容大小）使得打印交互更加友好（通常情况为将500页内容一次发送直接卡死）。同样的也不建议批次打印页数设置过小导致的请求数太过频繁。MaxNotePrintPage作为前端与服务端默认批次打印页数数量（物理页数）。

问题：为什么有时候可以打超过500页，有时候不可以？

场景二（上限截断页数）：针对场景一的部分过程，我们能够打出超过500页内容（场景一的<1>和<4>），但是更通常普遍的，我们打出500页内容但是数据没有打印完全，这里我们分析500页是怎么来的。

首先，MaxNotePrintPage同样为默认值500。

<1>合并套打500页。在连续套打507页的数据下，以相同的模板进行合并套打，理论上同为507页，但实际结果为500页。仔细对照发现数据丢失。

<2>节纸套打逻辑页数500页。同理于合并套打，逻辑页数理论上为507页，但实际结果为500页。

参照前置知识中的打印任务子项的逻辑，是否有可能跟有关呢。因此测试下单个单据，500条分录以上，每页打印一个分录的套打测试。

使用新的套打模板，单个单据套打模板测试，与上个套打模板几乎一样，仅将数据表格数据源调整为单据体，打印单据体数据，每页放一个分录。

<3>单个单据，500条分录以上，每页打印一个分录的套打测试。理论上逻辑页数等同于分录数，但实际上当大于500页时，只能打到500页。

按照前置知识和上面三个示例，能够得到这个结论：单个打印任务子项具有独立的上限截断逻辑页数判断。普通连续套打每个单据独立判断；合并套打和连续节纸打印整体判断。

继续思考，截断位置都为逻辑页码为500页，而且这个500又与MaxNotePrintPage相等，是否有关系呢，以下通过调节参数再次比对。

<4>将MaxNotePrintPage减少，如本例中为100，重复<1><2><3>三次，三者逻辑页码都为100。

<5>将MaxNotePrintPage增大，如本例中为600，重复<1><2><3>三次，三者都能够打印完整（没有截断）。

根据以上得出结论：MaxNotePrintPage作为单个打印任务子项中的最大逻辑页数，如果需要打印更多内容需要调整这个参数。更重要的是，我们应该要根据我们打印的逻辑页数判断内容是否打印完整，或者为套打模板在设置上的逻辑存在冲突导致的到达上限截断页数。

以上就是文章的所有内容，当然这两个知识点结合起来会具有很多变化。

就好比如为什么针对同样一批数据，我在套打打印交互界面有时候可以修改页码范围，有时候不可以。

当套打打印交互界面的页码范围可修改时，就代表一个批次打印完成，当不可修改时，就代表进行分批处理；检查批次打印页数是否有设置，然后就可以断定两者一定为不同的套打操作，合并套打和普通连续套打两类型，一种是整体套打，一种是逐个单据套打然后页拼接；再仔细思考，极大可能是因为合并套打到达了上限截断页数，在不设置批次页数的前提下，上限截断页数==批次打印页数，因此合并套打可以在一次数据传输下完成发送，而连续套打不可以，连续套打这时候的物理页数必然超过了上限截断页数，但实际上没有被截断，同样的由于超过了批次打印页数，因而进行了分批打印的操作，这时候连续套打不可修改打印页码范围。因此在这里，很有可能你的合并套打数据打印不全了。