试用、下载、了解更多产品信息请点击"咨询在线客服"   

v10.7.0.7中的修复的问题

• [TiffDecoder]Customer图片会导致TiffDecoder出现SEHException异常。
• [AdvancedDocClean] LineRemovalCommand在某些图像上会引起不可修复的System.AccessViolationException，从而破坏主机进程。
• [AbbyyEngine] OcrTableRegion.Cells没有被填充。
• WebDocumentViewer getDocumentInfo对removePage的调用不成功。

上一个版本中修复的问题

• 在特定的PDF中使用修复功能会导致新版本出现异常。
• [MVC] NuGet库中缺少Atalasoft.dotImage.WebControls.MVC（包括x86和x64）。
• [WDV] Async方法可能会在浏览器页面刷新期间/之后引起控制台发生错误。
• 使用PdfDocument.Save格式保存时，Multipage PDF页面会引用前几页的资源。
• 保存PDF时，无效的PDF属性值会引起异常。
• [PdfAnnotationDataExporter]使用OverwriteExistingAnnotations = true保存到特定图层时，会覆盖掉上一层。
• PDF417条形码不可读取。
• Customer DWG文件在DwgDecoder中呈现时丢失图像。
• WebDocumentViewer会调用触发了ThreadAbortException的Response.End。
• PdfDocument.Repair对于某些格式不正确的链接可能会删除而不是修复。
• [PdfTextDocument]文本提取结果在某些文档上使用时会丢失内容。
• 当SelectionMode = ThumbnailSelectionMode.MultiSelect时WinForms ThumbnailView / FolderThumbnailView SelectionIndexChanged会触发两次。
• RawDecoder注册时，Customer file会引起System.AccessViolation异常。
• [PdfGeneratedDocument] PdfTextLine会忽略通过构造函数传递的FillColor和OutlineColor值。
• [PdfDocument]一些PDF文件在PdfDocument中打开时会发生StackOverflow问题。
• [PdfDocument]使用PdfDocument / PdfAnnotationDataImporter打开一些PDF时会出现Overflow问题。
• WebDocumentThumbnailer：当tabular：true set时，滚动条未正确更新。
• 客户在Logger中报告的竞争条件/非线程安全行为。
• “不支持Colourspace转换”的Customer tiffs无法打开。
• 755266：WDV - 打开non-relative web根路径将导致WDV保存失败。
• [PdfDocument]如果我们多次将新页面添加到文档时，Adobe Acrobat将无法读取pdf文件。
• 只有页面可见时，WebDocumentViewer Rotate方法才会更新。
• [OfficeDecoder]无论解码器分辨率如何设置，Office文件始终呈现默认的DPI（大多数系统上为96）。
• [PdfEncoder]使用PdfCompressionMode.Segmented保存大文件（大量页面）会发生内存的问题。
• [BarCodeReader] DataMatrix条形码读取速度非常慢
• PdfCompressionMode.Segmented强制将灰度图像变为黑白，且这种行为没有记录。
• PdfDocument打开/保存时Customer PDF被损坏。
• [OfficeDecoder]部分office文件的表格标题中缺少内容。
• 带有AnnotationStreamWritten事件的WDV 10.7中的行为发生变化。
• 载入注释中的WDV regression。
• [DotTwain] HP scanners DeviceEvent 会使device.State进入无效状态。
• Barcoding.Reading.BarcodeReader没有读取到相应的客户代码。
• 10.7 WDV更改会破坏WingScan-only的许可。
• [PdfAnnotationDataExporter] EmbeddedImageAnnotation会增加目标PDF文件大小。
• [BarCodeReader] - 在其他引擎中读取的PDF-417条形码的Customer images在BarCodeReader中无法读取。
• [BarCodeReader]当前的BarCodeReader引擎无法读取旧的9.x（Inlite）引擎读取的条形码的全部内容。
• [PdfDocument]Customer PDF会引起关于MLPdfLabColorSpace的PdfException异常。修复后提示成功，但所有内容也会丢失。

using Leadtools;
using Leadtools.Dicom;
using Leadtools.Dicom.Scu.Common;
using Leadtools.Dicom.Scu;
using Leadtools.MedicalViewer;
using System.Net;
using System.IO;

// CStore highlevel 客户端和服务端对象
        private StoreScu _cstore;
        private DicomScp _server = new DicomScp();

private void initServer() {
            _server = new DicomScp();
            _server.AETitle = "L19_PACS_SCP64";
            _server.PeerAddress = IPAddress.Parse("10.32.1.75");
            _server.Port = 534;
            _server.Timeout = 30;
        }

private void initCstore() {
            _cstore = new StoreScu();
            _cstore.AETitle = "L19_CLIENT64";
            _cstore.HostPort = 1030;
            //存储成功后
            _cstore.AfterCStore += _cstore_AfterCStore;
        }

private void 存储ToolStripMenuItem_Click(object sender, EventArgs e)
        {
            string filename ="D:\\Xa.dcm";
            _cstore.Store(_server, filename);

        }

• 可靠性。这一方面是代码质量问题，通过为brpc团队设立很高的招聘门槛，以及在团队中深入的技术讨论，我们确保了稳固的代码基础。另一个问题是长尾问题，这是设计问题，brpc其实包含了很多模块，其中的bthread是一个M:N线程库，就是为了更好地提高并发避免阻塞。brpc中的读和写都是wait-free的，这是最高程度的并发。技术细节请点击链接查看。
• 易用性。有种设计是什么选择都做成选项丢给用户，号称功能都有，但一旦出问题，则是用户“配置错了”。而且这样用户还非常依赖开发团队，没有开发团队的支持基本用不了，开发团队有足够的理由扩充团队。这么做其实非常不负责任，用户面对海量的选项也很难受。brpc对于增加选项非常谨慎，框架能自己做判断的绝不扔给用户，所有用户选项都有最合理的默认值，不设也能用。我们认为这对用户体验来说非常重要。
• 定位问题的便利性。这点其它开源框架目前做的都不好，正常使用是可以的，但出问题就麻烦了。这个问题在百度内部其实也很严重，brpc之前用户排查问题都要拉RPC同学一起排查，RPC框架对用户是个黑盒，用户根本不知道里面发生了什么。按我们的经验，基本每天都有几个用户在群里问server卡顿，client超时之类的问题，排查问题是常态，人手必然不够。时间长了用户就觉得你这个框架各种问题，人还拽的不行很少回他们消息。brpc的解决办法是给server内加入各种HTTP接口的内置服务，通过这些服务，用户可以很快看到server的延时、错误、连接、跟踪某个RPC、CPU热点、内存分配、锁竞争等信息，用户还可以使用bvar来自定义各类统计信息，并在百度的运维平台NOAH上汇总。这样大部分问题用户可以自助解决。其实我们去看也是看这些，只是会更加专业。内置服务的具体说明可以看这里。

• 对协议的抽象更一般化，并统一了全百度的通信架构。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热点，内存分配，锁竞争等一应俱全。

• 百度地图API入口
• 联盟DSP
• ELF学习框架
• 云平台代理服务