您的位置:首页 > 其它

关于Web打印的一些总结

2010-07-09 01:07 176 查看
最近做了一个项目,有一块比较麻烦的功能就是打印,项目的设计是使用asp.net的网站,前期对web打印进行了一些初步的分析,觉得可能问题不大,于是便开始开发了,

项目的其他部分没有什么新意,为了让团队积累更多东西,觉得试用NHibernate(EntityFramework不支持Oracle),简单的学习和使用,借助NConstrct便方便的得到了数据访问和数据实体.

随着业务的慢慢实现,发现打印的问题凸显出来了,对应的每种打印模板的特殊要求(注:打印模板为Word),且每种格式均不同,寻求了几个参考解决方案:

1.使用IE浏览器的打印功能,打印当前页面,因为打印模板的问题,无法使用mhtml或者html作为模板,最终采用PNG图片显示打印模板,不过因为浏览器的打印页眉,页角,边距需要设置,否则打印的页面会存在显示问题.

2.使用IE浏览器调用Word处理软件远程打开Word文档,通过VBS控制Word软件打印.该方案能较好的显示打印的效果,页面也方便设置,本准备作为最优方案,但客户提出希望不能修改打印的结果,(Word可以修改)

3.使用收费打印ActiveX控件(ScriptX,japtools等).设计到收费,放弃考虑使用,同时也考虑到模板是Word,不方便转换

4.使用报表工具的插件(水晶报表,微软报表的IE显示插件),时间关系,没空研究,如果理解没错,对应的每个模板都需要进行开发一套对应的报表模板

5.导出成PDF文档然后打印.已实现了PDF文档的导出,但因为PDF客户端软件客户不一定安装,没考虑调用组件打开并且打印.

6.通过Flash插件的打印功能,来实现打印控制,问题是把模板转换成Flash比较麻烦,思路来源于百度文库和豆丁网的Flash文档阅读器

最终,我们实现了1,2,5的方案,现在运行的方案是1和5,总结一下Web打印,发现最大的问题是模板和打印容器,今天总结分析的时候,又参考了几个技术:

SmartClient技术, .NET 版本的ActiveX控件,两者都需要有安装.net Framework.不便于在客户端大规模部署,同时自己开发的ActiveX控件需要有签名才可以运行,比较麻烦.

于是又联想到现在有一种技术可以让程序脱离.netFramework运行,或者是所谓的虚拟化技术,需要进一步研究
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: