做过bs开发的同志应该都深有体会，在web程序中打印不再象应用程序中那样便于控制了，web程序天生的一些特性造成了这个缺点，如：打印机在本地，而文件确可能在服务器上；格式如何控制和定制等等。都给我们开发中带来了很多问题，虽说有水晶报表等控件来解决但总归是不方便。当然有了问题就会有人来研究解决，这里我先对目前流行的几种方式做个简单介绍：
1、IE直接打印
这个不用多说，直接调用window.print或者webrower控件的ExecWB方法来打印。方便快捷，客户端无需任何设置即可。利用一些办法也可以实现简单的定制，比如做一个模板htm文件，然后在js中动态创建一个隐藏帧来，用脚本来生成其中的数据，再把最后的结果文件写入到隐藏帧打印处理。如果处理的好，实际上效果也是不错。对于简单的打印需求应该是够了。这里我举个实际中的例子来说明这种方式：
开发中经常需要打印一些统计的结果给用户，比如说一个常见的功能是营业报表类的打印：操作员先输入查询条件，然后提交得到查询的结果，点击打印后，按照定义好的格式打印报表。
我们实现上大部分情况会把查询的结果绑定到DataGrid上来，然后打印DataGrid。这种情况的打印一般来说格式比较固定简单，确定后基本不会再作更改。所以可以采用IE直接打印，但若直接调用window.print来打印页面，页面上别的元素也会被打印处理，页头页尾的格式也不好控制。
2、ActiveX控件
自己开发控件。这种方式很多商用软件采用这种方式，写成控件后已经无所谓是在web中使用还是应用程序中使用了。打印方式非常灵活，基本上程序能做到的web也能做得到。但客户端需要安装组件，部署不是很方便。
3、.NET组件
卢彦写过一篇很好的文章《利用XML实现通用WEB报表打印》，相信大家都看过了。思路新颖，实现简单，确实不失为一种通用WEB打印解决办法，尤其利用XML来描述打印文件的方法给以后的格式的拓展留下很好的接口，非常容易扩充。这种打印方式对于格式变化大，数据量小的应用来说非常合适。这种思路也给了ASP.NET上打印的一种新的思路：自定义一些组件来实现灵活的打印功能。当然缺点也是显而易见：1、需要客户端安装NET framework1.0组件。2、XML的解析上，如果文件较大速度上不是很理想。3、页面首次加载时会有明显的延时。
先列个条目，明天继续写
1、IE直接打印
这个不用多说，直接调用window.print或者webrower控件的ExecWB方法来打印。方便快捷，客户端无需任何设置即可。利用一些办法也可以实现简单的定制，比如做一个模板htm文件，然后在js中动态创建一个隐藏帧来，用脚本来生成其中的数据，再把最后的结果文件写入到隐藏帧打印处理。如果处理的好，实际上效果也是不错。对于简单的打印需求应该是够了。这里我举个实际中的例子来说明这种方式：
开发中经常需要打印一些统计的结果给用户，比如说一个常见的功能是营业报表类的打印：操作员先输入查询条件，然后提交得到查询的结果，点击打印后，按照定义好的格式打印报表。
我们实现上大部分情况会把查询的结果绑定到DataGrid上来，然后打印DataGrid。这种情况的打印一般来说格式比较固定简单，确定后基本不会再作更改。所以可以采用IE直接打印，但若直接调用window.print来打印页面，页面上别的元素也会被打印处理，页头页尾的格式也不好控制。
2、ActiveX控件
自己开发控件。这种方式很多商用软件采用这种方式，写成控件后已经无所谓是在web中使用还是应用程序中使用了。打印方式非常灵活，基本上程序能做到的web也能做得到。但客户端需要安装组件，部署不是很方便。
3、.NET组件
卢彦写过一篇很好的文章《利用XML实现通用WEB报表打印》，相信大家都看过了。思路新颖，实现简单，确实不失为一种通用WEB打印解决办法，尤其利用XML来描述打印文件的方法给以后的格式的拓展留下很好的接口，非常容易扩充。这种打印方式对于格式变化大，数据量小的应用来说非常合适。这种思路也给了ASP.NET上打印的一种新的思路：自定义一些组件来实现灵活的打印功能。当然缺点也是显而易见：1、需要客户端安装NET framework1.0组件。2、XML的解析上，如果文件较大速度上不是很理想。3、页面首次加载时会有明显的延时。
先列个条目，明天继续写
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
