未发布 .Net文档图像处理工具包GdPicture.NET发布v14.0.30，改进PDF/OCR生成速度 GdPicture.NET是一款功能全面且可无限分发的文档图像处理工具包，开发者可将其作为.NET组件运用在他们的C#, VB.NET和CodeGear应用程序中，从而实现文档生成，显示，获取，编辑和打印等功能。在您的程序中使用GdPicture.NET，可实现文档显示，获取TWAIN扫描图像，进行图像处理，执行光学字符识别操作，其涵盖了所有主流领域的其他文件成像技术。
GdPicture.NET v14.0.30更新内容
改进了检测空白页的准确性。
改进了页面方向检测精度。
改进了autodeskew引擎的准确性。
改进了PDF/OCR生成的准确性和速度。
小的错误修复。
未发布 全面的.NET图像处理包DotImage v10.7.0.7发布丨附下载 DotImage
Atalasoft DotImage 是一款功能完善的图像处理包，它主要针对.NET的开发。它为基于.Net框架开发的Windows应用程序以及基于IE的Asp.Net程序提供高级的图像处理功能。DotImage 提供了很多Microsoft .NET Framework一样的设计模式，并向开发者提供功能丰富，高性能，授权方式灵活的对象模式。
DotImage v10.7.0.7更新内容
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异常。修复后提示成功，但所有内容也会丢失。
未发布 Oracle正式发布Java 9，引入新的Java编程组件 Java SE 9.0于2017年9月21日发布。
JDK 9的核心变化就是引入了一种新的Java编程组件，也就是模块，按照Oracle的说法，它是一个可命名的、自描述的代码和数据集合。模块技术的核心目标是减少Java应用和Java核心运行时环境的大小与复杂性。为此，JDK本身进行了模块化，Oracle希望通过这种方式提升性能、安全性和可维护性。为了支持Java 9的模块，引入一种新的模块化JAR文件形式，按照这种形式会在其根目录中包含一个module-info.class文件。Oracle同时提供了工具，允许我们组合和优化一组模块，形成自定义的运行时镜像（image），这样的镜像不必将整个Java运行时包含进来。模块化所带来的其他变化包括从Java运行时镜像中移除了rt.jar和tools.jar。 Java社区进程（JCP）执行委员会的成员Ben Evans认为最急需重构的应用恰好就是最适合进行模块化的应用。如果你已经备受Lava Flow/God Class/Stovepipe System地狱的折磨，而且你的利益相关方明确知道这一点，那么你可能更容易说服他们进行一次完整的底层重构，通过渐进式的努力形成一个完成的模块解决方案（而不是简单重构并迁移至Java 8）是值得去做的。
Oracle宣布Java 8会是一个长期支持的发布版本，会一直支持到2022年，因此Evans认为很多的应用将会停留在Java 8上，根本不会升级到Java 9。Evans补充说，有些应用可能会让开发和构建工具链使用Java 8版本，而在生产环境使用Java 9的运行时。
对特定类型的应用来说，这是很有帮助的。例如，我曾经见到有的电子商务网站具有非常大的堆空间，其中包含了大约40G的字符串数据。Java 9的ompact Strings技术能够将这种类型的内存使用减半。这反过来又会对GC的性能带来积极的影响。对于有些应用来说（这可能就包括大型的Solr安装环境及类似场景），单单这一项收益就值得将运行时升级到Java 9。
Java 9使用G1作为默认的垃圾收集器，替代了之前默认使用的Parallel GC。Evans对这项变化的评论：
这项变更是很重要的，因为相对于Parallel来说，G1会在应用线程上做更多的事情，而Parallel几乎没有在应用线程上做任何事情，它基本上完全依赖GC线程完成所有的内存管理。这意味着切换到G1将会为应用线程带来额外的工作，从而直接影响到应用的性能。
在很多（甚至可以说大多数）场景中，这种额外的性能损耗都不是什么问题。但是，在这方面，我确实也曾经见过从Parallel切换到G1时，有一定比例的工作负载会引起性能的下降。对于这些应用来说，这种性能下降是无法接受的，所以他们无法切换至G1收集器。随着G1成为默认的收集器，这将会影响到升级至Java 9的每个应用。
JClarity的CEO Martijn Verburg认为大型的代码库需要重构为模块的形式。Verburg给出了一些通用的模块化建议，并且指出了开发人员在采用Java 9模块系统时，需要注意的一些事情：
- 阅读Paul和Sander的图书“Java 9 modularity”：它是本权威指南，提到了所有需要注意的地方，阐述了模块、包以及JAR之间如何运行的关联关系；
- 在模块边界的地方，使用定义良好的接口并且针对这些接口编程；
- 不要拆分包（split package），也就是说一个包不要分散到两个模块中。Adopt OpenJDK有个探测工具，我们可以用它来探测已有的代码；
- 确保不要存在循环依赖（Jigsaw不允许这样）；
- 模块在源码的布局上与我们已习惯的方式有所不同，需要确保构建工具能够进行对应的处理；
- Jigsaw不支持多版本。
按照Verburg的说法，核心要点在于处理循环依赖、拆分包的问题，并确保针对接口进行编码。在尝试使用Jigsaw模块化重构之前，针对已有的代码库，这些工作需要预先完成。他还澄清了一个误解，那就是只有模块化的应用才能在Java 9上运行。
由于误解，在这方面有一种FUD（恐惧、不确定和怀疑）情绪，有人误认为在Java 9上运行的必须是模块化的应用。事实并非如此，我们可以将已有的基于类路径的应用直接在Java 9上运行。这里会有一些新的安全限制，因此我们需要设置一些特定的运行时标记（除非你重构代码，使用更安全的方式来访问Java的内部资源），即便如此，默认的行为也只是警告，而不是完全阻止我们（Java 10的限制会更严格）。
Verburg认为Jigsaw会是一个基石，会让Java的演进更快，这要归功于Mark Reinhold、Alan Bateman、Mandy Chung以及Jigsaw团队的其他成员多年来不知疲倦的工作，正是他们的努力使这一切得以实现。
Java 9还引入了jshell工具。这个命令行环境为Java平台带来了读入-求值-打印-循环（Read-Eval-Print-Loop，REPL）功能。它的目的在于以即时结果和反馈的形式，简化原型的实现并帮助我们探索语言在编码时的可选项。
Verburg和Evans看到Java 9中包含了jShell都非常兴奋，但令他们失望的是，HTTP/2只是作为Java 9的一个孵化模块（incubator module）提供的。鉴于社区对这项特性的兴趣和提供的帮助，Evans认为Oracle应该投入足够的工程资源，将HTTP/2交付为GA版本。
JDK 9完整的变更列表可以在Oracle的站点上查阅。Oracle宣布会按照每六个月一次的节奏进行发布，意味着Java 9是最后一次“keystone”特性驱动的版本发布，这反映出了Oracle目前管理Java的特点。Java下一阶段的演化将会按照更短的发布周期并且会按照更加面向特性的方式来发布。Java是否依然能够在服务端技术中占据领导者地位尚有待观察。
更多资讯点击查看>>>
沪公网安备31011202009668号 | 沪ICP备13020027号-2 