WPS：在网页中使用 PostScript 绘图

PostScript 是由 John Warnock 和 CharlesGeschke 与 1982 年创建的页面描述语言，在出版行业使用广泛。而 WPF 项目将 PostScript 移植到网页中，使开发人员可以利用 PostScript 在网页中进行绘图。

WPS 是一个使用 JavaScript 编写，并基于 HTML 5 中 Canvas 的 PostScript 和 PDF 解释器。因此，只有在支持 HTML 5 的浏览器（如最新的 FireFox，Opera 和 Chrome）上才能使用 WPS 框架。

在主页上，WPS 创建者提出了以下几点设想及问题：

• 作为了解和实现一种类 Forth 的语言，PostScript 是一个不错的选择：
  • 它拥有良好的语法及基于栈的执行机制。
  • 拥有广泛的实践基础。
  • 在印刷与出版等行业中拥有长期的成功经验。
  • 它是 PDF 的前身。
  • 几乎所有东西（如编辑器，图片，文档）都可以大量复用。
  • 适合结合 HTML 5 进行试验，因为在 PostScript 看来，canvas 只不过是另一种低端设备。
• 简单并灵活：
  • 为快速变更，而不是纯粹的执行速度作优化。尽可能地保持代码的简小与规则。
  • 验证 JavaScript 是否可以作为 Web 平台上可移植的组装器（assembler），以及在 JavaScript 的基础上构建一个实际可用脚本语言是否高效可行。如果不行的话，找出其限制所在。
• 将语言 / 环境的核心尽可能地缩小：
  • 可以在客户端或服务器端使用其它语言编写解析器。
  • 开放，设法可以在客户端和服务器端运行“同样的代码”。
• 能否在 Web 浏览器上阅读 PDF 文档，并摆脱服务器端图片生成？
  • 利用 OnDoc 实现基于 Canvas 的 PDF 浏览及编辑功能。
• 可能可以使用另一种后端设备，而不是 HTML 5 Canvas 来实现这些功能，如 SVG 设备。
• 探索一种能够用于构建 Web 应用程序产品的 Lisp 解释器的可能性。

目前 WPS 仍处于开发过程中，还有一些限制及问题。

即时出现了基于Flash 和Silverlight 等RIA 技术的解决方案，业界也从来没有放弃过使用传统、简单且标准的技术来实现丰富的网页应用程序，其中一个重要的原因便是“即改即现”的网页开发模式。如之前报道过的微软 Gestalt 框架，设法引入更高效的 Python 和 Ruby 语言，来取代现有的 JavaScript 进行客户端网页开发。在 WPS 之前， Raphaël 等 JavaScript 绘图框架也提供了客户端绘图能力。如今 WPS 又提出了另一种尝试，只把 JavaScript 作为一种组装器，通过引入一种成熟的语言形式，在页面上进行图像绘制等工作。

您更倾向于哪种方式呢？