未发布 Xmanager Enterprise网络通讯工具更新合集 Xmanager Enterprise是完整的网络连接套件，它带有一个高性能PC X服务器，支持OpenGL(GLX)、3d硬件加速、安全终端模拟器、文件传输客户端和LPD打印机服务器。Xmanager Enterprise 4使3d X应用程序运行得更快，通过SSH和TELNET来提供安全的远程终端访问，通过SFTP/FTP进行方便的文件传输，使用LPD在本地打印远程文件等。
Xmanager Enterprise v5.1243更新：
- 修复：[Xmanager]全屏启动时屏幕闪烁
- 修复：[Xshell]自动更新会错误地显示用户正在使用最新版本
- 修复：[Xshell]终端复位时，光标不复位
- 修复：[Xshell]重命名选项卡有时将名称应用于其他选项卡
- 修复：[Xshell]反向视频终端转义序列被忽略
- 修复：[Xshell]当选择新窗口中打开时，将-newtab选项中的新选项卡名称应用于现有选项卡
- 修复：[Xftp]从连接的会话中打开新终端时，系统将提示用户输入密码
- 修复：[Xftp]从会话的上下文菜单中调用Xftp始终默认为TCP 22
- 修复：[Xlpd]资源清理
Xmanager是市场领先的PC X服务器，它能够带来Windows平台下强力的虚拟应用技术。使用Xmanager，能够使安装在远程的基于UNIX系统的X应用程序与一般的Windows应用程序 完全一样。它提供了一个强大的会话管理控制台、易于使用的X应用程序启动器、X服务器概要文件管理工具、SSH模块和用于安全访问的远程高性能PC X服务器及虚拟化的UNIX/Linux
环境。
Xmanager v5.1056更新：
Xshell是一个功能强大的终端模拟器，支持SSH、SFTP、TELNET、RLOGIN和SERIAL。它提供业界领先无法替代的性能和特性集。它有许多对企业用户有用的特性，包括：分页式环境、动态端口转发、自定义键映射、用户定义按钮、VB脚本以及显示2字节字符和支持国际语言的UNICODE终端。
Xshell v5.1333更新：
- 修复：[Xshell]自动更新会错误地显示用户正在使用最新版本
- 修复：[Xshell]终端复位时，光标不复位
- 修复：[Xshell]重命名选项卡有时将名称应用于其他选项卡
- 修复：[Xshell]反向视频终端转义序列被忽略
- 修复：[Xshell]当选择新窗口中打开时，将-newtab选项中的新选项卡名称应用于现有选项卡
Xftp是一个灵活和轻量级的SFTP / FTP客户端，它主要用于为用户提供通过网络安全的传输文件。它提供了许多强大的功能，比如直接编辑、多窗格、文件夹同步、支持FXP、服务器之 间传输以及集成第三方编辑器。在处理远程文件方面Xftp将为你节省时间和精力。 对于家庭和学校的用户来说，Xftp是免费的。具体情况可参阅家庭和学校用户免费使用许可协议条款和
Xftp v5.1229更新：
- 修复：[Xftp]从连接的会话中打开新终端时，系统将提示用户输入密码
- 修复：[Xftp]从会话的上下文菜单中调用Xftp始终默认为TCP 22
Xlpd是一个用于Windows系统的简单的行式打印机后台程序（LDP）和打印作业管理工具。它通过LPD协议从远程服务器接收打印任务并把该打印任务发送至本地打印机。LPD是一个支持多种操作系统的标准的打印协议，支持包括UNIX、Solaris和Linux等系统。
Xlpd v5.1231更新：
未发布 LEADTOOLS的新功能Document Composer可以让你在多个文件中创建文档 作为LEADTOOLS v19更新的一部分，新版本向Document Viewer添加了一个新的虚拟文档功能。 LEADTOOLS Document Composer界面可以轻松地从任意数量的页面以及来自多个源文档的文件中创建虚拟文档。你可以在查看该文档时进行修改，并可以使用代码添加或删除页面，也可以使用拖放来进行交互式操作。由Document Composer创建的虚拟文档可以保存在服务器上，与多个用户共享，并导出为任何格式。
从任何源文件中构建或撰写文档意味着什么？想象一下，房地产经纪人准备与客户会面，并想要准备几个房产相关的打印资料。他的计算机或云盘上收集了一些文件：PDF格式的列表、DOCX格式的列表、谷歌地图的截图，甚至是访问其他客户时的一些个人照片。房地产经纪人可以使用LEADTOOLS Document Composer从每个源文件中单击并拖动所需的页面并创建新的虚拟文档，然后将其打印出来参与会议，也可以将虚拟文档导出为新的PDF并通过电子邮件发送。
如果你想要尝试该功能，请查看Document Composer演示应用程序，或直接下载最新的LEADTOOLS安装程序！
未发布 Essential Studio for WPF更新至2017 v2，新增Adobe X安全性等功能丨附下载 Essential Studio for WPF是一个帮您轻松创建利于分析且高性能Windows应用程序的WPF界面控件。包含了如 grids、charts、gauges、menus、calendars、editors等等。同时，文件格式库还允许您导出资料到Excel、World和PDF文件中，以及对这些格式的文件进行处理。
Essential Studio for WPF是一个大型组件，2017 v2新版本增加了工作簿排序和过滤、动态图表端口、Adobe X安全性和其他新的功能。
日历编辑
特殊日期标记
日历编辑控件中可以标记特殊日期。
图表
区段颜色设置
图表中的每个段现已支持颜色贴图。
多个样条曲线类型
图表控件现在支持样条区域的多个样条类型。
图表
滚轮鼠标平移
通过将滚轮鼠标的中心滚动按钮移动到一侧，图表可以从左到右平移，反之亦然。
片段装饰
连接器中添加了一种新的装饰元素，以指示连接在另一个连接器或片段上的流动。
滚动性能
当在图表中滚动大量对象时，将显示对象的轮廓，直到每个对象加载完成，从而平滑滚动。
DocIO
增强Word转换PDF功能
DocIO现在支持Word到PDF转换期间的方程式字段。
编辑控件
支持Microsoft Visual Studio-like Go-To-Line
支持的内置会话窗口的Microsoft Visual Studio-like编辑器，用户可以选择浏览特定的行。
PDF
增强PDF安全功能
现在支持PDF 2.0安全功能（AES Revision 6）。
演示
注释功能
可以在PowerPoint演示文稿中创建和修改注释。
属性网格
处理属性网格中的自定义描述符对象。
电子表格
排序和筛选
可以使用排序和自动过滤器选项在Excel中有效地分析数据。
排序
根据单元格值按升序或降序对数据进行排序。
过滤
使用自动过滤器功能过滤数据。如Excel中，该功能具有多个选项来过滤多列数据，以及从特定列中清除过滤数据的功能。
树型网格
过滤
树状网格控件现在支持使用各种过滤器选项，用编程方的式过滤节点。
XlsIO
Excel到PDF转换中的图标设置
Essential XlsIO支持使用“仅显示图标”和“反向图标顺序”选项进行PDF转换的自定义图标设置。
增强图表转换图像功能
将图表转换为PDF文件或图像时，图表元素（如标题和显示单元）现在支持富文本和具有不同标记的图表系列。
数据透视表自定义排序
数据透视表列可以通过字符串数组或设置自定义位置进行排序。
表格过滤器
可以根据文本、数值和日期过滤Excel表格行。
未发布 百度正式开源其RPC框架brpc 9月14日，百度正式在GitHub上基于Apache 2.0协议开源了其RPC框架brpc。brpc是一个基于protobuf接口的RPC框架，在百度内部称为“baidu-rpc”，它囊括了百度内部所有RPC协议，并支持多种第三方协议，从目前的性能测试数据来看，brpc的性能领跑于其他同类RPC产品。
brpc开发于2014年，主要使用的语言是C++和Java，是百度内部使用最为广泛的RPC框架，它经受了高并发高负载的生产环境验证，并支撑了百度内部大约75万个同时在线的实例。据了解，百度内部曾有多款RPC框架，甚至在2014年时还开源过另外一款RPC框架sofa-pbrpc。那brpc是在什么样的背景下诞生的？它有什么样的优势？又为何要开源？就这些问题，InfoQ记者采访了brpc负责人戈君。
Q：谈谈brpc的一些基本情况？什么时候开始研发的？经过了怎么样的迭代和升级？目前在内部应用情况如何？
戈君：brpc于2014年创建，在百度内部称为“baidu-rpc”。到目前为止，brpc一共进行了3000次左右的改动，现在仍在持续优化中，百度内的wiki上可以查询到每次改动的描述。brpc的主要语言是C++和Java，对其他语言的支持主要是通过包装C++版本，比如brpc的Python版包含C++版的大部分功能。
brpc目前支撑百度内部大约75万个同时在线的实例（不含client），超过500种服务（去年的统计，现在已不统计这类数据）。Hadoop、Table、Mola（另一种广泛使用的存储）、高性能计算、模型训练、大量的在线检索服务都使用了brpc。brpc第一次统一了百度内分布式系统和业务线的通信框架。
Q：为什么百度当时要研发brpc？
戈君：我们在实践中意识到，RPC作为最基础的通信组件，当时的百度已经不领先了。我当时的经理刘炀曾是Google的工程师，非常重视基础架构的建设，也愿意在这个方向投入资源。
我们在内部会更加深入地讨论这些问题。“好用”有时看起来很主观，但其实还是有据可循的，它的关键点是能不能真正地提高用户的效率：开发、调试、维护都要考虑到，如果用户效率真的被提高了，用户会想着你的，靠吹嘘或政令推广的东西得不了人心。我们创建brpc的初衷是解决百度业务所面临的实际挑战，同时也希望成为百度同学最喜爱的工具，哪怕离开百度也会怀念brpc。我们希望在提供了一个好用框架的同时，也展现了一种工作方法：注释怎么写，日志怎么打，ChangeLog怎么写，版本怎么发布，文档怎么组织，甚至对未来不在百度的同学的工作也有帮助，所以从这点来说brpc从一开始就是拥抱开源的。事实上，我们在口碑上做得还不错，brpc的wiki可能是百度内被点赞最多的内容之一。
Q：与其他的一些开源的RPC框架相比，brpc的优势是什么？
戈君：brpc主打的是深度和易用性。一方面我们没有精力像gRPC那样摊大饼，什么都做。另一方面我们也注意到gRPC（包括更早的Thrift）的深度和易用性并不够。技术方面的东西就是这样，看示例程序，文档非常牛逼，但实战中可能就是另一回事了，为什么各个公司都要造自己的轮子，一个隐藏原因就是表面高大上的东西在一些细节上让你无法忍受。
RPC真正的痛点是什么？是可靠性、易用性和定位问题的便利性。服务中不要出现不可解释的长尾，程序的可变项要尽量少，各种诡异问题要有工具支持快速排查。而这些在目前开源的RPC框架中做的并不好，它们大多看着很牛，但就是无法在自己组织中推广开来。回到前面那三点，brpc是如何做的呢？
- 可靠性。这一方面是代码质量问题，通过为brpc团队设立很高的招聘门槛，以及在团队中深入的技术讨论，我们确保了稳固的代码基础。另一个问题是长尾问题，这是设计问题，brpc其实包含了很多模块，其中的bthread是一个M:N线程库，就是为了更好地提高并发避免阻塞。brpc中的读和写都是wait-free的，这是最高程度的并发。技术细节请点击链接查看。
- 易用性。有种设计是什么选择都做成选项丢给用户，号称功能都有，但一旦出问题，则是用户“配置错了”。而且这样用户还非常依赖开发团队，没有开发团队的支持基本用不了，开发团队有足够的理由扩充团队。这么做其实非常不负责任，用户面对海量的选项也很难受。brpc对于增加选项非常谨慎，框架能自己做判断的绝不扔给用户，所有用户选项都有最合理的默认值，不设也能用。我们认为这对用户体验来说非常重要。
- 定位问题的便利性。这点其它开源框架目前做的都不好，正常使用是可以的，但出问题就麻烦了。这个问题在百度内部其实也很严重，brpc之前用户排查问题都要拉RPC同学一起排查，RPC框架对用户是个黑盒，用户根本不知道里面发生了什么。按我们的经验，基本每天都有几个用户在群里问server卡顿，client超时之类的问题，排查问题是常态，人手必然不够。时间长了用户就觉得你这个框架各种问题，人还拽的不行很少回他们消息。brpc的解决办法是给server内加入各种HTTP接口的内置服务，通过这些服务，用户可以很快看到server的延时、错误、连接、跟踪某个RPC、CPU热点、内存分配、锁竞争等信息，用户还可以使用bvar来自定义各类统计信息，并在百度的运维平台NOAH上汇总。这样大部分问题用户可以自助解决。其实我们去看也是看这些，只是会更加专业。内置服务的具体说明可以看这里。
Q：作为公司内部的RPC框架，在服务治理方面有什么考虑？
戈君：百度内部RPC使用非常广泛，基本都是RPC调用，一些产品线还会通过local RPC隔离工程框架和策略代码。这么多年下来，服务周边的系统也比较全面了：编译是BCLOUD，发布是Agile，服务注册和发现是BNS，认证是Giano，监控和运维是NOAH。在百度内部，brpc和这些系统做了比较紧密的绑定，用户体验是一站式的。虽然在开源版本中，这些结合大都删掉了，但用户可以根据自己组织中的基础设施来进行定制：交互协议，名字服务，负载均衡算法都可以定制。对于其中一些特别通用的，我们希望用户反馈到开源版本中来以方便所有人。
Q：之前百度还开源过sofa-pbrpc，brpc与它的区别是什么？
戈君：sofa-pbrpc也是百度开发的一个比较早期的RPC框架，属于sofa编程框架的一部分，在搜索有应用。brpc相比sofa-pbrpc有如下优点:
- 对协议的抽象更一般化，并统一了全百度的通信架构。bprc能容纳非常多的协议，基于Protobuf的，基于HTTP的，百度内的nshead/mcpack，开源的Redis/Memcached，甚至RTMP/FLV/HLS直播协议，brpc能逐渐地嵌入现有系统，而不需要彻底重构，但sofa-pbrpc则不具备扩展协议的能力。类似的，sofa-pbrpc也无法定制负载均衡算法，brpc默认提供round-robin、随机、一致性哈希，Locality-aware（局部性感知）四种算法，用户还能定制。
- 多线程质量更好。多线程编程是非常困难的，看起来简单的RPC遍布多线程陷阱，比如处理超时的代码可能在RPC还没发出去时就运行了；发送函数还没结束，处理回复的回调就被运行了；一个回复还在被处理另一个回复回来了，诸如此类。另外，一个异步RPC的回调里发起一个同步RPC会发生什么，带着锁做同步RPC会发生什么。这些问题我们都不能在sofa-pbrpc中找到满意的答案。
- 完备的调试和运维支持。解决这个问题的本质还在可扩展性，你如何让用户参与进来定制他们感兴趣的指标，为此我们设计了bvar，让用户能用比原子变量代价还小的方式自由地定制各种指标，用户能在浏览器上看到指标的变化曲线，或在运维平台NOAH看到汇总的监控数据。brpc还加入了大量内置服务方便用户调试程序，查看连接，在线修改gflags，追踪RPC，分析CPU热点，内存分配，锁竞争等一应俱全。
无需讳言，brpc在诞生之初和sofa-pbrpc在百度内部是有竞争关系的，但就像其他地方一样，这种竞争带来了活力。类似的，brpc和其他已经开源的RPC框架也是良性的竞争关系，在比拼谁能真正提高用户效率的过程中共同进步。每个用户都可以去对比代码、文档质量，接口设计，易用程度，扩展能力等，投出自己的一票。
Q：谈谈brpc的整体架构？
戈君：技术栈无外乎是从传输层垒到应用层，就略过不讲了，具体可以去看下开源出来的文档。brpc在架构上强调“在不牺牲易用性的前提下增强可扩展性”，比如brpc支持非常多的协议，在百度内部一个brpc server同端口可以支持二十几种协议，这对于服务的平滑迁移就非常好用。
Client端的协议也非常多，用户用brpc和bthread用得很爽，所以希望我们最好能统一所有的客户端，像对Redis和Memcached的客户端支持也是在这个背景下做的，这两个客户端比官方Client好用多了，感兴趣的读者可以去尝试一下。但这么多协议的配置非常简单，填个字符串就行了，比如HTTP就是把ChannelOptions.protocol设为“http”，Redis就是“redis”。Server端甚至不用设，它会自动判断每个client的协议，怎么做到的开源文档里也有。
名字服务、负载均衡也都可以定制。但为了对用户负责，我们也不鼓励“太自由”的定制，比如一点点需求的变化就要搞个新的，这时更需要想清楚本质区别是什么。这个事情我们在百度内的支持群里每天都在做，我们是开放的”乙方”，但我们也是严厉的”乙方”。
Q：brpc的性能如何？这么高的性能是怎么做到的？
戈君：性能是我们非常看中的一点，它和用户体验也是紧密联系的。好用但性能不行，或不好用但性能很牛，用户会很难受，我们不希望用户纠结。从另一个角度来看，在推广初期，我们要说服产品线用brpc靠什么？最直观的就是性能提升。而且这儿的性能不能停留在benchmark的图片上，而是能在真实应用中体现出来。开放出来的案例文档中或多或少都包含了性能提升，具体如下：
- 百度地图API入口
- 联盟DSP
- ELF学习框架
- 云平台代理服务
Q：为什么要将brpc开源？接下来在开源项目的迭代方面有什么计划吗？
戈君：因为马上还有不少依赖RPC的百度系统要开源啊。RPC作为最基础的组件，开源不仅仅是为了自身，也是为其它开源项目铺路，比如说我们马上还会开源基于brpc的RAFT库，搭建高可用分布式系统非常方便；以及使用brpc的bigflow，让流式计算变得很顺手。这些年百度对开源的认识也在不断加深，开源看似曝光了百度的核心技术，但带来的生态影响力更重要。从Apollo、PaddlePaddle开始，百度真的开始拥抱开源了。brpc的开源版和内部版很接近，只是去掉了对百度内部独有的一些基础设施的支持，我们在内网写的深入分析RPC技术细节的文档也都一并开源了，后续也会及时推送改动，请大家放心。这是一个活项目，不会拉个开源分支就不管了。
查看更多资讯>>>
未发布 扫描识别工具Dynamic Web TWAIN使用教程：如何使用图像编辑器 Dynamic Web TWAIN是一个专为Web应用程序设计的TWAIN扫描识别控件。你只需在TWAIN接口写几行代码，就可以用兼容TWAIN的扫描仪扫描文档或从数码相机/采集卡中获取图像。
本文为你介绍Dynamic Web TWAIN中如何使用图像编辑器，欢迎收藏。
什么是图像编辑器
图像编辑器是Dynamic Web TWAIN的内置功能。您可以使用图像编辑器来管理图像。
你可以用图像编辑器做什么？
在图像查看器中，您可以：
- 浏览当前扫描或加载的所有图像
- 以下列方式编辑图像：旋转、镜像、裁剪、更改大小等
- 打印图像等
打开图像编辑器
当缓冲区中至少有一个图像时，可以使用方法ShowImageEditor()来显示编辑器窗口：
DWObject.ShowImageEditor();
未发布 GLG工具包Visualization and HMI Toolkit更新至v3.6，支持Java Script Visualization and HMI Toolkit的为开发高级图形的动态界面而设计的艺术化的框架：它不仅仅是简单的按键与菜单，它是全动态的能显示动态数据以及能反映用户互动的图片对象。它不仅仅是能制作“漂亮图片”绘制工具（它还具有很多其他功能），而是能使开发人员定义图片对象以及与程序中的对象互动的图形引擎。它的使用对象主要针对应用程序开发人员，能将乏味的低级别图片代码编译工作转化成高级的互动设计行为。
GLG工具包Visualization and HMI Toolkit更新至v3.6，点击下载>>>
支持Java Script：
对Java Script的增加的支持使得用户可以定义自定义函数，将多个输入值转换为驱动动画的输出值。通过可以添加到对象属性的新Java Script转换来使用Java Script。例如，一个新的“LED Value Display”部件可以通过使用Java Script转换来实现部件的逻辑。
转换的Java Script属性包含用于生成输出值的Java Script代码。转换的Arg List属性通过$ N符号提供脚本中使用的可变的参数，其中N是基于1的参数索引（即 $ 1是第一个参数）。参数可以是双（D）、字符串（S）或XYZ（G）类型。Java Script转换的输出值也可以是D、S或G类型，与其所附属性的类型相匹配。
例如，可以使用以下Java Script将D属性的值设置成以度为单位的第一个参数的sin函数：Math.sin （$ 1 / 180. * Math.PI）
下面的Java Script可用于根据第一个参数的值和由第二个、第三个参数定义的阈值来在“NORMAL” 和“ALARM”之间切换的文本字符串：$ 1 <$ 2 || $ 1> $ 3？“ALARM”：“NORMAL”
对于复杂的Java Script来说，可以通过Java Script文件提供Java Script函数和方法库。加载此文件时，可以在图形中使用该文件中定义的Java Script函数。
应用程序可以使用包含Java Script方法集合的全局Java脚本文件并在应用程序的图纸中使用。该文件将被预加载并用作Java Script库。Viewport的JavaScriptFile属性也可定义为该viewport预加载的Java Script文件。所有加载的Java脚本都是全局的，可以在应用程序的任何位置访问。从Java Script文件加载的函数将覆盖任何以前具有相同名称的Java Script函数。
GLGeditors和所有GLG API都支持Java Script：C / C ++、Java、C＃和Windows上的ActiveX。C / C ++和ActiveX中的Java Script支持由Duktape JavaScript Engine提供，对于C＃来说可以使用Jurassic JavaScript引擎（由Jurassic.dll提供）。在Java中可以使用Java的JavaScript引擎。
所有Java Scripts都在绘图设置时先行编译，以实现更快的运行。这些脚本也可以进行缓存。
GlgJavaScriptFile全局配置资源或GLG_JAVA_SCRIPT_FILE环境变量可用于指定全局Java Script文件。 对于GLG Builder和GLG HMI配置器，还可以通过-glg-java-script-file命令行选项或GLG配置文件中的GlgJavaScriptFile资源（即glg_config或glg_hmi_config）提供全局Java Script文件。
【本文作者慧都Elyn，转载注明出处】
未发布 Google开源了Abseil，为C++和Python开发提供支持 Google公开了其项目内部使用的一系列C++库，随后还会公开其Python库。
Abseil已在Google历经十多年的开发，它的目的是为Google编程人员在各种项目上的工作需求提供支持，这些项目包括Protocol Buffers、gRPC和TensorFlow等。Google评价Abseil为：
- 它是从Google内部代码块中抽取出来的一系列最基础的软件库。作为基本的组成部分，这些软件库支撑了几乎全部Google在运行的项目。以前这些API是零零散散地嵌入在Google的大部分开源项目中，现在我们将它们规整在一起，形成这样一个全面的项目。
- Abseil是Google代码库的最基本构建模块，其代码经过了生产环节测试，此后还会继续得到完全的维护。
最初，Abseil提供的抽象并非C++ 14或C++ 17的组成部分，但最终它们已被添加到C++标准中。例如，Google提供一个称为StringPiece的类型，随后C++ 17也添加了一个称为std::string_view的相近类型。为了与新的C++ 17类型具有一致的API，Google将StringPiece重构为absl::string_view。从底层机制上看，如果开发人员正在使用的是C++ 17，那么Abseil的string_view默认为标准实现；如果开发人员正在使用的是C++ 17以前的版本，那么string_view默认为Google的实现。
使用Abseil的优点在于可以访问一些目前依然尚未添加到标准中的C++特性，并且一旦这些特性被添加到C++标准中，Google保证会重构这些特性为默认使用标准实现。Google鼓励开发人员使用Abseil，并提及已有超过两亿五千万行的C++代码使用它，并且几乎所有从头开始构建的项目都使用了它。这意味着，Abseil已被Google广为使用，并出于与项目需求同步的考虑而得以频繁维护。
Abseil中包括如下的库：
- base：初始化，以及其它的基础代码。
- algorithm：对C++的库的补充，并为原算法提供了基于容器的版本。
- container：提供了更多的STL类型容器。
- debugging：用于检查泄漏的调试库。
- memory：包括兼容C++ 11版本的std::make_unique()和内存管理。
- meta：包括兼容C++ 11版本的类型检查，在C++ 14和C++ 17版本的C++ 库中可用。
- numeric：兼容C++ 11的128位整数。
- strings：各种字符串工具。
- synchronization：并发原语和同步抽象。
- time：抽象了绝对时间点操作和时区操作。
- types：非容器工具的类型。
沪公网安备31011202009668号 | 沪ICP备13020027号-2 