PDF FLY™是一款专业图像转换工具，用于将PostScript®, EPS 和 PDF文件转化为矢量和光栅图像文件格式。通过它，您可以将图像、图标、窗体和报表等无图像损失得移动到您的视图、编制和发布的系统中。您可以转换多个文件及进行文件夹级别的文件转换，其操作就像进行单个文件转换一样简单。

【最新PDF FLY v10.0点击下载>>>】

格式

• 新的输入格式 - 现在可以转换EPS（.eps）和Adobe Illustrator（.ai）以及PDF
• 图像格式、颜色深度、CMYK和多页TIFF的新输出选项
• 图像格式旋转选项
• 支持AutoCAD 2000及更高版本的所有DXF和DWG输出格式

文本选项

• 微调转换字符为文本字符串的新选项
• 默认字体映射选项
• 新的扩展文本选项

对象识别

• 从多边形/路径中识别圆/椭圆的新选项
• 识别线段中的水平/垂直线的新选项

分层

• 基于专色名称的层分离（例如RGB_0_0_0）
• 基于颜色和线宽的组合分隔层

属性

• 创建自定义线条样式的新选项
• 颜色支持线和填充属性（AutoCAD 2004及更高版本）
• Width Polyline DXF Entry

综合

• 提高精度和标度线宽度
• 指定基准线宽度的选项
• 改进错误和警告处理
• 增强PDF解释器
• 在PDF中转换隐藏文本的选项

Anychart v8.0.0更新：

模块化系统

模块化系统是AnyChart 8的核心。它允许您仅连接实际使用的图表类型和功能，大大减少了在网页上运行的大小。基于模块化的AnyChart与流行的捆绑工具（如Webpack，Browserify等）完全兼容。使用我们的JS Builder轻松生成自定义构建。

 

 

自定义JavaScript Builds

自定义JavaScript Builder专门用于组装一个仅包含需要使用的功能和图表类型的JavaScript文件。AnyChart 8.0.0版包含30个模块和 16个主题。您还可以创建含许可证密钥的文件 。

 

Node.js服务器端渲染

Node.js服务器是一个轻量级的Web服务器，提供用于生成矢量图形（PDF，SVG或PS）、位图图像（PNG，JPG或TIFF）、PDF报告和CSV和XLSX（Excel）中的数据的API。它使用JavaScript代码以及JSON和XML配置作为输入数据。服务器非常易于安装和自定义，您可以在任何主要平台上运行：Linux，Windows和macOS。它是创建通过电子邮件或社交网络共享工具发送图表的报表系统的理想选择。

 

 

无数据标签功能

无数据标签功能是用于通知图表查看器数据不可用的API。由于默认情况下缺少数据，或者通过“数据更新API”，“排除数据点”功能或通过交互性删除数据，则可能会丢失数据。

 

 

重做CSV/Excel导出

根据需求，我们重新编制了为图表准备的CSV/Excel数据的算法。现在，它考虑到图表类型的特定功能，并允许您为不同的系列使用多个数据集。

 

图表导出设置

现在，您可以自定义每个图表的导出设置：在Facebook上共享的链接和说明、图像导出选项等。

 

上下文菜单自定义API

我们大大简化了上下文菜单定制的过程。现在，上下文菜单中的每个项目都被分配了一个DI，可以访问相应的字段和设置以及添加自定义ID。我们还添加了本地化上下文菜单的选项。

 

一般的API改进

我们大大改进了第八代JavaScript图表库中的AnyChart JS Charts API。 界面设置、网格设置、数据映射设置现在变得很容易。为了方便和简化从

AnyChart 7到AnyChart 8的转换，我们创建了允许大多数用户以半自动模式切换到新版本的迁移工具。

 

数据点大小设置

数据点的大小现在可以控制，我们添加了以下方法：

chart.pointWidth（） - 设置动态添加系列时的固定大小数据点;

chart.maxPointWidth（） - 设置数据更新时的点宽度;

chart.minPointLength（） - 确保显示相对较小和接近零的值。

 

 

3D线图

AnyChart已经支持多种图表类型。v8.0.0增加了新的3D线图类型。

• 改进mapAs()方法的API ，现在它只接受一个参数，而不是四个（旧版本）。
• 现在，条和列图表默认使用值为0的softMinimum()设置。
• 改进网格API，grid()/ minorGrid()方法被替换为xGrid()/yGrid()，xMinorGrid()/yMinorGrid()方法。着色oddFill()/evenFill()方法被替换为fill() 和
  palette()方法。参见Axes基础知识文章了解更多。

• 修复绘图注释标签格式的问题。 (Case 3293, TS-195)
• 解决了在绘制财务图表后改变系列数据的问题（TS-150）
• 修复IE6-8中工具提示的错误（Case 3173，TS-296）
• 
  

【Dynamsoft Camera SDK v5.2点击下载>>>】

• 扫描纸质文件
• 从网络摄像头中捕获图像
• 从扫描的文档或网络摄像头中读取条形码

v5.2更新内容

• 更改了摄像头授权对话框的行为，默认情况下不会显示。
• 添加了一个新的方法dynamsoft.dcsEnv.setLanguage，用来设置摄像头授权对话框中使用的语言。
• 添加了一个新的方法getImagePartUrl，根据图像查看器中的索引获取图像的URL。

Java 9在9月21日正式发布，同时Oracle宣布将Java新版本的发布周期调整为每半年一次。目前，Java新版本的开发也已正式进入轨道。就已公开的消息来看，下一个版本的Java预计会在2018年3月发布，版本号将会是18.3，已经规划加入的特性包括JEP 286和296。

根据reddit站点上的讨论，首先更新的是JEP 296，Valhalla预计很快也会加入进来。OpenJDK的主页面则显示，已确定要在18.3版本实现的是JEP 286和296。

JEP 296主要是将JDK仓库群（JDK Repository Forest）合并为一个仓库，旨在降低管理大量仓库群的成本。根据InfoQ之前的报道，该仓库群的合并已经完成。这些软件仓库是在OpenJDK发展史上历次分裂生成的，在OpenJDK 9及以前的版本中将会继续存在。在这次合并操作之前，OpenJDK曾分裂为多个不同的Mercurial软件仓库群，这导致了许多问题，例如不能以原子方式对多个软件仓库应用漏洞修复（Bug Fixes）。在OpenJDK合并完成后，只会有一个软件仓库，并复制在三个开发线上。为了简化仓库的管理，JDK中还创建了用于在合并和未合并版本间移动更改的工具。

JEP 286提议在Java中引入局部变量的类型推断，该JEP在2016年提出，InfoQ曾经报道过该JEP的概况和相关的开发者调查结果。该JEP旨在减少编写Java代码相关的仪式性的内容，提升开发人员的体验，同时还要保证Java语言的静态性。它会减少开发人员在声明局部变量时，没有必要的变量类型声明。如果该JEP实现的话，在声明局部变量的时候，就可以采用类似如下的方式:

var list = new ArrayList();  // infers ArrayList
var stream = list.stream();          // infers Stream

这种语句只能用于带有初始化器（initializer）的局部变量、增强的for-loop中的索引以及传统for-loop中声明的局部变量。它不能用于方法声明、构造函数声明、方法返回值、字段、catch语句以及其他类型的变量声明中。

关于局部变量的类型推断，不管是JVM体系中的语言还是其他语言都提供了一定形式的支持，比如C++（auto）、C#（var）、Scala（var/val）以及Go（通过:=进行声明）。至于该使用var作为关键字，还是使用let或类似于C/C++中的auto作为关键字，之前曾经有过一个面向开发者的调查。大约84%的回答表明定义可变内容的变量用关键字var是恰当的，只有百分之几的回答者建议使用auto更合适。根据Java语言架构师Brian Goetz介绍，该功能应该使用关键词var。

关于该特性的用法，在reddit上有一些讨论。有人表示，即便在支持“auto”语法的语言中，该特性使用的也比较少，因为有些人希望一眼就能看出变量的类型是什么。也有人认为，var有它的适用空间，在小的代码块中，直接用它实例化对象是可以的。如果是作为方法返回值的话，还是希望明确声明类型，Java的类型推断并不支持方法返回值，这一点倒不必担心。如果函数或代码块比较长的话，就不建议使用var了并要考虑适时进行代码的重写。时间和经验将会让我们更加明确应该在何时使用新功能，就像Optional刚出现时，也是耗费了一些时间才明确其推荐适用场景。

Valhalla项目中包含了一些有趣的JEP，包括值类型(Value Type)、针对原始类型实现泛型功能、增强的volatile等，外界很期待这些内容最终也能添加到新版本中。

2017慧都十四周年狂欢搞事情！砸金蛋100%抽现金红包、满额豪送iPhone X、iPhone 8、DevExpress汉化免费送、团队升级培训套包劲省10万元......更多惊喜等您来探索！

Java社区进程（JCP）执行委员会的成员Ben Evans认为最急需重构的应用恰好就是最适合进行模块化的应用。如果你已经备受Lava Flow/God Class/Stovepipe System地狱的折磨，而且你的利益相关方明确知道这一点，那么你可能更容易说服他们进行一次完整的底层重构，通过渐进式的努力形成一个完成的模块解决方案（而不是简单重构并迁移至Java 8）是值得去做的。

对特定类型的应用来说，这是很有帮助的。例如，我曾经见到有的电子商务网站具有非常大的堆空间，其中包含了大约40G的字符串数据。Java 9的ompact Strings技术能够将这种类型的内存使用减半。这反过来又会对GC的性能带来积极的影响。对于有些应用来说（这可能就包括大型的Solr安装环境及类似场景），单单这一项收益就值得将运行时升级到Java 9。

这项变更是很重要的，因为相对于Parallel来说，G1会在应用线程上做更多的事情，而Parallel几乎没有在应用线程上做任何事情，它基本上完全依赖GC线程完成所有的内存管理。这意味着切换到G1将会为应用线程带来额外的工作，从而直接影响到应用的性能。


在很多（甚至可以说大多数）场景中，这种额外的性能损耗都不是什么问题。但是，在这方面，我确实也曾经见过从Parallel切换到G1时，有一定比例的工作负载会引起性能的下降。对于这些应用来说，这种性能下降是无法接受的，所以他们无法切换至G1收集器。随着G1成为默认的收集器，这将会影响到升级至Java 9的每个应用。

• 阅读Paul和Sander的图书“Java 9 modularity”：它是本权威指南，提到了所有需要注意的地方，阐述了模块、包以及JAR之间如何运行的关联关系； 
• 在模块边界的地方，使用定义良好的接口并且针对这些接口编程； 
• 不要拆分包（split package），也就是说一个包不要分散到两个模块中。Adopt OpenJDK有个探测工具，我们可以用它来探测已有的代码； 
• 确保不要存在循环依赖（Jigsaw不允许这样）； 
• 模块在源码的布局上与我们已习惯的方式有所不同，需要确保构建工具能够进行对应的处理； 
• Jigsaw不支持多版本。

Xmanager Enterprise

Xmanager