图文报告模块之需求以及未来涉及到的问题
来源:互联网 发布:mac拼音切换快捷键 编辑:程序博客网 时间:2024/06/10 06:15
系统基础架构是CEF + C++,要求C++处理过的图像传给JS的报告,进行排版之后,在传回C++的客户端进行打印功能。
关于图像数据传递的解决方案有两个:1、将处理过的图像传给JS的服务器;2、借用JS,将直接传递图像的二进制数据保存到JS服务器。生成报告涉及到图像数据的一致性。医生在报告中使用的图像等数据,不论是那个等级的医生拿到的数据必须是一致的。
无论使用那个解决方案,JS排版后都需要将数据(包含医生的诊断与图像数据)发给本地客户端进行打印。这里会遇到打印图片时和排版的不同问题。已经出现了文字字体的表现不一致问题。
优点:将处理过的图片统一上传到服务器,理论上保证每个医生获取的图像数据是一致的。 缺点:1、医生需求不同,所需的图像不同。有的医生需要原图像,不需要修改过的图像。根本上数据就不一致。需确定这些图像是直接覆盖原图像,还是重新生成一组图像。
涉及到重新生成图像的格式以及保存也是一等大事。
1、自己将处理过的图像直接传给JS的服务器
后台C++将数据传到服务器,1】、可以给JS传递图像的路径。JS传回打印网页时,如果是传递路径,需要再次下载图像数据。然后就有涉及到排版问题。目前的打印是直接将获取到的html转换成pdf,之后打印。
2】、将数据传完服务器后,JS可以自己根据图像路径解析图像,然后将图像的二进制数据直接传递给后台打印。疑问1、不确定JS能否解析图像数据;2、解析的图像数据是否能完整传递;3、传递的速度是否让人接受;4、接收到的图像数据能否被正确转化成pdf;3、正确转化后,打印是否正确。
2、借用JS,将直接传递图像的二进制数据保存到JS服务器
直接传递图像的二进制数据,然后让JS将图像存储到服务器。这样就将后台图像数据保存的后台问题交给前台处理。JS是一个单线程的,很有可能会导致页面卡死,进而有可能导致整个程序崩溃。
综合考虑之后,确定将第一种方案较为适宜。
- 图文报告模块之需求以及未来涉及到的问题
- Good stuff, Bruce Eckel有关Java存在的问题以及未来方向的报告
- View的生命周期以及涉及到内存警告的问题
- discuz涉及到的问题
- 计算机技术当前的主流技术以及其社会需求报告
- 涉及到状态改变的模块需要集中
- androidUI设计中涉及到的dpi dp px等问题以及屏幕适配问题
- 涉及到url修改的问题
- C++的未来,以及未来的未来
- C++的未来,以及未来的未来
- STL之涉及到的算法
- 类和接口的继承问题以及一些涉及到的知识
- 语文游戏项目涉及到的几个需求的解决方法
- 说一下视频播放跟随屏幕旋转,以及activity涉及到的周期问题
- 字符反转以及涉及到的 StringBuilder
- ioc以及Aop涉及到的设计模式
- 图文验证码模块乱码问题的解决
- J2SE基础夯实系列之使用Arrays.sort()方法,以及涉及到的Comparable和Comparator
- 使用OpenResty控制CDN回源主机
- Android系统广播大全及开机自启动的Service
- 【设计模式】【六】代理模式
- Jersey 文件下载
- Appium通过xpath定位
- 图文报告模块之需求以及未来涉及到的问题
- Android apk信息获取管理和手机信息获取管理
- boost (C++库)
- mysql创建视图包含子查询的解决方法
- &和&&的区别
- Ubuntu中python多个版本之间切换
- 架构 白话软件设计中的六大原则
- QT学习笔记17Socket通信
- CSS创建导航条