测试环境：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页内