web报表打印通常是系统的辅助部分，但是又必须解决，否则项目完成不了。下面来分析分析目前的几种常见的web报表打印方案。
一、 浏览器的菜单打印功能
这是最简单的，只需点击页面上的打印菜单，但是也是问题最多的，基本上是不能满足用户需要。比如：不能精确分页，有出现打出半行字的风险；改变纸型后打印出的格式和页面显示的格式相差太大；页眉页脚也需要从菜单中去设置，等等等等。这种方案最大的优势就是不需要做任何代码，点击打印就可以了。
二、 window.Print()
这实际上，是浏览器打印功能菜单的一种程序调用。与点击打印功能菜单一样，不能精确分页，不能设置纸型，套打的问题更加无从谈起，只不过，可以让用户不用去点菜单，直接点击网页中的一个按钮，或一个链接里面调用罢了。
需要指出的是这种方法提供一个打印前和打印后的事件onbeforeprint、onafterprint。可以在打印前的时候重新编辑一些格式，专门送去打印，打印后又处理回来。
function window.onbeforeprint()
{
//将一些不需要打印的隐藏
}
function window.onafterprint()
{
//放开隐藏的元素
}
事实上，很多用户都是采用这种方式打印，但是这种方式最致命的缺点是不能设置打印参数，比如纸型，页边距，选择打印机等等。
三、 导出excel导出pdf文件的打印
将需要打印的数据导出excel文件或者导出pdf文件，然后打开excel文件或者pdf文件重新打印，用这种方案能实现精确的打印，套打也能实现，但是需要客户端安装excel和adobe软件，操作起来也有些麻烦，并且导出的excel文件可以重新修改编辑，一般用户都会要求系统提供这种导出的方案，也同时需要直接打印的功能，所以个人觉得这种方案也不能很好的解决打印的问题。
四、 纯ActiveX控件
这种方案其实就是编写一个C/S的打印控件，然后嵌入到页面里面，将要打印的数据装入到控件中，然后打印。这种方案的优点是打印精度高，分页，设置打印参数等等都能实现。但是缺点也是很明显的，嵌入ActiveX控件破坏了web应用的整体html风格，且这样的控件通常都比较大，一般都超过1M，下载很慢。
五、 Applet方式
采用Applet方式，分页或精确打印，都可以做到完美，但缺点也很明显，表现在：
安装Applet成本巨大。需要下载十几M的文件。
Applet本身可能并不大，但运行Applet所需的jre一般至少10几M（jre1.4.2 ， 15.45M）。用户需要极大的耐心，来进行打印。
打印报表时，需要重新向服务器检索数据，效率低。
因为Applet方案，一般采用html方式呈现数据，打印时Applet必须向服务器检索同一张票据的数据，看上去，是打印了当前页的票据，实际上，Applet根本不会用当前html页的数据来打印，而是向服务器下载数据到Applet中来打印。也就是说，打印的话，必须两次请求，一次html呈现，一次用来打印。
市场上java类的报表工具，一般推荐Applet方式来实现打印。
六、 轻量级的ActiveX插件＋DHTML＋javascript＋后台代码（动态获取数据）
轻量级ActiveX插件：设置打印参数，比如预定义纸型，设置打印方向，打印边距，指定打印机，不弹出打印对话框直接打印等等。
DHTML＋javascript编辑打印数据的格式展现，实现格式的自定义。
后台代码，可以是java，dotnet等等的，实现动态获取打印数据。
这种方案是比较理想的，只需要客户端下载一个很小的打印插件，客户端无需安装任何C/S的格式设计器，就可以轻松实现打印格式的自定义，打印参数的自定义等等。
eprint自定义打印工具就是这样一种web打印工具。下面是运行这种方案实现格式自定义的一个示例：
下面是一个预览的界面。
格式设计页面如下：
代码调用如下图：红色圈中的为调用的javascript函数。
这种方案的优点是：
能设置打印的纸型，方向，边距，页眉页脚等等打印参数。
能实现精确打印，分页；
格式可以自定义；
成本低廉，ActiveX只有75k。
