迈向自由办公[转] （推荐） - UNIX Resources Network

迈向自由办公

一、序言

在几年以前，Richard M. Stallman所推行的自由软件理念被认为是天方夜谭—没有严密的项目管理，如何保证程序员们协调一致？没有金钱的激励，有几个人能最终坚持下来？没有可观的利润，能吸引哪一家商业公司的参与？而没有统一的目标，又如何避免程序开发的混乱？开源阵营这种匪夷所思的想法令诸多商业企业嗤之以鼻，在很漫长的时间内，微软都没有将自由软件放在眼里，在它看来，这不过是一群小孩子在玩过家家游戏，不需多长时间自然会土崩瓦解。

在一开始，局面确实如微软所想，作为开源的核心，Linux陷入版本混乱的僵局，人们普遍认为它将重蹈UNIX的覆辙，在2000年间火热一段后迅速归于沉寂。而其他的自由软件项目就不必说了，在项目建立后的漫长时间内都没有什么成果出现。按照微软的想法，大概没有多少程序员能坚持到最后。很遗憾，这种合乎逻辑的期望并没有成为现实，恰恰相反的是，自由软件在很短时间就克服了初期的混乱和无序，进入稳定的协作开发阶段，而在经过数年的开发之后，一大批自由软件开始步入成熟阶段，开源成果大量涌现，其中最为著名的便是Mozilla Firefox项目—凭借胜出一筹的安全性、诸多人性化功能以及强大的可扩展性，Firefox硬是在铁板一块的浏览器市场抢占市场份额，一举打破微软 IE的垄断地位，迫使微软公司不得不改变策略，开发IE 7.0与之对抗。而在最关键的操作系统领域，我们看到Linux应用进入了冲刺时代，一些技术问题不断得到解决，一个成熟、可靠、性能卓越的开放平台基本建立，而Linux业界更是开始朝向完美型产品方向发展，它们将超越的目标放在苹果的Mac OS X 10.3系统。在未来的1-2年内，我们有望看到Linux在商业应用中进入雪崩式成长阶段。

这个时候，Linux平台下的办公软件就成为焦点，目前，可运行于Linux环境的办公套件主要有KOffice、OpenOffice.org 体系（包含SUN StarOffice、中科红旗RedOffice等）、永中Office 2004以及尚未出现的金山WPS Office V6，其中，KOffice隶属于KDE桌面环境，暂无法支持Windows平台；永中Office 2004与金山WPS V6则是我国软件厂商出品的跨平台套件，虽然水准突出，但属商业软件范畴，也不在我们的讨论之列；真正属于开源体系，且实力较强的只有 OpenOffice.org以及衍生项目。可遗憾的是，虽然目前的OpenOffice.org可满足用户的基本需要，但在易用性、操作性以及功能方面都无法与微软的Office系列相比，办公软件仍然还是Linux系统的软肋。不过，这种情况有望在OpenOffice.org 2.0面世后好转—OpenOffice.org 2.0无论在软件品质还是技术上都有长足的进步，它所带来的一系列技术革新绝对具有革命意义。

二、OpenOffice的曲折发展历史

OpenOffice.org的历史最早可以追溯到上个世纪八十年代，当时，德国一位天才少年编写了一套名为“StarWriter”的文字处理软件，该软件推出后受到热烈欢迎，并在八十年代末的欧州地区占据霸主地位。1995年，该软件被扩展成StarOffice办公套件，套件中除了包含原有的StarWriter外，还增加了电子表格的StarCalc以及电子简报的StarImpress等，为更好地推广产品，创始者专门成立了名为 “Star Division”的公司来专门经营该套件。在上个世纪八十年代末，StarOffice套件曾在欧州地区广泛流行，它从最初的1.0版本一直发展到 5.0，但在微软推出Office 97套件之后，StarOffice也和其他办公软件一样遭遇发展困境。

图1 OpenOffice.org 1.1.2 Writer，在英文环境下表现尚好，但中英文混排式很容易出现版面错乱。

1999年8月，SUN公司收购了Star Division，取得StarOffice 5.0。但SUN并没有效仿微软进行独自开发，它认为若仍然以传统的商业开发模式来运作，StarOffice无论如何都无法与微软的Office系列竞争，毕竟微软公司在该领域投入巨大且掌握决定性的操作系统平台，SUN的擅长领域只是在服务器和工作站领域，办公软件绝非其特长。嗅觉敏锐的SUN将视角转移到开源阵营—在1999年，这应该是非常前卫的想法，之前的例子是Netscape公司将Communicator 5.0浏览器的源代码交付给开源社区，形成Mozilla开发项目，而后续的程序升级则由开源社区负责，Netscape在此基础上来发展自己的新版 Communicator。此种做法的好处是可借助开源社区的力量，大大节省企业的开发资源。为此，SUN决定效仿Netscape公司的开源做法。 2000年7月，SUN资助建立了OpenOffice.org社区，同年10月，SUN将大约800万行的StarOffice源代码正式公布， OpenOffice.org由此成为与Mozilla、Apache项目并列的世界三大开源社区之一，而SUN则在OpenOffice.org的最新研发成果基础上开发自己的新版StarOffice。在当时，SUN远没想到开源项目本身能够成就什么大气候，毕竟之前没有任何成功的例子可循，而作为参照的Mozilla项目也仅处于起步阶段，离现在的FireFox还有十万八千里。

我们有必要对OpenOffice.org的名称作出一番解释。相信许多人都将它称为“OpenOffice”，但这并不符合规范， “OpenOffice”这个名称虽然是最理想的，但它很早就被其他企业所注册，而如果改用其他的称谓，软件的开源性质就无法在名称上获得直接体现。最终，开源阵营决定在“OpenOffice”单词的后面添加.org后缀，创造出“OpenOffice.org”的名称。为方便起见，它也被简写为 “OOo”，这也是官方定义的名称规范。

最早被提交给开源社区的是StarOffice 5.2版本，它也可以说是OpenOffice.org最初版，开源社区在它的基础上进行深入开发。与其他的项目一样，OpenOffice.org项目开始并不顺利，参与者也不多，直到2002年5月他们才发布OpenOffice.org 1.0正式版。该版本包含Writer（文字处理，类似Word）、Calc（电子表格，类似Excel）、Draw（工业流程图、类似Visio）、 Impress（电子简报，类似PowerPoint）、Database（桌面数据库，类似Access）、Math（数学公式编辑）等相当完整的软件，可谓是阵容庞大，而除了可支持Windows系统外，它还有Linux、Solaris对应的版本，是一款真正意义上的跨平台软件。不过， OpenOffice.org 1.0推出之后，获得的反馈并不积极，大家的目光都放在微软的Office XP上面，加上Linux系统陷于发展的低潮期，对OpenOffice.org 1.0有兴趣的用户很少。同时虽然号称正式版，OpenOffice.org 1.0在许多地方都不完善，甚至常会遇到版面发生错乱的低级问题（尤其是在编辑中文内容时），实用价值非常有限。可想而知，这样的产品显然无法吸引用户，即使它是免费提供的。至于SUN公司，它在OpenOffice.org 1.0的基础上开发出自己的StarOffice 6.0，二者的差别在于StarOffice 6.0属于商业产品，对商务应用所需的功能进行强化，如加入了更多的字体、商业模版以及一些搜索功能，且提供了企业级的支持与服务。另外，SUN没有采用 OpenOffice.org中不够成熟的桌面数据库，而是采用德国Software AG公司所开发的Adabas D数据库作为替代。此外，StarOffice可支持包括简体中文、繁体中文、韩文和日文在内的亚太语系并推出相应的版本，但由于 “StarOffice”的商标在亚洲地区已被注册，SUN不得不将亚太语系版更名为StarSuite 6.0—大家要明确的是StarSuite 6.0与StarOffice 6.0其实是同一个东西。不可否认的是，商业版本的StarOffice 6.0比OpenOffice.org 1.0完善，但若从产品角度考虑，这两者并没有太大的区别，因为StarOffice 6.0所作的改动都不涉及核心部分，仅是在表面上作文章。

2003年10月，OpenOffice.org项目发展到了1.1.0版，诸如版面错乱的严重Bug获得一定程度的修正，可用性大大提高。不过它更重要的变动是大举拥抱“开放”—作为OpenOffice.org的前身，StarOffice是一款专有的商业软件，OpenOffice.org 1.0上还带有许多商业软件的影子，仍采用专属性的SXW文件格式、缺乏对开放文档输出的支持等等。OpenOffice.org 1.1.0在一定程度上改变了这一点，虽然尚未建立开放文档格式，但套件中的Writer可以直接将所编辑的文件输出为PDF格式（Adobe制定的电子文档格式），Impress也能将幻灯片输出成SWF格式（Macromedia的Flash动画）—无论PDF还是Flash，都属开放的文件格式，任何企业都可以依据标准自主选用，相对而言，微软Office乃至其他的商业办公软件，文件格式都是完全专属性质，这不可避免造成软件壁垒，给用户带来许多不便。OpenOffice.org 1.1.0推出之后得到外界的广泛注意，由于实用性明显提升，许多用户开始对它感兴趣，而OpenOffice.org开始广为人知其实也是从1.1.0 版开始的。SUN公司仍然以此为基础开发自己的后续版本，但它采取一个投机取巧的措施：将StarOffice的版本从6.0大幅提高到7.0，而非外界认为的6.1，这更多是一种宣传手段—我们要知道的是，StarOffice 7.0之于OpenOffice.org 1.1.0，同样没有伤筋动骨的改造。

进入2004年后，OpenOffice.org的项目开发工作明显加速，1.1.1、1.1.2和1.1.3相继推出，程序Bug不断获得修正。更重要的是，该项目也吸引了全球各地无数开发者的参与，尤其以大学和科研院所最为活跃，项目开发呈现爆发式增长。OpenOffice.org可支持 Windows 9x/2000/Me/XP、Linux、PPC Linux、FreeBSD、Solaris、IRIX、Mac OS X等操作系统，拥有27国语言的版本（这个数量还在持续增加），在跨平台、跨语言领域无人能敌。尽管OpenOffice.org仍存在大量的问题，易用性远难同微软Office相媲美，但在这个过程中OpenOffice.org获得的技术进步有目共睹，开源社群的活力也显露无疑。

图2 OpenOffice.org 1.1.3 Calc，具有相对出色的性能，较Writer成熟。

2005年5月，OpenOffice.org 2.0将正式发布，同1.1.X相比，2.0版所带来的绝对是飞跃性的提升，而它的变化不仅仅在于功能及易用性方面，更关键的是选择了开放文件系统。到此为止，OpenOffice.org才算是真正走上“开放”的轨道。

三、OpenOffice.org分层技术架构

在介绍OpenOffice.org 2.0之前，我们有必要深入了解OpenOffice.org的技术架构。前面我们介绍过，OpenOffice.org是一套真正跨平台的软件，但它采用的主要程序语言并不是与平台无关的Java，而是面向对象的C++（底层代码考虑到效率原因，采用了C语言）。尽管C++编译器存在于每一个平台上，可以支持软件的多环境编译，但用它来开发跨平台产品是一件非常艰难的事情。开发者必须为每一个操作系统的运行版本进行独立编码，并分别加以编译执行，技术难度相当于同时开发几套这样的大型软件。OpenOffice.org可支持几乎所有的操作系统平台，这让人感觉几乎是个“奇迹”。那么， OpenOffice.org如何实现这一点？难道是单纯依靠数量巨大的程序员在埋头苦干？这当然不是最终答案，事实上，OpenOffice.org能顺利实现跨平台，很大程度上得益于它所采用的分层式技术架构，自上而下，OpenOffice.org的逻辑架构可分为应用层、构架层、基础设施层和系统抽象层。每个子层和库并非对应某一个具体的源代码模块，而很可能由若干个逻辑相关的模块构成。在OpenOffice.org刚发布时，拥有不到100个代码模块，但到1.1.2版，代码模块已提高到150个左右，预计2.0版代码模块的数量将会更多。不同的模块在逻辑上关联，它们之间往往存在非常复杂的相互依赖关系。下面，我们将对OpenOffice.org的这四个逻辑层进行详细的阐述。

图3 OpenOffice.org的分层技术架构，从上而下可分为四个逻辑层，每一层都是由若干个功能不同的子层和库共同组成。

3.1 系统抽象层：跨平台的关键

图4 系统抽象层的四大子层/库

在四个逻辑层中，应用层、构架层和基础设施层为所有OpenOffice.org版本共同分享，决定软件本体，而系统抽象层（System Abstraction Layer）则封装了所有系统相关的API（应用程序接口），保证其他三个逻辑层能以平台无关的方式访问系统资源。简单点说，我们可以将系统抽象层看作是 OpenOffice.org与操作系统的中间桥梁，这样，程序员只要对这部分代码进行重写，便可以让上层的OpenOffice.org实现跨平台运作。而由于系统抽象层的代码占整体不到10%，重写的工作量远小于常规做法。当然，这项工作在刚开始时也是具有相当难度，但经过多年的积累，跨平台编码的工作都已经全部完成。如果未来要对OpenOffice.org进行不断地升级，开发者也只需对其他三个逻辑层进行改动并重编译，系统抽象层的代码基本无需变动，这样便可以在不断提升OpenOffice.org程序品质的同时，充分保证OpenOffice.org的跨平台特性。

不过，系统抽象层也会带来一些负面的因素，它的存在让OpenOffice.org程序本体和操作系统的交互多了一个环节，不可避免对性能造成损失—我们可以看到，OpenOffice.org在Windows系统中的性能落后于微软的Office套件，启动速度相对较慢，其原因就在于此。幸好这不算是什么大问题，通过对抽象层的代码优化，可在一定程度上提高其执行效率，再加上目前的主流硬件都具有出色的性能，OpenOffice.org性能上的不足完全可以被弥补。

系统抽象层的四个子层/库

● 操作系统层（Operating System Layer，OSL）：封装了用来访问和使用系统资源（例如文件、内存、套接字、管道等）的操作系统功能。该层与系统联结紧密，为了保证效率，它采用C语言进行编写。

● 运行时库（Runtime Library，RTL）：提供所有与平台无关的功能。如提供字符串类的实现，也可以将字符串转换到不同的字符集，内存管理功能也是在该模块中实现。

● 标准模板库（Standard Template Library，STL）：作为泛型容器类来使用，它提供了列表、队列、栈、映射等模板/类的实现。

● 可视类库（Visual Class Library，VCL）：OpenOffice.org的核心库之一。VCL的实现分为两个部分，一部分封装了对不同的底层GUI系统（GUI， graphical user interface，图形用户接口）的所有访问方式，另一部分是完全与平台无关的，包括面向对象的2D图形API和OpenOffice.org使用的整个窗口部件集。这种划分保证了不同环境的OpenOffice.org拥有相同的外观、功能和操作模式，用户在平台转换的过程中不会感觉到有任何困难。另外，打印功能、剪贴板和拖放功能也都是在可视类库中实现的。

3.2 基础设施层：程序本体的骨架

图5 基础设施库的逻辑组成

基础设施层（Infrastructure Layer）是OpenOffice.org程序本体的基础，它向下与系统抽象层交互，向上则为应用组件提供服务。基础设施层包括组件模型、复合对象、脚本与Basic库等三大部分，这三者分别负责不同的功能，而各自的内部又包含更多的子模块。

组件模型由虚拟操作系统层、工具库、通用网络对象、通用内容代理等多个模块联合构成。其中，虚拟操作系统层（Virtual Operating System Layer，VOS）是一个C++类的组合，允许程序方便地调用文件、线程、套接字等系统资源，提供了一个以面向对象方式访问系统资源的便捷途径。工具库（Tools Libraries）则是由许多提供辅助功能的小库组成，它包括处理日期时间相关数据、结构化存储、通用注册表、类型安全管理和持久属性数据等诸多功能的实现。通用网络对象（Universal Network Objects，UNO，下文将作详细介绍）是OpenOffice.org所使用的独立组件技术，这种组件技术基于多线程和网络通讯环境，它不依赖于任何图形子系统。其中，UNO中的IDL编译器（IDL：接口定义语言）可根据特定的接口定义产生二进制字符，用以表示相关的C头文件或Java文件，而这个二进制表示形式与程序的运行平台和语言都没有关系，采用任何语言编写的代码模块都能够调用。该技术的优点在于，可有效减少开发多语言程序所需的代码量，但缺点是需要对每种代码都提供后端支持，且每种编译器在运行时都需要一个桥接模块。通用内容代理（Universal Content Broker，UCB）允许所有上层代码对不同类型的结构内容进行透明访问，UCB由一个核心和若干通用内容提供者（Universal Content Provider，UCP）组成，后者用来集成不同的访问协议。目前，OpenOffice.org的UCP已集成了HTTP、FTP、WebDAV和本地文件系统上的内容访问功能。

对任何一个办公套件，文档复合功能都是必不可少的，这在使用中非常重要。例如，我们经常会遇到电子表格嵌入到文字处理文件的情况，那么在底层上，这种做法是如何实现的呢？对于OpenOffice.org，这项任务由基础设施层中的“复合对象（Compound Objects）”专门负责，现在的OpenOffice.org可支持复合文档和镶嵌多媒体播放器这样的可视控件，且该种实现也是与平台无关的。复合文档的所有内容均以OLE结构存储格式兼容的方式加以保存，这样一来，只要支持OpenOffice.org的操作平台就可以顺利访问OLE复合文档。

对OpenOffice.org程序主体代码的翻译工作也是在基础设施层中完成，专门负责这项工作的就是“脚本与Basic库（Scripting and Basic Libraries）”，该组件提供了一个解释器，用以解释源代码并产生元指令。这些指令可以通过附带的元指令处理器直接执行，或在模块/库里持久保存以备后用，对此我们就不作详细解释了。

3.3 构架层：功能模块的复用

构架层（Framework Layer）负责实现应用程序对各个功能模块的复用，例如公共对话框、文件访问、配置管理等功能为OpenOffice.org套件中各个应用所共同拥有，而构架层就提供了一个资源共享的媒介，避免需要为每个应用重复编写代码的情况。（套件中的Writer、Calc、Draw、Impress、 Database、Math等软件被称为“应用”，下同）

构架层包括“应用架构库（Application Framework Library，SFX）”和“共享功能库（SVX Library）”两个部分，前者为所有的应用提供运行环境，每个应用共有但其他逻辑层未能提供的功能都在这里实现。就程序结构来说，每个应用都需要一个外壳（Shell）和若干视图（View），而应用架构库便提供了所有的基础功能，各个应用只需补充其特有的功能即可。例如，模板管理、配置管理、菜单和工具条的合并与设置，对所有应用的定制化等功能都是由应用架构库所提供。而共享功能库（SVX Library）则可以为各个应用提供架构无关的共享功能，例如，它提供了面向对象的“画布”功能，允许各个应用都直接进行图形编辑和输出，除了2D引擎外，该画布还包含一个完整的3D引擎，用于某些3D元素的处理。此外，字体选择、颜色选择、数据库连接等各应用共享的功能也是在这里实现的。

3.4 应用层：OpenOffice.org的终端实现

应用层位于OpenOffice.org逻辑架构的最上方，所有的应用都是在此实现的，它们包括Writer文字处理、Calc电子表格、 Draw图表绘制、Impress演示文稿等等，这些应用实际上都是基于下面的共享库，在运行时由应用架构进行动态加载，分层次和共享的架构为所有这些应用创造一个必要的基础环境。大家可以在实用中接触到这些应用，对此我们就不作过多的介绍了。

四、环境融合与功能扩展

“开放”是OpenOffice.org的核心，这种理念在开发过程中也获得忠实的体现，而OpenOffice.org的开放特性让它具有强大的环境融合与功能扩展能力。具体点说，这两点完全依赖于OpenOffice.org所提供的UNO组件模型以及标准化的API设计。

4.1 UNO组件模型：实现与操作环境的融合

在现时的开放系统世界中，并不存在一个标准统一、所有环境都通行的组件技术—Linux系统的KDE环境和GNOME虽然都将CORBA（公共对象请求代理结构）作为底层通讯方式的基础，但两者的高层组件模型并不相同：KDE采用Kparts，而GNOME则采用Bonobo。由于不存在通用的组件，程序员很难为OpenOffice.org编写出可同时支持两种桌面环境的组件。而退一步来说，即便CORBA协议能一统天下，它也很难满足实际需求。CORBA规范主要用于远程服务和分布式网络应用，它并不包含复合文档以及其他桌面软件相关的功能，以它作为OpenOffice.org的组件技术显然很不明智。不仅是OpenOffice.org，Mozilla开源项目也遇到同样的问题，最终Mozilla社区决定自己建立一个可轻松移植到不同平台的轻量级组件模型，它就是后来的XPCOM。自定义组件模型尽管技术难度大些，但优点是非常明显的：针对性强、可定制化，能很好满足程序的实际需要。有鉴于此，OpenOffice.org也决定自主创建组件模型，它便是我们所要介绍的UNO组件技术（Universal Network Objects，通用网络对象）。

在制定UNO技术时，OpenOffice.org阵营雄心勃勃，希望它可满足现代桌面应用对组件的所有需求，并在功能和效率上达到与微软Office相当的水准，为此，UNO被设计得异常强大，它的主要特性包括以下几个方面：

● 开放 UNO可支持目前所有流行的组件标准通讯协议，如CORBA、JavaBeans、JavaScript、Python、Perl、OLE （Windows Scripting Host、Visual Basic、Delphi）等脚本语言，当然也支持C++和C语言的本地集成。其中，C、C++、Java和Python都已实现了完整的UNO绑定，而 OpenOffice.org Basic、OLE和共同语言架构（Common Language Infrastructure，CLI）目前只支持访问UNO组件，还无法用于创建新的组件。

● 面向对象 UNO采用面向对象设计，支持聚集、集成、异常处理和多态等面向对象的概念。

● 基于接口 UNO的功能被集成进接口里，具有相似功能区域的组件对同样的接口有访问权限，开发者将具有组件世界的真实感觉。

● 平台/开发系统无关 UNO被设计成平台无关性，只要有OpenOffice.org的平台便拥有UNO。而UNO本身也可采用目前所有的开发环境和编程语言实现，包括C+ +、C、Visual Basic、Windows Scripting Host和所有支持COM的系统、CORBA、JavaBeans组件、以及OLE等等。

● 支持网络基于UNO技术的组件可以在网络上通讯，也可以在远程服务器上实现，该技术允许OpenOffice.org运行于网络环境中，如程序本体可位于互联网服务器上，用户仅需通过本机上的接口客户端即可使用。

不过，采用UNO组件也带来了一个新问题：不同的操作环境采用不同的组件技术，KDE/Kparts、GNOME/Bonobo、CORBA、 Mozilla/XPCOM和OLE/ActiveX同时共存，如何让UNO组件与它们进行交互？OpenOffice.org的解决方案就是组件桥接技术，通过桥接方式，OpenOffice.org可以自由访问其他的组件，在一些概念相似的环境中桥接方式可拥有较高的效率，但在一些差异较大的环境中桥接功能就不可避免要损失性能，如果用户接触过多平台的OpenOffice.org套件，对此应该有所体会。此外，桥接方式也可实现办公套件与操作环境的集成，如目前OpenOffice.org已可作为一个ActiveX控件在IE浏览器内直接运行。为Mozilla FireFox提供的插件也已开发完毕，将在2.0版中得到体现，而OpenOffice.org为KDE中Konqueror浏览器所制作的插件也接近完成。但比较遗憾的是，OpenOffice.org与GNOME/Bonobo的桥接项目在开始一段时间后又中止了，我们在短时间内可能无法看到 OpenOffice.org与GNOME环境的集成。

4.2 开放的API：实现强大的功能扩展

OpenOffice.org的应用程序接口（Application Programming Interface，API）建立在UNO组件技术的基础之上，UNO决定组件和应用如何进行相互通讯，某种编程语言如何访问API，而API则定义了独立于编程语言、访问OpenOffice.org功能的通用接口。这种接口结构的好处在于，如果在开发过程中需要重新实现某个应用，仅需要修改相应的模块即可，这种模式可有效保证软件的质量并提高可维护性。

从功能上分，OpenOffice.org API可以划分为以下四大类：办公软件接口、集成架构接口、应用域无关接口和组件系统接口。办公软件接口用于对文字处理、电子表格、绘图和演示文稿等应用；集成架构接口则让OpenOffice.org可轻松集成新的组件；应用域无关接口负责包括属性访问、集合、流操作、附加脚本引擎等许多重要的功能；组件系统接口则位于最基层，负责上层模块与底层系统的通讯。OpenOffice.org API具有平台无关性和版本无关性，很容易被扩展，且具备良好的重用特性，借助这个开放的接口，OpenOffice.org可以很容易地实现许多程序本体来不及提供的新功能，它甚至允许你更换OpenOffice.org的用户界面。这个概念同Firefox的扩展插件非常类似，相信大家应该比较熟悉。

五、软件品质与开发思想的飞跃

如果你有耐心看完上一段枯燥的技术描述，并对此有所认识，那么将对OpenOffice.org 2.0有很深的理解。无论是基础结构还是逻辑设计，OpenOffice.org 2.0均完整地继承了上述思想，它所带来的变革集中体现在两个方面：一是软件品质的跃升；二是开放文档格式的引入。

5.1 软件品质明显提升

图6 OpenOffice.org 2.0的启动画面，通过竞赛方式加以遴选。

早在2003年8月，OpenOffice.org社群就为2.0版制定了个宏伟的目标。所有的参与者均希望OpenOffice.org 2.0能有革命性的进步：可持续地全面兼容微软Office，程序比微软Office更为精简、执行效率更高，且要比微软Office更富实用价值，提高用户的办公效率。这样的目标在短时间内显然无法实现，但也足以让OpenOffice.org 2.0获得突飞猛进的品质提升。在撰写本文时，OpenOffice.org 2.0的正式版尚未发布，我们所能接触到的只是测试版本，但它已初步表现出非凡的魅力：Writer文字处理软件彻底解决了版面错乱的问题，在正常使用时表现出应有的品质，虽然功能仍显简单，但用它来代替Word已经没有任何问题；Calc电子表格表现更出色，无论是功能还是操作方式，都与微软Excel 2003相差无几；至于其他的应用，情况也大同小异，读者如果有兴趣，不妨下载使用便可有直观的了解。但比较令人遗憾的是，OpenOffice.org 2.0测试版仍没有解决效率问题，首次程序启动以及文档读取的速度都明显慢于微软Office，但在启动一次后再打开其他的OpenOffice.org 文档，效率明显改善，倘若正式版可进一步改善程序效率，相信会更受欢迎。其次，测试版偶有运行不稳定的现象，但相信正式版本可较好解决这个问题。再次， OpenOffice.org 2.0的内存占用较高，这是由它的程序架构所决定的，估计未来也很难改变。

5.2 开放文档格式

如果说软件品质提升只是表面功能的增进，那么采用开放文档格式就称得上是OpenOffice.org 2.0内在的革命。

图7 OpenOffice.org 2.0 Writer软件界面

与开放文档格式对应的，便是目前广泛流行的封闭式文档格式，例如，微软Word采用doc格式，Excel采用xls格式，永中Office采用 eio格式，金山文字则采用wps格式。所有这些文档格式都是封闭性的，相互之间彼此保密，应用软件无法支持使用其他软件创建的文档，即便这两者看起来一模一样。封闭格式的最终胜利者是微软公司，由于文档格式不为人知，其他办公软件无法实现对微软Office 100%的兼容，如果用户之前已有大量的相关文档，那么就只能永远使用微软的产品，否则将出现历史文档无法完美打开的难题。对于这一点，国内的软件界应该体验颇深，作为办公软件的两大龙头，永中与金山公司都深为这个问题所困扰，尽管它们的产品号称可高度兼容，但总会出现这样那样的问题。凭借文档格式的垄断地位，微软在办公软件领域占据超过90%的市场份额，用户不得不接受相关软件昂贵的价格。

图8 OpenOffice.org 2.0 Impress软件界面

业界很早就意识到文档格式封闭的问题，即便微软公司没有垄断市场，也会出现大量互不兼容的文档格式满天飞的问题，用户不得不为每一种格式配备对应的办公套件方能读取，这种情况或许会比微软垄断市场还要糟糕。那么，这个难题应该如何解决？显然，制定一套开放的文档格式是最好的解决之道，倘若所有的软件厂商都能采用共同的格式，那便不存在兼容问题，不管哪一家厂商出品的套件，均能顺利读写其他软件创建的内容，无疑是一个非常理想的境界。但是，我们不能指望商业界完成这项使命，无论是微软还是其他什么办公软件企业，封闭与商业利润都是同义词，谁都不愿意开放自己的文档格式，唯恐担心竞争对手获益比自己更多。最终，开源社会扛起这杆大旗，开始将开放文档格式付诸现实。

图9 OpenOffice.org 2.0 Calc软件界面

负责文档格式制定的是OASIS组织旗下的“开放办公软件XML格式技术委员会（Open Office XML Format TC，注意拼写上的差异：Open Office并非是OpenOffice.org）”。该委员会成立于2002年11月，其成员包括办公软件企业（Sun、IBM、Corel和 Koffice）、企业出版/内容管理企业（Arbortext、SpeedLegal、Stellent、Blast Radius）和IT咨询公司（CSW集团、Propylon、ISOGEN、Toolsmiths），总计有十几家重量级的企业，波音公司和澳大利亚国家档案馆也都是该委员会的成员。而它的任务便是创建一个完全开放的、基于XML的办公软件文档格式规范。2004年3月，OASIS Open Office XML格式1.0版草案公布，并面向全世界征集意见，它的正式版本预计会在2005年内发布。1.0版草案其实是以OpenOffice.org的XML 文件格式作为基础，进行了大量更改和提高，且采用全新的XML命名空间定义以保持规范的独立性。而最先对OASIS Open Office XML文件格式提供支持的应该是Linux KDE图形环境下的Koffice，早在2003年8月份它们便宣布转移计划，在1.0草案公布后的第二个月，Koffice便对该格式提供初步的支持。与此同时，OpenOffice.org阵营也决定不再采用旧有的sxw、sxc、sxi等封闭格式，2.0版套件直接采用OASIS Open Office XML作为缺省的文件格式。GNOME Office项目则相对迟缓，但它们也表示会根据用户的需要来支持开放格式。至于Corel公司，肯定也会在WordPerfect中采用OASIS Open Office XML作为默认的文档格式，毕竟Corel本身就是该委员会的主要创始成员之一。

开放文档格式实施以后，迅速获得一些国家和地区的热烈响应，而最为积极的首推欧盟政府。2004年5月，欧盟行政机关信息交换小组（IDA）向欧洲委员会送交提案，建议欧盟政府全面采用开放的文档格式，而“OASIS Open Office XML”规范则被欧盟行政机构通讯委员会（TAC）所重点推荐。TAC进一步建议说，在05年正式版规范公布之后，将它提交到国际标准化组织（ISO），使之成为文档格式的国际标准，这将对它的推广大有好处。至于其他的一些商业软件公司，对此多半是充耳不闻，尽管他们的客户早已深受专属性文档格式的困扰。

我们有必要对开放文档格式的技术优势作一番补充介绍。在保持开放以及跨平台特性的同时，Open Office XML规范也拥有明显的技术优势，例如，封闭文档格式的互换性普遍很差，如果将它们转为PDF、html之类的格式将会出现大量的内容损失；再者，封闭文档格式普遍体积庞大，很不利于网络传输，用户不得不采用压缩处理才行。在制定规范的时候，OASIS Open Office XML委员会就充分意识到这些问题，在这些方面Open Office XML规范均有相当出色的表现。

六、前瞻：可预期的光明前景

作为世界三大开源项目之一，OpenOffice.org在Apache、Mozilla之后也将进入到收获阶段，OpenOffice.org 2.0的出现将是一个转折点。在不到两年时间内，它实现了软件品质的跨越性进步，软件的实用价值大大提升，虽然仍达不到与微软的Office套件相媲美的程度，但对绝大多数的用户来说，以OpenOffice.org 2.0作为日常办公套件已经没有任何问题，只要很短的时间用户们都可上手使用。而对于Linux系统的用户，OpenOffice.org 2.0不啻为雪中送炭，它的成熟完善为Linux桌面应用的全面展开奠定了坚实的基础，在最后一道障碍扫除之后，Linux进入桌面将重新变成一场轰轰烈烈的运动，也许微软公司对此将大皱眉头。

如果我们单单谈论软件本身，OpenOffice.org 2.0仍不足以让人激动，毕竟业界比它水平高的办公套件并不罕见，除微软的Office之外，我国金山公司的WPS Office V6、永中公司的Office 2004均在软件品质上更胜一筹，其中永中Office采用Java语言编写，可实现与OpenOffice.org媲美的跨平台运作，但所有的这些软件均属商业软件，且应用范围一直都比较狭窄，更别提有机会胜过微软了。唯一能够承担阻击微软Office的或许非OpenOffice.org莫属了，虽然它仍然还不够成熟，但发展速度令人吃惊，技术进步可谓日新月异。更重要的是，OpenOffice.org无论在架构上还是文档格式上都充分体现了先进性：分层逻辑架构确保了OpenOffice.org的跨平台实现和强大的扩展功能，开放文档格式更让它成为自由世界的号角。随着Linux系统的发展壮大，OpenOffice.org、开放文档乃至整个开源社群都将越来越具有影响力，而开源社会所积极倡导的知识无偿共享理念也日益深入人心。对任何商业企业来说，否认这一场即将来临的伟大变革将是自欺欺人，足够敏锐的企业应该考虑如何融入这一场变革，甚至积极成为主导力量，以避免在未来可能被边缘化的事实。

来源：《个人电脑》2005年第05期 http://www1.pcpro.com.cn/topic.php?id=6062

----

killall 眼高手低 用心浮躁 浅尝辄止

[Original] [Print] [Top]

« Previous thread
深入了解OpenOffice.org——路广[转]

Linux桌面与办公软件
第2页

Next thread »
Mutt与Pine等文本电邮客户端程序的比较

WEB	unixresources.net

备案序号: 京ICP备05006143 webmaster: webmaster@unixresources.net

This page created on 2008-07-17 02:08:40, cost 0.060889959335327 ms.