incubator-ooo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1206877 [4/5] - in /incubator/ooo/ooo-site/trunk/content/tools/releases: ./ buglist_1_0_2.html buglist_1_1_beta2.html index.html ooo11beta.sxw ooo11beta2.html q-concept.html q-concept.pdf q-concept.sxw release_process.sxw
Date Sun, 27 Nov 2011 22:28:41 GMT
Added: incubator/ooo/ooo-site/trunk/content/tools/releases/q-concept.html
--- incubator/ooo/ooo-site/trunk/content/tools/releases/q-concept.html (added)
+++ incubator/ooo/ooo-site/trunk/content/tools/releases/q-concept.html Sun Nov 27 22:28:40 2011
@@ -0,0 +1,2085 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1252">
+	<TITLE>StarOffice / &ldquo;Q&rdquo; Product Concept</TITLE>
+	<META NAME="GENERATOR" CONTENT="StarOffice 7  (Win32)">
+	<META NAME="AUTHOR" CONTENT="Lutz H&ouml;ger">
+	<META NAME="CREATED" CONTENT="20030730;18520000">
+	<META NAME="CHANGEDBY" CONTENT="J&ouml;rg Heilig">
+	<META NAME="CHANGED" CONTENT="20030808;11075370">
+	<!--
+		@page { size: 21cm 29.7cm; margin: 2cm }
+		P { margin-bottom: 0.21cm }
+		P.western { font-size: 12pt; so-language: en-US }
+		H1 { margin-top: 0.62cm; margin-bottom: 0.41cm; page-break-before: always }
+		H1.western { font-family: "Albany", sans-serif; font-size: 16pt; so-language: en-US }
+		H1.cjk { font-size: 16pt }
+		H1.ctl { font-size: 16pt }
+		H2 { margin-top: 0.82cm; margin-bottom: 0.21cm }
+		H2.western { font-family: "Albany", sans-serif; font-size: 14pt; so-language: en-US; font-style: normal }
+		H2.cjk { font-family: "HG Mincho Light J"; font-size: 14pt; font-style: italic }
+		H2.ctl { font-family: "Arial Unicode MS"; font-size: 14pt; font-style: italic }
+		H3 { margin-bottom: 0.21cm }
+		H3.western { font-family: "Albany", sans-serif; font-size: 12pt; so-language: en-US }
+		H3.cjk { font-family: "HG Mincho Light J" }
+		H3.ctl { font-family: "Arial Unicode MS" }
+		H4 { margin-bottom: 0.21cm }
+		H4.western { font-family: "Albany", sans-serif; so-language: en-US; font-style: normal }
+		H4.cjk { font-family: "HG Mincho Light J"; font-size: 11pt; font-style: italic }
+		H4.ctl { font-family: "Arial Unicode MS"; font-size: 11pt; font-style: italic }
+		P.sdfootnote-western { margin-left: 0.5cm; text-indent: -0.5cm; margin-bottom: 0cm; font-size: 10pt; so-language: en-US }
+		P.sdfootnote-cjk { margin-left: 0.5cm; text-indent: -0.5cm; margin-bottom: 0cm; font-size: 10pt }
+		P.sdfootnote-ctl { margin-left: 0.5cm; text-indent: -0.5cm; margin-bottom: 0cm; font-size: 10pt }
+		A.sdfootnoteanc { font-size: 57% }
+	-->
+	</STYLE>
+<P LANG="en-US" ALIGN=LEFT STYLE="margin-top: 0.42cm; page-break-after: avoid">
+<SDFIELD TYPE=DOCINFO SUBTYPE=TITLE>StarOffice / &ldquo;Q&rdquo; Product Concept</SDFIELD></P>
+<P LANG="en-US" CLASS="western">Lutz Hoeger,  August 2003</P>
+<DIV ID="Table of Contents1" DIR="LTR" STYLE="background: transparent">
+	<DIV ID="Table of Contents1_Head" DIR="LTR">
+		<P LANG="en-US" STYLE="margin-top: 0.42cm; font-weight: medium; page-break-before: auto; page-break-after: avoid">
+		<FONT FACE="Albany, sans-serif"><FONT SIZE=4 STYLE="font-size: 16pt">Table
+		of Contents</FONT></FONT></P>
+	</DIV>
+	<P LANG="en-US" STYLE="margin-bottom: 0cm"><FONT SIZE=3><A HREF="#1.Introduction|outline">1
+	Introduction</A>	2</FONT></P>
+	<P LANG="en-US" STYLE="margin-bottom: 0cm"><FONT SIZE=3><A HREF="#2.Executive Summary|outline">2
+	Executive Summary</A>	3</FONT></P>
+	<P LANG="en-US" STYLE="margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.Concept Overview|outline">3
+	Concept Overview</A>	4</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 0.5cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.1.Key Drivers (P2)|outline">3.1
+	Key Drivers (P2)</A>	4</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.1.1.Microsoft Office Interoperability|outline">3.1.1
+	Microsoft Office Interoperability</A>	4</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.1.2.Usability|outline">3.1.2
+	Usability</A>	4</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.1.3.Performance|outline">3.1.3
+	Performance</A>	5</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.1.4.Programmability|outline">3.1.4
+	Programmability</A>	5</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.1.5.Integration into Gnome Desktop and Microsoft Windows|outline">3.1.5
+	Integration into Gnome Desktop and Microsoft Windows</A>	5</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 0.5cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.2.General Improvements (P3)|outline">3.2
+	General Improvements (P3)</A>	5</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.2.1.Stability and Quality|outline">3.2.1
+	Stability and Quality</A>	5</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.2.2.Administration and Deployment|outline">3.2.2
+	Administration and Deployment</A>	6</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.2.3.Modern Look &amp; Feel|outline">3.2.3
+	Modern Look &amp; Feel</A>	6</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.2.4.Integration (Plugins, 3rd party applications)|outline">3.2.4
+	Integration (Plugins, 3rd party applications)</A>	6</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 0.5cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.3.Upcoming Opportunities (P4 and P5)|outline">3.3
+	Upcoming Opportunities (P4 and P5)</A>	7</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.3.1.Asian and CTL languages|outline">3.3.1
+	Asian and CTL languages</A>	7</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.3.2.Digital Signatures|outline">3.3.2
+	Digital Signatures</A>	7</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.3.3.Compelling upgrade features (e.g. multi media, OCR, DB)|outline">3.3.3
+	Compelling upgrade features (e.g. multi media, OCR, DB)</A>	8</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.3.4.Intelligent Document Tags |outline">3.3.4
+	Intelligent Document Tags </A>	8</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.3.5.Collaboration|outline">3.3.5
+	Collaboration</A>	8</FONT></P>
+	<P LANG="en-US" STYLE="margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.Concept Details|outline">4
+	Concept Details</A>	9</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 0.5cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.1.Key Drivers|outline">4.1
+	Key Drivers</A>	9</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.1.1.Improving Microsoft Office Interoperability|outline">4.1.1
+	Improving Microsoft Office Interoperability</A>	9</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.1.2.Usability|outline">4.1.2
+	Usability</A>	14</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.1.3.Performance|outline">4.1.3
+	Performance</A>	17</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.1.4.Programmability|outline">4.1.4
+	Programmability</A>	18</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.1.5.Integration into the Gnome Desktop, and Microsoft Windows|outline">4.1.5
+	Integration into the Gnome Desktop, and Microsoft Windows</A>	20</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 0.5cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.2.General Improvements|outline">4.2
+	General Improvements</A>	22</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.2.1.Stability and Quality|outline">4.2.1
+	Stability and Quality</A>	22</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.2.2.Administration and Deployment|outline">4.2.2
+	Administration and Deployment</A>	22</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.2.3.Modern Look &amp; Feel|outline">4.2.3
+	Modern Look &amp; Feel</A>	23</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.2.4.Integration (Plug-ins, 3rd party applications)|outline">4.2.4
+	Integration (Plug-ins, 3rd party applications)</A>	25</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 0.5cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.3.Upcoming Opportunities|outline">4.3
+	Upcoming Opportunities</A>	27</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.3.1.Asian and CTL languages|outline">4.3.1
+	Asian and CTL languages</A>	27</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.3.2.Digital Signatures|outline">4.3.2
+	Digital Signatures</A>	29</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.3.3.Compelling upgrade features (e.g. multi media, OCR, DB)|outline">4.3.3
+	Compelling upgrade features (e.g. multi media, OCR, DB)</A>	30</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.3.4.Web Services|outline">4.3.4
+	Web Services</A>	30</FONT></P>
+	<P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.3.5.Intelligent Document Tags |outline">4.3.5
+	Intelligent Document Tags </A>	31</FONT></P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<H1 LANG="en-US" CLASS="western"><A NAME="1.Introduction|outline"></A>
+1 Introduction</H1>
+<P LANG="en-US" CLASS="western">(Lutz Hoeger, July 2003)</P>
+<P LANG="en-US" CLASS="western">This document provides a
+comprehensive, high-level overview of concepts for features in the
+next release of StarOffice / (SO/OOo) currently in the
+planning phase.</P>
+<P LANG="en-US" CLASS="western">The specification for such a large
+project covers many areas and many details.  Consequently, it will
+not provide a complete list of all the details, but occasionally will
+include some details to aid in clarifying the discussion. Many more
+details have already been and will soon be submitted as feature
+issues in IssueZilla, completing the picture.</P>
+<P LANG="en-US" CLASS="western">In compiling this document, we've
+gathered feedback from users, developers and existing or potential
+customers: in direct communication at trade shows like Linux World,
+during events like the Conference, using surveys, and
+last but not least in discussions on the mailing
+lists. We then put together ideas to respond to these requirements,
+prioritized them, and finally assembled it all into the Product
+<P LANG="en-US" CLASS="western">During the prioritization for this
+release, we had to strike a balance between the importance of each
+requirement and the goal of an 18-month cycle for releases. We've
+learned from discussion, particularly with enterprise customers, that
+this is their expected &ldquo;heartbeat&rdquo; for major releases of
+an office productivity suite.</P>
+<P LANG="en-US" CLASS="western">The structure of this document
+provides different levels of detail  about the concept:</P>
+	<LI><P LANG="en-US" CLASS="western">The Executive Summary (0.5
+	pages) is ideal for a &ldquo;Got-only-5-minutes-hurry-up!&rdquo;
+	reader who wants to know what the overall direction is. It's a brief
+	description of our answers to the highest priority requirements.
+	This section contains neither any details  nor a full list of areas
+	we plan to work on. 
+	</P>
+	<LI><P LANG="en-US" CLASS="western">The Concept Overview section
+	(five pages) explains the prioritization and discusses all
+	requirement areas.  This section should provide a good &ldquo;30-minute&rdquo;
+	overview of the responses to the requirements.  While leaving out
+	many of the details, it covers all the areas.</P>
+	<LI><P LANG="en-US" CLASS="western">And finally, the Detailed
+	Concept section (about 20 pages) completes the previous section with
+	a much more detailed view into all aspects of the requirements, with
+	some background information if available, and even illustrates parts
+	of the concept by drilling down on some details.</P>
+<P LANG="en-US" CLASS="western">Before beginning, let me introduce
+one convention used throughout this document. Code name &ldquo;Geordi&rdquo;
+stands for SO/OOo 1.1, and &ldquo;Q&rdquo; for the next major release
+after 1.1.</P>
+<P LANG="en-US" CLASS="western">And one final note, you'll find the
+document chapters tagged with different author names reflecting that
+many people contributed to this document.  We all would be happy to
+get your feedback.  So if you want to tell us something we could have
+done better, we may have forgotten or just want to ask a question,
+please refer in your comments to the section on which you are
+commenting.  This will help us identify the person who can best
+respond to  your feedback.</P>
+<H1 LANG="en-US" CLASS="western"><A NAME="2.Executive%20Summary|outline"></A>
+2 Executive Summary</H1>
+<P LANG="en-US" CLASS="western">(Lutz Hoeger, July 2003)</P>
+<P LANG="en-US" CLASS="western">&ldquo;Q&rdquo; will be the next
+major release of StarOffice / (SO/OOo).  Listed below
+are the concepts to address the key requirements of our existing and
+potential customers. These CTQs (Critical to Quality) are all
+centered around the main theme:  migration to &ldquo;Q&rdquo;.</P>
+	<LI><P LANG="en-US" CLASS="western">Lower cost of interoperability
+	with Microsoft Office.  By providing better interoperability with
+	Microsoft Office, &ldquo;Q&rdquo; will significantly decrease the
+	cost of conversion between the two applications.</P>
+	<LI><P LANG="en-US" CLASS="western">Lower cost of retraining<BR>&ldquo;Q&rdquo;
+	will lower the training needs for average users by enhancing feature
+	areas toward better standards of interaction.  This will make the
+	migration to SO/OOo cheaper.</P>
+	<LI><P LANG="en-US" CLASS="western">Better Performance<BR>&ldquo;Q&rdquo;
+	will come with noticeable improvements in startup performance as
+	well as time to open or save a document.</P>
+	<LI><P LANG="en-US" CLASS="western">General usability
+	improvements<BR>Redesigning parts of &ldquo;Q&rdquo; to increase
+	usability will increase productivity of the average user and the
+	overall level of satisfaction when working with the product.</P>
+	<LI><P LANG="en-US" CLASS="western">Enhanced programmability<BR>&ldquo;Q&rdquo;
+	will make it easier to automate typical office suite tasks. By
+	improved extensibility, &ldquo;Q&rdquo; will be better customizable
+	to individual customer's needs.</P>
+	<LI><P LANG="en-US" CLASS="western">Better integration into desktop
+	systems<BR>Particularly on Gnome desktop systems, &ldquo;Q&rdquo;
+	will integrate better with the existing infrastructure. This leads
+	to a more intuitive use of &ldquo;Q&rdquo; for users who are already
+	familiar with the desktop system, and provides better
+	interoperability between SO/OOo and other desktop applications.</P>
+<H1 LANG="en-US" CLASS="western"><A NAME="3.Concept%20Overview|outline"></A>
+3 Concept Overview</H1>
+<P LANG="en-US" CLASS="western">This section explains the
+prioritization and provides a general overview about all concept
+areas. More details are given in section 4, Concept Details.</P>
+<P LANG="en-US" CLASS="western">The priorities used in this concept
+have been set according to the general guidelines of priorities from
+different bug tracking systems, including IssueZilla. Although the
+<SPAN LANG="en-US"><FONT SIZE=3>latter</FONT></SPAN> doesn't
+specifically exclude feature issues from having priority 1, a P1
+issue normally means that an area is broken and cannot be worked
+with. Typically P1 is reserved for bugs only. That's why the scale
+for requirement priorities ranks from P2 (highest) to P5 (lowest). We
+assigned them in the following way.</P>
+<H2 LANG="en-US" CLASS="western"><A NAME="3.1.Key%20Drivers%20(P2)|outline"></A>
+3.1 Key Drivers (P2)</H2>
+<P LANG="en-US" CLASS="western">The overarching motto and strategy
+for this release is to lower the barrier for customers to migrate to
+StarOffice/ (SO/OOo). Our concept addresses this at
+various levels, in different areas of the product. The following
+areas describe the key drivers for &ldquo;Q&rdquo; - the areas that
+we hear about most in our customer research. These are the areas with
+highest priority and also often the highest effort in development
+<H3 LANG="en-US" CLASS="western"><A NAME="3.1.1.Microsoft%20Office%20Interoperability|outline"></A>
+3.1.1 Microsoft Office Interoperability</H3>
+<P LANG="en-US" CLASS="western">(Dieter Loeschky, April 2003)</P>
+<P LANG="en-US" CLASS="western">Interoperability between Microsoft
+Office and SO/OOo is generally influenced by three factors.  The
+first factor is the quality of the filter component, that is, the
+quality of the component that translates the content and structure of
+a Microsoft Office document into the content and structure of a
+SO/OOo document.  The second factor is the compatibility of the
+feature set of the application in Microsoft Office versus the
+corresponding SO/OOo application.  The third factor is the behavior
+or interpretation of features that exist in both applications.  Even
+if another application and SO/OOo both support a certain feature,
+there might be differences in the way the feature is actually
+applied, so that documents in fact might look different although they
+have exactly the same values stored for the feature within their text
+<P LANG="en-US" CLASS="western">One (already resolved) example of
+this is the upper paragraph margin that exists in Microsoft Word and
+SO/OOo Writer. The <SPAN LANG="en-US"><FONT SIZE=3>latter</FONT></SPAN>,
+like many DTP and professional word processing applications, ignores
+this value for the first paragraph of a page. Microsoft Word does
+not. The result of this is that the documents look different,
+although exactly the same values are stored in both text engines.</P>
+<H3 LANG="en-US" CLASS="western"><A NAME="3.1.2.Usability|outline"></A>
+3.1.2 Usability</H3>
+<P LANG="en-US" CLASS="western">(Matthias Mueller-Prove, May 2003)</P>
+<P LANG="en-US" CLASS="western">&ldquo;Q&rdquo; will change its
+overall appearance in order to improve the usability for the majority
+of non-SO/OOo customers. These changes affect the menu structure, the
+toolbar User Interface, the terminology, and finally the overall
+window layout. 
+<P LANG="en-US" CLASS="western">In general, usability is about task
+conformance, familiarity, predictability, flexibility, robustness,
+customizability, and learnability. Several minor usability
+improvements support the usability of SO/OOo in aspects of these
+usability qualities. All new features will be evaluated against these
+qualities by the Sun StarOffice User Experience Team.</P>
+<P LANG="en-US" CLASS="western">Task conformance pushes us to
+reconsider the necessary steps for an action and reduce the number of
+mouse clicks in &ldquo;Q&rdquo; as much as possible.  Predictability
+demands that we strive for a consistent user interface.  We will
+provide a conceptual model that is predictable and consistent for all
+SO/OOo applications instead of conforming with the majority of
+competing applications.  On the other hand, predictability calls for
+conformance with styleguides for the target platforms.</P>
+<H3 LANG="en-US" CLASS="western"><A NAME="3.1.3.Performance|outline"></A>
+3.1.3 Performance</H3>
+<P LANG="en-US" CLASS="western">(Matthias Huetsch, May 2003)</P>
+<P LANG="en-US" CLASS="western">SO/OOo will improve its performance
+in four areas that are especially important to customers.  The two
+most visible areas of improvement will be decreasing the Startup Time
+and Document Open/Save Time.  The third area of improvement will be
+Responsiveness in rendering more complex drawing objects as they, for
+example, occur in presentations. The fourth area is in the
+Scalability of large scale multi-user deployments like on Citrix,
+Tarantella, and SunRay servers. 
+<P LANG="en-US" CLASS="western">The performance improvements in the
+first three areas were identified as being mostly of an architectural
+nature.  Significant improvement in any of these areas can be
+achieved through either refactoring the current architecture, or
+replacing architecture.  The fourth area of scalability issues 
+originates in a number of areas that can be addressed individually.</P>
+<H3 LANG="en-US" CLASS="western"><A NAME="3.1.4.Programmability|outline"></A>
+3.1.4 Programmability</H3>
+<P LANG="en-US" CLASS="western">(Kay Ramme, May 2003)</P>
+<P LANG="en-US" CLASS="western">Programmability describes the
+possibility of usinge SO/OOo or parts of it in custom solutions
+programmatically. The underlying technology for SO/OOo
+programmability is the SO/OOo component model UNO (Universal Network
+Objects) and the SO/OOo API .   &ldquo;Q&rdquo; will make it easier
+on many levels to create solutions utilizing UNO and SO/OOo's API. 
+This will be achieved through improved language bindings, IDE
+integration, easier deployment of add-on components into a SO/OOo
+installation, and a new scripting framework that allows use of other
+languages in addition to BASIC for scripting purposes.</P>
+<H3 LANG="en-US" CLASS="western"><A NAME="3.1.5.Integration%20into%20Gnome%20Desktop%20and%20Microsoft%20Windows|outline"></A>
+3.1.5 Integration into Gnome Desktop and Microsoft Windows</H3>
+<P LANG="en-US" CLASS="western">(Christof Pintaske, June 2003)</P>
+<P LANG="en-US" CLASS="western">The overall requirement is to provide
+an easy to use desktop with an appealing and modern Look and Feel
+that is consistent throughout all applications.</P>
+<P LANG="en-US" CLASS="western">To achieve a better system
+integration, &quot;Q&quot; will make increased use of information and
+infrastructure that is provided with the Gnome desktop instead of
+creating platform independent solutions. 
+<P LANG="en-US" CLASS="western"><BR><BR>
+<H2 LANG="en-US" CLASS="western"><A NAME="3.2.General%20Improvements%20(P3)|outline"></A>
+3.2 General Improvements (P3)</H2>
+<P LANG="en-US" CLASS="western">The next areas are still mandatory
+requirements.  They fall under general improvements, that help
+facilitate a successful deployment of SO/OOo.</P>
+<H3 LANG="en-US" CLASS="western"><A NAME="3.2.1.Stability%20and%20Quality|outline"></A>
+3.2.1 Stability and Quality</H3>
+<P LANG="en-US" CLASS="western">(Matthias Huetsch, June 2003)</P>
+<P LANG="en-US" CLASS="western">&ldquo;Q&rdquo; improves stability
+and quality by  addressing the response to SO/OOo crashes with
+unsaved documents, which can  result in lost data. Currently, SO/OOo
+performs an emergency backup of those documents only. Upon next
+startup, a Document Recovery dialog then offers to restore those
+documents to a previously known good state.</P>
+<P LANG="en-US" CLASS="western">The probability of data loss due to a
+crash will be reduced by augmenting the current emergency backup with
+regular backup copies of documents.  The Document Recovery dialog
+will be improved by providing more guidance and feedback while
+restoring documents. An Error Report tool, available in the &ldquo;Geordi&rdquo;
+release, should provide data to help identify and eliminate crash
+<H3 LANG="en-US" CLASS="western"><A NAME="3.2.2.Administration%20and%20Deployment|outline"></A>
+3.2.2 Administration and Deployment</H3>
+<P LANG="en-US" CLASS="western">(Dirk Grobler, Christof Pintaske, May
+<P LANG="en-US" CLASS="western">With regard to deployment, &quot;Geordi&quot;
+offers a platform independent installation process, which can not
+easily be managed by any kind of management software.  Instead of
+adding additional management capabilities in this area, SO/OOo &quot;Q&quot;
+changes the installation process. The platform independent
+installation is replaced by the support for standard, platform
+dependent installation routines - so called native installers - and
+their native installation packages. These are the Solaris Package
+(pkg) installation, the Linux RPM package manager (RPM) installation,
+and the Microsoft Installer (MSI) installation.</P>
+<P LANG="en-US" CLASS="western">The advantage of this approach is to
+leverage already existing deployment technology based on those native
+formats. With &quot;Q&quot;, administrators will   be able to install
+&quot;Q&quot; with their existing tooling.</P>
+<H3 LANG="en-US" CLASS="western"><A NAME="3.2.3.Modern%20Look%20&amp;%20Feel|outline"></A>
+3.2.3 Modern Look &amp; Feel</H3>
+<P LANG="en-US" CLASS="western">(Christian Jansen, May 2003)</P>
+<P LANG="en-US" CLASS="western">Users are asking for various look and
+feel improvements, which fit mainly into three categories.</P>
+	<LI><P LANG="en-US" CLASS="western">The SO/OOo look and feel themes
+	should be more intuitive. 
+	</P>
+	<LI><P LANG="en-US" CLASS="western">The user interface should be
+	better organized and emphasize the important information.</P>
+	<LI><P LANG="en-US" CLASS="western">SO/OOo needs to provide more
+	user feedback and responses.</P>
+<P LANG="en-US" CLASS="western">For SO/OOo &quot;Q&quot; we will
+address these areas by improving the look &amp; feel and adjusting it
+to the expectations of the majority of non-SO/OOo users while
+balancing it with the expectations of current SO/OOo users.</P>
+<H3 LANG="en-US" CLASS="western"><A NAME="3.2.4.Integration%20(Plugins,%203rd%20party%20applications)|outline"></A>
+3.2.4 Integration (Plugins, 3rd party applications)</H3>
+<P LANG="en-US" CLASS="western">(Mathias Bauer, May 2003)</P>
+<P LANG="en-US" CLASS="western">Integrating SO/OOo with 3rd party
+applications can be done on several levels:</P>
+	<LI><P LANG="en-US" CLASS="western">Create import and export filters
+	to convert between the file formats.</P>
+	<LI><P LANG="en-US" CLASS="western">Use the system clipboard for
+	data exchange.</P>
+	<LI><P LANG="en-US" CLASS="western">Use external communication means
+	like pipes, files, command line parameters etc. to establish a work
+	flow that uses SO/OOo and other applications together.</P>
+	<LI><P LANG="en-US" CLASS="western">Link or embed data or files from
+	other applications in(to) SO/OOo documents and vice versa.</P>
+	<LI><P LANG="en-US" CLASS="western">Use the SO/OOo API or the API of
+	other applications to integrate on a functional level.</P>
+<P LANG="en-US" CLASS="western">The first two options are already
+widely used in SO/OOo. Adding support for more 3rd party applications
+simply means providing the necessary conversion routines and will not
+be discussed here in detail.</P>
+<P LANG="en-US" CLASS="western">External communication means are
+usually tailored for every single use case. Examples for this kind of
+integration are external e-mail clients. 
+<P LANG="en-US" CLASS="western">3rd party integration on an API level
+can be done in two ways:</P>
+	<LI><P LANG="en-US" CLASS="western">the 3rd party application uses
+	UNO to connect to SO/OOo and uses its APIs to get the wanted
+	functionality</P>
+	<LI><P LANG="en-US" CLASS="western">SO/OOo creates adapters to use
+	the middleware technology of the 3rd party application (like Com,
+	.NET or SOAP).</P>
+<P LANG="en-US" CLASS="western">This concept document concentrates on
+the first approach. The latter one is addressed by UNO bridges like
+the ones we have (or will develop) for OLE Automation, .NET or SOAP.</P>
+<H2 LANG="en-US" CLASS="western"><A NAME="3.3.Upcoming%20Opportunities%20(P4%20and%20P5)|outline"></A>
+3.3 Upcoming Opportunities (P4 and P5)</H2>
+<P LANG="en-US" CLASS="western">The final part of the concept
+contains optional enhancements in the area of upcoming opportunities
+that we can foresee today.</P>
+<H3 LANG="en-US" CLASS="western"><A NAME="3.3.1.Asian%20and%20CTL%20languages|outline"></A>
+3.3.1 Asian and CTL languages</H3>
+<P LANG="en-US" CLASS="western">(Falko Tesch, July 2003)</P>
+<P LANG="en-US" CLASS="western">Internationalization (I18N) describes
+the ability and availability of a product for international markets.
+This means that the product has to comply with 3 important issues:</P>
+	<LI><P LANG="en-US" CLASS="western">It needs to address locale
+	specific features and customs.</P>
+	<LI><P LANG="en-US" CLASS="western">It needs a good and
+	comprehensive documentation and UI.</P>
+	<LI><P LANG="en-US" CLASS="western">It needs localized tools and
+	support for local utensils and tools, such as IME (input method
+	engine) and the like.</P>
+<P LANG="en-US" CLASS="western">StarSuite 6.0 and &quot;Geordi&quot;
+support IME that enables the input of East-Asian scripting like
+Chinese, Korean and Japanese. Furthermore &quot;Geordi&quot; pays
+tribute to the most needed features for text processing in Asia, like
+vertical text layout, Ruby support, specific font effects and other.
+While &quot;Geordi&quot; covers features and needs for CJK markets,
+it takes only the first steps towards a specialized offer to the CTL
+(complex text layout) markets (Arabic, Hebrew, Thai, Hindi etc.). &ldquo;Q&rdquo;
+will complete the CJK (Chinese, Japanese, Korean) feature set and
+complete CTL features started with &quot;Geordi&quot;:</P>
+	<LI><P LANG="en-US" CLASS="western">Refining already existing CJK
+	features and adding competitive features to fully compete with other
+	office productivity suites for CJK, like local office software, such
+	as Hangul (Korea), Ichitaro (Japan) and WPS Office (PR China).</P>
+	<LI><P LANG="en-US" CLASS="western">Introducing full localized CTL
+	support for Arabic and Hebrew-spoken countries as well as for India
+	(Hindi plus 6 other major languages spoken)</P>
+<P LANG="en-US" CLASS="western">With &ldquo;Geordi&rdquo;, SO/OOo
+demonstrates it's suitability for the CTL markets (e.g. Arabic and
+Hebrew regions)</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<H3 LANG="en-US" CLASS="western"><A NAME="3.3.2.Digital%20Signatures|outline"></A>
+3.3.2 Digital Signatures</H3>
+<P LANG="en-US" CLASS="western">(Michael Brauer, May 2003)</P>
+<P LANG="en-US" CLASS="western">Security for office document content
+can be divided into two features, digital signatures and encryption. 
+<P LANG="en-US" CLASS="western">Digital signatures themselves are a
+relatively new topic for office applications. The requirement to
+protect data from being modified has existed for many years ,
+however.  In the past, it has been addressed by features that
+protected documents from being edited within the office application.
+With digital signatures, these features will be enhanced to offer
+secure protection of document content, inside SO/OOo, and outside of
+<H3 LANG="en-US" CLASS="western"><A NAME="3.3.3.Compelling%20upgrade%20features%20(e.g.%20multi%20media,%20OCR,%20DB)|outline"></A>
+3.3.3 Compelling upgrade features (e.g. multi media, OCR, DB)</H3>
+<P LANG="en-US" CLASS="western">Encryption is a feature that has been
+supported by office applications for a long time.  Enhancement in
+this area mainly affected the encryption algorithm themselves, to
+make them more secure. However, since there was no standardized way
+in which encryption algorithms are applied to documents, processing
+such documents outside an office application was complex.  By
+supporting new XML encryption standards, and due to SO/OOo's XML file
+format, this will become much easier.</P>
+<P LANG="en-US" CLASS="western">Although the requirements cover many
+improvements and new features for SO/OOo, this section is reserved
+for features that make the upgrade particularly compelling for
+existing SO/OOo customers. Since we don't know of any specific
+customer requirements that fit exclusively into this section, it's
+content will be determined later.Web Services</P>
+<P LANG="en-US" CLASS="western">(Kai Sommerfeld, May 2003)</P>
+<P LANG="en-US" CLASS="western">Web Services become more and more
+important as they easily can be used to establish B2B communication
+in a platform independent way. There are lots of Web Services
+available that offer a broad range of functionality, for example
+Google offers a Web Service for searching the Internet.</P>
+<P LANG="en-US" CLASS="western">It would be valuable, if SO/OOo could
+act as a Web Services client, meaning that it could access and use
+arbitrary Web Services.</P>
+<P LANG="en-US" CLASS="western">Additionally it could be interesting
+to offer SO/OOo's functionality as Web Services. An example for such
+a Web Service is a document transformation service, which would be
+based on SO/OOo's document import and export.</P>
+<H3 LANG="en-US" CLASS="western"><A NAME="3.3.4.Intelligent%20Document%20Tags%20|outline"></A>
+3.3.4 Intelligent Document Tags 
+<P LANG="en-US" CLASS="western">(Andreas Martens, May 2003)</P>
+<P LANG="en-US" CLASS="western">SO/OOo will support an interface for
+intelligent and extensible document tags. This interface will allow
+third party vendors to offer additional information/services on the
+basis of textual analysis. This is a win-win situation. SO/OOo gets a
+feature without the effort of reinventing the wheel. For third party
+vendors it creates a business opportunity around SO/OOo.</P>
+<P LANG="en-US" CLASS="western">Initially, all words/phrases which
+are recognized as keywords will be underlined. The user is able to
+open context menus for these marked words and to choose additional
+<P LANG="en-US" CLASS="western">Example: A vendor offers a component
+with different dictionaries (technical, juristic, medicinal). The
+SO/OOo document will be scanned for entries in these dictionaries.
+For marked words the context menu contains the names of the
+dictionaries where the word has been found. The user chooses a
+dictionary and the component displays the complete entry.</P>
+<P LANG="en-US" CLASS="western">Example: The supporting component is
+based on a customer list. If the name of a customer is present in a
+SO/OOo document it will be underlined. The context menu may offer
+actions like  &ldquo;address&rdquo;, &ldquo;send email&rdquo;, &ldquo;show
+business volumes&rdquo;, &ldquo;show last order&rdquo; et cetera. The
+chosen information will be displayed or another program like an email
+client will be started. 
+<H3 LANG="en-US" CLASS="western"><A NAME="3.3.5.Collaboration|outline"></A>
+3.3.5 Collaboration</H3>
+<P LANG="en-US" CLASS="western">To be completed later</P>
+<H1 LANG="en-US" CLASS="western"><A NAME="4.Concept%20Details|outline"></A>
+4 Concept Details</H1>
+<P LANG="en-US" CLASS="western">This section contains details about
+the product concept. 
+<H2 LANG="en-US" CLASS="western"><A NAME="4.1.Key%20Drivers|outline"></A>
+4.1 Key Drivers</H2>
+<H3 LANG="en-US" CLASS="western"><A NAME="4.1.1.Improving%20Microsoft%20Office%20Interoperability|outline"></A>
+4.1.1 Improving Microsoft Office Interoperability</H3>
+<P LANG="en-US" CLASS="western">(Dieter Loeschky, April 2003)</P>
+<P LANG="en-US" CLASS="western">In the past, interoperability between
+Microsoft Office and SO/OOo was improved by completing the import and
+export filters.  In &quot;Geordi&quot; interoperability between
+Microsoft Office and SO/OOo was improved by also adding features to
+SO/OOo and by changing SO/OOo's behavior and interpretation of single
+<P LANG="en-US" CLASS="western">For &ldquo;Q&rdquo;, interoperability
+will be improved in a very large scale by continuing to add features
+to SO/OOo.  Changes in the filters are of course still required to
+support the new features or changed behavior.</P>
+<P LANG="en-US" CLASS="western">The movement of effort from the
+filter development into the application development is in fact a very
+natural process. At a certain stage, interoperability of a certain
+feature cannot be improved by the filter any longer, because it
+already converts all data that is supported from one application to
+the other. At this point, if the feature still behaves differently,
+the SO/OOo  application itself may be enhanced.</P>
+<H4 LANG="en-US" CLASS="western"> SO/OOo Writer</H4>
+<P LANG="en-US" CLASS="western">For SO/OOo Writer, there are four
+main areas in which interoperability with Microsoft Office will be
+improved:  tables, drawing objects, numberings/bullets and spacing.
+The improvements in these main areas will be completed by many other
+small enhancements in other areas that also raise interoperability
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Tables</P>
+<P LANG="en-US" CLASS="western">The most important improvement will
+be the support of automatic page breaks within cells. Currently, this
+can cause significant differences in layout of the same document
+between a non-SO/OOo application and SO/OOo Writer if the document
+contains tables that do not fit on a single page. Two other important
+improvements will be the support of tables within tables and of
+tables where text flows around them. Table interoperability will be
+completed by a border model that provides better interoperability
+with other applications, including Microsoft Word.  Interoperability 
+improvements mentioned above are considered to be a much higher
+priority than those that can be achieved by introducing a different
+table model.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Drawing objects</P>
+<P LANG="en-US" CLASS="western">A second very important area where
+interoperability will be improved is in SO/OOo drawing objects. The
+most important improvement will be supporting other applications'
+drawing objects within page headers and footers. In addition to this,
+missing alignment, anchoring and position modes will be added.
+Finally, there will be a unification of drawing objects and SO/OOo
+Writer's so called fly frames, i.e. graphic, text box and OLE
+objects. Many options that are available for frames will be made
+available to drawing objects as well and vice versa. The user
+interface of both kind of objects will also be unified.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Numbering and bullets</P>
+<P LANG="en-US" CLASS="western">Interoperability of numberings and
+bullets, the third main area mentioned above, will also be addressed
+by many small enhancements. Negative indents will be supported and it
+will be possible to change the indent values for every paragraph
+individually. Tabulators will be supported within numbers. Last but
+not least, the the calculation of chapter numbers and table of
+contents will be enhanced.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Spacing</P>
+<P LANG="en-US" CLASS="western">The fourth important area for
+improvement can be summarized by the word &ldquo;spacing.&rdquo;
+Although the differences are very small (typically less than half a
+point) and will hardly be noticed by the user, the end result might
+be that an imported page contains two lines less of text on a SO/OOo
+Writer page. This again can result in images and text boxes appearing
+on different pages, and the document may look completely different in
+SO/OOo Writer.</P>
+<H4 LANG="en-US" CLASS="western"> SO/OOo Calc</H4>
+<P LANG="en-US" CLASS="western">Most interoperability problems
+between Microsoft Excel and SO/OOo Calc that exist today result from
+an incompatible feature set.  The biggest advance in interoperability
+can be achieved by adding new and changing existing features in Calc
+to achieve better compatibility.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Breaking the row limit</P>
+<P LANG="en-US" CLASS="western">Currently, 32,000 is the maximum
+number of rows in a Calc spreadsheet.  Cell content beyond row 32,000
+is lost when a file with more rows is imported into SO/OOo. If more
+than 32,000 rows are needed for a specific spreadsheet, there's no
+easy way to get equivalent results using only SO/OOo's 32,000 rows.
+It is therefore important to adjust our row limit. The number of rows
+in a spreadsheet will be increased to 65,536, with provisions to make
+it relatively easy to further increase that number in later versions.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Calculation</P>
+<P LANG="en-US" CLASS="western">The second important issue is
+calculation. Although the set of formula functions is very similar
+across most spreadsheet applications, some special-case features of
+calculation with these functions are not yet supported in SO/OOo.
+Currently, when documents that use these additional features are
+loaded in SO/OOo, the formula cells will show error values or even
+different results from those in the original document.  To get the
+same results as in the original, the spreadsheets would have to be
+changed manually.  Especially in the case of array formulas, these
+required changes would be quite extensive, making it difficult to
+create an equivalent calculation in SO/OOo.  We have identified a set
+of features that cause problems.They will be addressed in <SPAN LANG="en-US"><FONT SIZE=3>&quot;Q&quot;</FONT></SPAN>.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Form controls</P>
+<P LANG="en-US" CLASS="western">Another important feature that will
+be added to SO/OOo is the ability to create form controls (list
+boxes, check boxes, etc.) that are connected to spreadsheet cells.
+These controls get their values from the cells, and update the cells
+if something is selected. With the increased flexibility that will be
+needed to support the form layer's own new features, we will be able
+to also implement this connection to spreadsheet cells.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Cell attributes</P>
+<P LANG="en-US" CLASS="western">SO/OOo supports slightly different
+cell attributes than competing applications.  This leads to
+differences in the appearance or behavior of imported documents that
+contain these attributes.  We will add corresponding features to
+SO/OOo to eliminate the differences in imported documents.  We will
+extend the validation feature, annotations, scenarios, ranges and
+hyperlinks, as well as some cell formatting attributes. 
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">DataPilot</P>
+<P LANG="en-US" CLASS="western">Currently, basic functionality and
+interoperability is available in SO/OOo's DataPilot.  In <SPAN LANG="en-US"><FONT SIZE=3>&quot;Q&quot;</FONT></SPAN>,
+we will extend the DataPilot to the state-of-the-art feature set for
+reports based on spreadsheet cell data. The most important of these
+features are page fields, settings for fields and individual
+elements, and the table formatting options.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Sorting</P>
+<P LANG="en-US" CLASS="western">Finally, it's common amongst the
+competing applications to preserve as much of the original sorting
+order as possible, when sorting a spreadsheet according by some sort
+keys. In SO/OOo they end up in a random order. We can change the
+implementation of sorting so that the original order is preserved
+where sorting criteria are equal.</P>
+<H4 LANG="en-US" CLASS="western"> SO/OOo Impress</H4>
+<P LANG="en-US" CLASS="western">&quot;Geordi&quot; improved
+interoperability with Microsoft PowerPoint in many aspects.  To
+further improve interoperability completely new features need to be
+added to the application and the drawing layer.</P>
+<P LANG="en-US" CLASS="western">Build effects</P>
+<P LANG="en-US" CLASS="western">The current animation system of
+SO/OOo Impress supports one effect per shape with all effect types
+individually implemented. Execution of all effects is either
+automatic or manually per slide. Users request to have an equivalent
+set of effects and to preserve the order of execution of effects when
+exchanging presentations between SO/OOo Impress and non-SO/OOo
+<P LANG="en-US" CLASS="western">Instead of manually implementing
+every new shape effect, it is necessary to support an animation core
+that is flexible to handle new effects that may be added later. The
+first step is to add a core component that can fully load and store
+non-SO/OOo effects for improved interoperability.  Due to the higher
+demands for hardware supported rendering this first step will not be
+visually equal on all effects. Also playing the effects in real time
+will not be solved by this. 
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Timeline</P>
+<P LANG="en-US" CLASS="western">To support a timeline concept, there
+will be a timeline feature for SO/OOo Impress. With this timeline,
+interoperability is enhanced by preserving the order and timing by
+which the shape effects are executed. Users will be able to add more
+than one effect to each shape and to have effects that are partly
+automatic and partly triggered by mouse clicks. <BR>This will also
+include a user interface to change the new introduced timeline and
+effect features. &ldquo;Q&rdquo; will also provide a shortcut, for
+the user to select an animation theme for a slide, so that the slide
+and shape effects are automatically set to fit the theme.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Collaboration</P>
+<P LANG="en-US" CLASS="western">Interoperability with other
+presentation programs, including Microsoft PowerPoint, will be
+improved by adding means to use sticky note like comments in Impress.
+ Currently, upon import, SO/OOo Impress ignores this information. 
+This improvement will enhance interoperability by preserving document
+content and by giving SO/OOo Impress users who need to interoperate
+with other application users the ability to exchange comments on
+their work.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Header and Footers</P>
+<P LANG="en-US" CLASS="western">Sometimes headers and footers in
+Impress presentation slides get lost during a roundtrip from
+Microsoft PowerPoint to SO/OOo Impress.  The reason for this is the
+different way headers and footers are used in Microsoft PowerPoint
+and SO/OOo Impress.  The SO/OOo Impress method for using headers and
+footers is much more flexible than Microsoft PowerPoint's.</P>
+<P LANG="en-US" CLASS="western">To meet this requirement and to
+improve ease of use, SO/OOo Impress will provide easier access to
+it's header and footer feature. This will not only enhance
+interoperability by keeping header and footer information persistent,
+but will also provide the user with an easier interface to create
+them in SO/OOo Impress. There will also be an easy to use dialog to
+change the header and footer for the current page or for all pages.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Extended Drawing Shapes</P>
+<P LANG="en-US" CLASS="western">Often drawing shapes, such as 
+&ldquo;AutoShapes&rdquo; in Microsoft PowerPoint, can be found in
+competing presentation program applications.  They provide an easy
+way of adding drawings to presentations. Therefore a set of
+predefined shapes of different categories like 'block arrows', 'flow
+charts', 'stars and banners', 'callouts' and 'action buttons' can be
+<P LANG="en-US" CLASS="western">For example, in the current version
+of SO/OOo, imported  Microsoft Office documents that contain
+Autoshapes are mostly displayed correctly.  There does not exist,
+however, the ability to edit WordArt objects or to change 3D-objects.
+ Interchanging documents between SO/OOo and Microsoft Office leads to
+the loss of  functionality of these drawing objects.</P>
+<P LANG="en-US" CLASS="western">To meet this requirement, an
+implementation for extended drawing objects in SO/OOo will be
+designed, including new dialogs to edit imported WordArt objects and
+to change imported 3D objects. This will not only enhance
+interoperability through supporting all Microsoft Office AutoShapes,
+but make them fully editable and allow SO/OOo Impress users to create
+functionally equal drawing shapes themselves.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<H4 LANG="en-US" CLASS="western"> SO/OOo Base (Forms)</H4>
+<P LANG="en-US" CLASS="western">An evolving standard for data entry
+applications are W3C's XForms. XForm controls can be embedded into
+any XML based file format like XHTML, and they support data entry
+based on XML schemes. It is likely that XForms will replace at least
+HTML/HTTP forms in the mid term future. By adding XForms support to
+SO/OOo, it will not only keep up with recent development trends, but
+in combination with the OASIS OpenOffice XML file format it also
+becomes a powerful alternative to XHTML/XForms. What makes it
+interesting to use an OASIS OpenOffice XML and XForms based SO/OOo as
+a data entry client is that it offers much more layout capabilities
+than XHTML/XForms based clients, but uses exactly the same open
+protocols as XHTML/XForms based clients on the server side. Moreover,
+since SO/OOo is also a powerful tool to create forms, even form
+creation gets easier and does not require additional tools.</P>
+<P LANG="en-US" CLASS="western">While XForms are already an
+improvement for data entry applications, it is conceivable that data
+entry applications will improve further. In some of the recently
+developed applications, data entry is not limited to classical form
+controls, but arbitrary text or other content can by included into
+the form data. Additionally, some applications provide the ability to
+extend forms at run time. An example for this are meeting minutes,
+where an agenda item might be duplicated any times. These
+capabilities allow it to use data entry applications not only for
+static and simple forms, but also for such complex things like
+minutes, bills or letters. In any case, the actual form data will
+stay in an XML schema. These schema could be either a user defined
+one, or one that is standardized by organizations like OASIS. In the
+later category are the UBL schemes that are currently developed by an
+OASIS technical committee. 
+<P LANG="en-US" CLASS="western">In such scenarios, the user creates
+new documents based on existing document  templates. In the new
+document, data can be entered only at predefined locations, for
+instance within certain fields, controls or text boxes. Moreover only
+very few editing features will be enabled. For instance, text
+sections might be duplicated but not inserted at any location. This
+way, it can be ensured that the document always has a defined
+structure. This again allows it to bind every editable data to
+elements of an XML schema and therefor to submit them as XML form
+<P LANG="en-US" CLASS="western">SO/OOo capabilities for such form
+based work flows will be improved. The starting point is the XForm
+enhancements described above. Further steps will be the inclusion of
+for instance field or paragraph contents into XML form data and
+possibilities to enter data into them in Writer's read only mode. The
+capabilities to specify application behavior within templates will be
+improved. Finally, certain complex editing operations, like
+duplicating a section, will be allowed in Writer's read only mode as
+well. By adding data entry capabilities to SO/OOo step by step, more
+and more work flows can be implemented with SO/OOo. 
+<P LANG="en-US" CLASS="western">SO/OOo will also improve its
+interoperability with the form functionality of Microsoft Office, in
+particular of Microsoft Word. Microsoft Word features two completely
+different concepts for form functionality: form fields and form
+controls. Form fields are the more ancient concept and are not
+supported by &quot;Geordi&quot;, but are nevertheless frequently used
+by Microsoft Word users. SO/OOo will address this by implementing
+equivalents for these form fields.</P>
+<P LANG="en-US" CLASS="western">Form controls offer a functionality
+similar to form controls in SO/OOo applications. For &ldquo;Q&rdquo;,
+we will implement some new control types like scroll bars, toggle
+buttons, and a rich text control, and enhance existing control types
+with functionality currently not present, for example multi-columnar
+list boxes, and spell checking in text controls.</P>
+<H4 LANG="en-US" CLASS="western"> SO/OOo Chart</H4>
+<P LANG="en-US" CLASS="western">Additional functionality will be
+added to the Chart core.  This added functionality will ease Bug
+fixing and integration of new features.  
+<P LANG="en-US" CLASS="western">The most important feature that will
+be added will allow data series to get their input from individual
+cell-ranges for x-values, y-values, labels, etc. Without it, some
+imports from non-SO/OOo spreadsheets can only produce an empty
+output.  Technically, this requires new interfaces for the
+communication between SO/OOo Chart and either SO/OOo Calc or SO/OOo
+Writer.  Moreover, the source data concept within the SO/OOo Chart
+needs to be redesigned completely.</P>
+<P LANG="en-US" CLASS="western">Some new chart types have to be
+integrated too &ndash; especially bubble and surface charts. A bubble
+chart requires an additional input range for the bubble sizes. As
+this additional range does not fit into the current source data
+structure the new source data concept mentioned above is a
+prerequisite for offering a bubble chart  as well.</P>
+<P LANG="en-US" CLASS="western">Moreover, the integration of a new
+chart type into the old SO/OOo Chart core could jeopardize existing
+functionality, as chart type dependent code is spread over the whole
+project. To eliminate this fundamental problem a new SO/OOo Chart
+core will encapsulate chart type dependent code in separate UNO
+components with well defined interfaces.</P>
+<P LANG="en-US" CLASS="western">The re-implementation of the SO/OOo
+Chart core is a necessary, long-lasting task that has to be finished
+before any of the requested new features can be started. The
+re-implementation of the current functionality is expected to take at
+least until the end of the calendar year.</P>
+<P LANG="en-US" CLASS="western">The missing features for
+interoperability with competing applications include:</P>
+	<LI><P LANG="en-US" CLASS="western">Flexible source range selection
+	for different parts of data series (x-values, y-values, labels etc.)</P>
+	<LI><P LANG="en-US" CLASS="western">Flexible combination of
+	different chart types (mostly line &amp; bar)</P>
+	<LI><P LANG="en-US" CLASS="western">Free positioning of data point
+	labels (often requested for pie charts)</P>
+	<LI><P LANG="en-US" CLASS="western">Take format for data point
+	labels from corresponding SO/OOo Calc cell</P>
+	<LI><P LANG="en-US" CLASS="western">Pull out 3d pie segments (often
+	requested)</P>
+	<LI><P LANG="en-US" CLASS="western">Pseudo 3d look (this type of 3d
+	charts is often used in magazines)</P>
+	<LI><P LANG="en-US" CLASS="western">Bubble chart</P>
+	<LI><P LANG="en-US" CLASS="western">Surface chart</P>
+	<LI><P LANG="en-US" CLASS="western">More flexible legend (resizable,
+	removable entries)</P>
+	<LI><P LANG="en-US" CLASS="western">Arbitrary content for data point
+	labels</P>
+	<LI><P LANG="en-US" CLASS="western">X error bars</P>
+	<LI><P LANG="en-US" CLASS="western">Filled radar chart</P>
+	<LI><P LANG="en-US" CLASS="western">Pull out outermost segments of
+	2d donut charts</P>
+<P LANG="en-US" CLASS="western">The order of the items reflects a
+proposed prioritization. The highest priorities are given to those
+missing features that cause more information loss and are used more
+<H3 LANG="en-US" CLASS="western"><A NAME="4.1.2.Usability|outline"></A>
+4.1.2 Usability</H3>
+<P LANG="en-US" CLASS="western">(Matthias Mueller-Prove, May 2003)</P>
+<H4 LANG="en-US" CLASS="western"> Menu Structure</H4>
+<P LANG="en-US" CLASS="western">The redesign of the menu structure
+will take the general concepts of the competing applications into
+account. Two prominent examples of menu changes for &ldquo;Q&rdquo;
+are the organization of menu items of the View menu and a new Table
+menu for Writer.</P>
+<H4 LANG="en-US" CLASS="western"> Toolbars</H4>
+<P LANG="en-US" CLASS="western">The user interface of toolbars will
+be completely redesigned. &ldquo;Q&rdquo; provides for small toolbars
+that can be rearranged with drag'n'drop. The new design makes better
+use of the screen estate by using the space more efficiently. The
+dynamic exchange of toolbar content will be eliminated.</P>
+<H4 LANG="en-US" CLASS="western"> Terminology</H4>
+<P LANG="en-US" CLASS="western">The terminology used for the user
+interface for menus, prominent dialogs and alert messages will be
+revised in order to utilize the existing knowledge of office
+productivity users.</P>
+<H4 LANG="en-US" CLASS="western"> Window Layout</H4>
+<P LANG="en-US" CLASS="western">Impress will get a new window layout
+that introduces a tool pane for SO/OOo. The tool pane offers specific
+commands for presentations to make it more easy for the user to
+manage and edit slides, import styles and slides from other files and
+to run her presentation.</P>
+<H4 LANG="en-US" CLASS="western"> Application Separation</H4>
+<P LANG="en-US" CLASS="western">For the user, &ldquo;Q&rdquo; will
+also look more like separate applications. The Microsoft Windows
+Start menu / Linux desktop panel, SO/OOo's &ldquo;File&rdquo;  and
+&ldquo;Window&rdquo; menu, document window titles, and the options
+dialog will reflect this change. 
+<P LANG="en-US" CLASS="western">Along with this new concept we will
+eliminate obsolete settings from the options dialog and make clear
+which settings have effects in which part of the application.</P>
+<H4 LANG="en-US" CLASS="western"> General Interaction</H4>
+<P LANG="en-US" CLASS="western">The interaction model for text,
+tables and images in Writer and for objects and layers in Draw and
+Impress will implement state-of-the-art selection techniques.</P>
+<P LANG="en-US" CLASS="western">For &ldquo;Q&rdquo; we will revise
+the interaction concepts for compound tasks like mail merge and
+creating charts.</P>
+<P LANG="en-US" CLASS="western">Finally, the enhanced Undo
+functionality will significantly improve robustness of the product. 
+<H4 LANG="en-US" CLASS="western"> Usability of the Database
+<P LANG="en-US" CLASS="western">(Frank Schoenheit, May 2003)</P>
+<P LANG="en-US" CLASS="western">Currently, the database access (DBA)
+functionality in SO/OOo exposes various differences from other
+database applications.  Those differences can be assigned to two
+groups:  usability and interoperability.  These issues are
+predominant with users who are not able to locate the functionality
+they need (though often it is present).  They then do not feel
+comfortable with SO/OOo's user interface which follows a different
+philosophy in this area.</P>
+<P LANG="en-US" CLASS="western">Additionally, having a competitive
+database application, instead of a set of database access components,
+clearly is an important feature for potential users and customers.</P>
+<P LANG="en-US" CLASS="western">We will address this with a redesign
+of SO/OOo's database application.  In the first instance, this will
+lead to it being recognized as a state-of-the-art end user oriented
+database application, and make former users of other database
+products, like Microsoft Access, feel more comfortable.  In the
+second instance, it will address most of the problems customers have
+with the current user interface.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">A New Database Application</P>
+<P LANG="en-US" CLASS="western">SO/OOo DBA (with a new name which is
+to be discussed) will be an own application, instead of hiding within
+Writer, Calc and Impress documents. This will be perceived as a
+competitive database application then, which will be equal to the
+other major applications in SO/OOo.</P>
+<P LANG="en-US" CLASS="western">This new application will be
+accessible from the main menu &ndash; File|New  is where users expect
+to create a new database, so we will add a Database item, which opens
+the application and offers the user a reasonable set of choices how
+to proceed (e.g. create a dBase data source,  connect to an existing
+foreign database via an auto pilot).</P>
+<P LANG="en-US" CLASS="western">We will not abandon the concept of
+data sources.  This is not only for reasons of feasibility (a
+database engine is a very heavy-weight project), but also for reasons
+of openness: We continue SO/OOo's philosophy to allow the user to
+work with whatever database is already present in her work
+environment, from client-side single-user file-based databases up to
+server-side databases participating in a corporate work flow.</P>
+<P LANG="en-US" CLASS="western">The layout and user interface of this
+new application will, at the first glance, be recognized as
+relatively similar to what typical database application users already
+know. Where it makes sense, the application will provide a look&amp;feel,
+including functional concepts, that are intuitive.</P>
+<P LANG="en-US" CLASS="western">As a consequence of this new database
+access application, we will give it its own top-level topic in
+SO/OOo's help system.  This will increase the user's ability to find
+help with database topics.</P>
+<P LANG="en-US" CLASS="western">The functionality of the current Data
+Source Administration dialog, and large parts of the functionality of
+the current data source browser, will be merged in the new
+application, providing one single entry point for database
+functionality in SO/OOo.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Data Sources</P>
+<P LANG="en-US" CLASS="western">We will re-implement the user
+interface of SO/OOo DBA. We will move away from the current
+technician-oriented user interface to a more end-user oriented work
+flow and terminology.</P>
+<P LANG="en-US" CLASS="western">In addition, several measures will be
+taken to make the &ldquo;data source&rdquo; concept feel more like
+the &ldquo;database&rdquo; concept the user is used to from other
+office suites. Though the underlying core concepts will not be
+changed, SO/OOo users then will have less problems when migrating
+from other database applications.</P>
+<P LANG="en-US" CLASS="western">We will change the way that data
+sources in SO/OOo are administrated &ndash; we will put more focus on
+meeting the user in her own vocabulary of concepts, by creating a
+more intuitive user interface, and by exposing most of the technical
+details to advanced users only.</P>
+<P LANG="en-US" CLASS="western">An auto pilot will be created which
+allows the import/export of data sources (file based), and thus
+migrate them between installations.  This will not only unburden the
+user from the manual work which is currently required for this, but
+also support the impression of a &ldquo;database&rdquo; in opposite
+to a &ldquo;data source&rdquo; which the user cannot really control.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Form Documents</P>
+<P LANG="en-US" CLASS="western">Form Documents provide a highly
+customizable view to database data, thus they are the user's primary
+choice when working with such data.</P>
+<P LANG="en-US" CLASS="western">The main improvement desired by
+SO/OOo users in the area of form functionality is usability. Thus, we
+will make changes to SO/OOo affecting the user interface in several
+ways. The user will recognize SO/OOo data-aware forms (which covers
+form design as well as form usage) as a dedicated solution, in
+opposite to the current situation, where form functionality is
+recognized as a small and hidden add-on to SO/OOo text documents.</P>
+<P LANG="en-US" CLASS="western">This list ranges from small and
+rather cosmetic changes which will sum up to a much better user
+experience, to larger projects such as a dedicated simple mode for
+the property browser, which consists of specialized views for the
+different object types, and presents only the most often used aspects
+of these objects to the user, this way exposing the full power of the
+property browser to advanced users only.</P>
+<P LANG="en-US" CLASS="western">Additionally, functionality
+enhancements will be made to SO/OOo's form layer.  Included here are
+additions to the form controls which are required in the Microsoft
+Interoperability Chapter, but also new implementations (such as
+real-time filter controls) which will bring SO/OOo nearer to the
+current state-of-the-art.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Common Tasks</P>
+<P LANG="en-US" CLASS="western">We will provide the user with more
+auto pilots for the most common tasks in the database area,
+respectively enhance the existing auto pilots. In SO/OOo &ldquo;Q&rdquo;,
+we will have an enhanced report and form auto pilot, and new pilots
+for designing new tables, and designing customized data views aka
+<H3 LANG="en-US" CLASS="western"><A NAME="4.1.3.Performance|outline"></A>
+4.1.3 Performance</H3>
+<P LANG="en-US" CLASS="western">(Matthias Huetsch, May 2003)</P>
+<H4 LANG="en-US" CLASS="western"> Startup Time</H4>
+<P LANG="en-US" CLASS="western">The most visible performance
+improvement in SO/OOo will be the substantial shortening of the time
+required for first startup, in particular when the system has not
+been used for some time or after a system reboot. The improved first
+startup time will correspond to the time used by competing
+<P LANG="en-US" CLASS="western">Generally, the decrease in startup
+time will be addressed through refactoring the code and removing the
+strong interdependencies between:</P>
+<P LANG="en-US" CLASS="western">Application 'Core', 'User Interface'
+and 'Filter' code</P>
+	<LI><P LANG="en-US" CLASS="western">Application code and 'Common
+	User Interface' code spread over several shared libraries</P>
+	<LI><P LANG="en-US" CLASS="western">Application code and
+	'Accessibility Helper Class' code spread over several shared
+	libraries</P>
+	<LI><P LANG="en-US" CLASS="western">Several large shared libraries
+	tied together due to the use of a global initialization pattern</P>
+<P LANG="en-US" CLASS="western">In combination, these refactoring
+actions shall result in loading a relatively lightweight framework
+plus the necessary application code and document filters upon
+startup, only, and will thus reduce both the startup time as well as
+the initial memory consumption.</P>
+<H4 LANG="en-US" CLASS="western"> Document Open/Save Time</H4>
+<P LANG="en-US" CLASS="western">The second most visible performance
+improvement in SO/OOo will be decreasing the time required for
+opening or saving larger documents, in particular for documents in
+the native XML format.  This time improvement will be comparable with
+competing applications.</P>
+<P LANG="en-US" CLASS="western">SO/OOo will implement this time
+savings with SO/OOo API enhancements that are optimized for XML
+import / export and are fully supported by the application internal
+implementations.  Code optimizations along the entire import / export
+component chain will be evaluated to identify and eliminate
+<P LANG="en-US" CLASS="western">Responsiveness</P>
+<P LANG="en-US" CLASS="western"><SPAN LANG="en-US"><FONT SIZE=3>&quot;Q&quot;</FONT></SPAN>
+will speed up the graphics display and increase the responsiveness in
+rendering complex drawing objects.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">This improvement will be addressed
+with a redesign of both the graphics toolkit, adding e.g., support
+for modern hardware acceleration, and the presentation engine, making
+use of double-buffering and other caching techniques.</P>
+<H4 LANG="en-US" CLASS="western"> Scalability</H4>
+<P LANG="en-US" CLASS="western">Large scale multi-user deployments in
+which possibly hundreds of SO/OOo application instances are running
+on a single multi-processor server will be improved beyond what
+&ldquo;Geordi&rdquo; already addresses.  Scalability issues can be
+summarized and addressed as follows:</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">System Load</P>
+<P LANG="en-US" CLASS="western">A high number of context switches per
+second is caused by SO/OOo instances temporarily yielding control to
+other processes or threads. This behavior induces a high load on the
+system scheduler, and may as well adversely affect the responsiveness
+of SO/OOo itself.</P>
+<P LANG="en-US" CLASS="western">This will be addressed by giving up
+current cooperative and timer based polling concepts in favor of
+preemptive and event driven concepts.</P>
+<P LANG="en-US" CLASS="western"><BR><BR>
+<P LANG="en-US" CLASS="western">Memory Consumption</P>
+<P LANG="en-US" CLASS="western">The amount of non-shareable memory
+per SO/OOo process to a large extend determines the number of
+instances that can run simultaneously on a given server machine.</P>
+<P LANG="en-US" CLASS="western">This will be addressed by reducing
+the size of writeable data segments in shared libraries and special
+purpose memory allocators for compact mass object storage.</P>
+<H3 LANG="en-US" CLASS="western"><A NAME="4.1.4.Programmability|outline"></A>
+4.1.4 Programmability</H3>
+<H4 LANG="en-US" CLASS="western"> UNO/Office API Improvements</H4>
+<P LANG="en-US" CLASS="western">(Stephan Bergmann, Daniel Boelzle,
+Kai Sommerfeld, May 2003)</P>
+<P LANG="en-US" CLASS="western">The Office UNO API is very fine
+grained. Although this offers maximum flexibility,  programmers often
+want to have simplified high-level UNO interfaces. This enables rapid
+application development and helps even lower-skilled developers to
+reach their goals quickly. To address this problem we need to provide
+a new set of task-oriented high-level convenience UNO services.</P>
+<P LANG="en-US" CLASS="western">UNO defines language independent
+concepts like services, interfaces or the Any data type. The binding
+to concrete languages often maps these concepts One to One. This is
+not always the optimum because it may require the developer to learn
+constructs that are unusual or even strange for a certain programming
+language. A popular example for this is the queryInterface call,
+which should be a simple cast in Java. For the next Office release we
+will provide new UNO features which will simplify the usage of UNO in
+general or for particular language bindings.</P>
+<H4 LANG="en-US" CLASS="western"> Integrated IDE for multiple
+scripting languages</H4>
+<P LANG="en-US" CLASS="western">(Thomas Benisch, May 2003)</P>
+<P LANG="en-US" CLASS="western">With the language independent
+scripting framework it will be possible to script SO/OOo in any
+supported scripting language. This raises the need for a lightweight
+scripting IDE, which is integrated into SO/OOo and supports multiple
+scripting languages including SO/OOo Basic, Java and JavaScript.</P>
+<P LANG="en-US" CLASS="western">The scripting IDE will be based on a
+language independent IDE binding concept. A scripting language can
+only be integrated into the IDE, if the corresponding interfaces are
+supported by the scripting runtime.</P>
+<P LANG="en-US" CLASS="western">It is planned, that the current Basic
+IDE and its dialog editor will be refactored and modularized, which
+will be the base for the new scripting IDE.</P>
+<H4 LANG="en-US" CLASS="western"> Type Life Cycle</H4>
+<P LANG="en-US" CLASS="western">(Daniel Boelzle, May 2003)</P>
+<P LANG="en-US" CLASS="western">The Universal Network Objects (UNO)
+Component Model with its support for different languages gains
+popularity. UNO paves the way to access the SO/OOo API and
+development of extensions by 3rd party developers.</P>
+<P LANG="en-US" CLASS="western">This way, developers have to face
+quite some problems introducing and using UNO types concurrently. If
+it is feasible, it is desirable that UNO types have a controlled life
+<H4 LANG="en-US" CLASS="western"> .NET Bridge</H4>
+<P LANG="en-US" CLASS="western">(Joachim  Lingner, May 2003)</P>
+<P LANG="en-US" CLASS="western">SO/OOo uses software bridges in order
+to have pieces of code, which may be subjected to certain language-
+and runtime specific requirements and restrictions, interact with
+each other. For example, Java code or C++ code cannot interact
+naturally. The same goes for C++ code compiled with different
+<P LANG="en-US" CLASS="western">All those particular requirements to
+a piece of code is referred to as environment and it is said that a
+piece of code lives (or runs) in an environment. Now, to have code
+from one environment access code in another environment, one needs to
+have a bridge. Because of the multitude of possible combinations of
+environments, bridges use an intermediary environment, namely the UNO
+<P LANG="en-US" CLASS="western">If a new compiler is to be used or
+software written in a new language, then one only needs to provide a
+bridge into the UNO environment and all other environments for which
+there is also a UNO bridge may interact with the new environment.</P>
+<P LANG="en-US" CLASS="western">The CLI &ndash; UNO bridge enables
+programmers to use languages which produce CLI (Common Language
+Infrastructure) compatible code. This includes languages such as C#,
+C++ .NET, and Visual Basic .NET.</P>
+<H4 LANG="en-US" CLASS="western"> Live Deployment and GUI</H4>
+<P LANG="en-US" CLASS="western">(Daniel Boelzle, May 2003)</P>
+<P LANG="en-US" CLASS="western">The development of 3rd party
+extensions for using the API is gaining
+popularity. The common tool to deploy those extensions into an Office
+installation is pkgchk. The user raises the pkgchk deployment tool
+specifying a package file to be installed. The tool then scans the
+content of the package file and handles different content types with
+respect to their file extensions:</P>
+	<LI><P LANG="en-US" CLASS="western">UNO shared library components
+	(.dll, .so files)</P>
+	<LI><P LANG="en-US" CLASS="western">UNO Java components (.jar files)</P>
+	<LI><P LANG="en-US" CLASS="western">UNO Python components (.py
+	files)</P>
+	<LI><P LANG="en-US" CLASS="western">UNO typelibrary files (.rdb
+	files)</P>
+	<LI><P LANG="en-US" CLASS="western">SO/OOo Basic scripts and dialogs
+	(script.xlb and dialog.xlb files)</P>
+	<LI><P LANG="en-US" CLASS="western">Configuration schemata and data
+	(.xcs, .xcu files)</P>
+<P LANG="en-US" CLASS="western">Currently users have to shut down a
+running office process before running the pkgchk deployment tool
+adding or removing packages. It may be desirable that users can
+deploy packages while running an office process and trigger removal
+of existing packages.  Moreover, the currently used pkgchk deployment
+tool is a command line tool.  If deployment can be performed while
+running the office process, a proper user interface is nice, too
+(e.g. in &ldquo;Tools&rdquo; menu bar).</P>
+<P LANG="en-US" CLASS="western">The need to shut down the offices
+using a shared installation is even worse, e.g. Imagine having a
+shared installation used by a thousand users, before something can be
+deployed  into this shared installation, it has to be ensured that
+every running office started out of this installation has been
+terminated. Otherwise this office instances may work with
+inconsistent data, which can lead to data loss or crashes.</P>
+<P LANG="en-US" CLASS="western">Different content types are deployed
+differently. Thus the problems that occur upon insertion/removal of a
+package at runtime are different. 
+<H4 LANG="en-US" CLASS="western"> Scripting Framework</H4>
+<P LANG="en-US" CLASS="western">(Noel Power, April 2003)</P>
+<P LANG="en-US" CLASS="western">Currently Scripting support for
+SO/OOo exists for one language only, SO/OOo Basic. Users, Developers
+and ISVs who wish to extend SO/OOo using scripting are locked into
+this single offering. It is advantageous from strategic point of view
+to support Java and Java derivatives  such as JavaScript and
+BeanShell for scripting.  Other scripting languages such as Python
+could also be added as the market dictates.</P>
+<P LANG="en-US" CLASS="western">A framework is needed to allow new
+scripting languages to be added and supported. It should be possible
+to easily plug in additional languages runtimes. The framework needs
+to provide an environment to enable users to easily and quickly
+develop, deploy and execute scripts. Scripting should be easy.  A
+script developer should be able to write and test a script with a
+minimal set of steps. They should be able to experiment and learn
+within the scripting environment, enabling them to accomplish their
+scripting tasks easily and quickly.   
+<P LANG="en-US" CLASS="western">Scripting in SO/OOo will be made more
+easy, intuitive and low cost. This is mainly due to the complexity
+and low level nature of the current SO/OOo API.  In order for
+scripting to be be easy, intuitive and low cost, the SO/OOo API needs
+to be simplified. Such a simplified API should be well documented,
+script focused and high-level. This would allow users to intuitively
+discover the necessary objects and interfaces needed to program a
+specific task rather than having to work through a mountain of
+<H3 LANG="en-US" CLASS="western"><A NAME="4.1.5.Integration%20into%20the%20Gnome%20Desktop,%20and%20Microsoft%20Windows|outline"></A>
+4.1.5 Integration into the Gnome Desktop, and Microsoft Windows</H3>
+<P LANG="en-US" CLASS="western">(Christof Pintaske, June 2003)</P>
+<P LANG="en-US" CLASS="western">(Requirements for integration into
+Microsoft Windows need to be determined later)</P>
+<H4 LANG="en-US" CLASS="western"> Look and Feel</H4>
+<P LANG="en-US" CLASS="western">&ldquo;Geordi&rdquo; emulates the
+color-scheme and basic font setting of a running Gnome-2.x desktop.
+&quot;Q&quot; is required to pickup the style of all basic widget
+elements (buttons, slider, fixed-text, check-boxes and so on) in a
+way that exactly reflects the current GTK widget theme. The majority
+of dialogs should not show any immediately visible differences to a
+dialog implemented in the GTK widget set. Focus, modality, and
+guidelines for widget placement will not be adapted.</P>
+<P LANG="en-US" CLASS="western">&quot;Geordi&quot; uses a proprietary
+engine for installing, naming, and selecting fonts. Font names on the
+system may be invalid in SO/OOo, or denote to a completely different
+font and vice versa. The &quot;Q&quot; font handling scheme has to be
+consistent with the Desktop and the major applications. Naming of
+fonts shipping with &quot;Geordi&quot; or older versions of SO/OOo
+must not change. Explicit settings for font replacement must remain
+intact as well.</P>
+<P LANG="en-US" CLASS="western">This will be addressed by using the
+systems font configuration (Fontconfig2). Doing so will be as well
+beneficial for the startup performance since &quot;Q&quot; will not
+need to examine fonts at startup.</P>
+<P LANG="en-US" CLASS="western">&quot;Geordi&quot; uses a mixture of
+X11/cursorfont mouse pointer, pointer specifically designed for
+SO/OOo, and pointer that are modeled similar to those found on other
+platforms, like Microsoft Windows. This is inconsistent with other
+applications on the Gnome desktop and it inhibits proper pointer
+settings for accessible desktop themes (large cursor settings, high
+contrast themes,  ...). &quot;Q&quot; should use Gnome compliant
+cursors where appropriate.</P>
+<P LANG="en-US" CLASS="western">Hotkey/Accelerator scheme should be
+aligned with the Gnome desktop. Common tasks should reflect in equal
+keys. Keys already taken by the window manager should not be offered
+or used for application bindings.</P>
+<P LANG="en-US" CLASS="western">It would be nice to have Gnome input
+methods available in SO/OOo as well (currently only available in
+Gnome-edit and Gnome-terminal).</P>
+<H4 LANG="en-US" CLASS="western"> Printing</H4>
+<P LANG="en-US" CLASS="western">&quot;Q&quot; is required to be able
+to provide the same printing experience as &quot;Geordi&quot; without
+the need of neither own printer configuration functionality nor own
+printer configuration data on a Gnome Desktop system. It may
+eventually provide an own UI to the system configuration if the
+systems UI is insufficient or otherwise unusable.</P>
+<P LANG="en-US" CLASS="western">The CUPS system encapsulates and
+provides access to locally connected printer, and remote printer
+accessed through the IPP, LPD, SMB and many other protocols.  
+<P LANG="en-US" CLASS="western">CUPS provides a legacy layer that
+enables &quot;Geordi&quot; to chose from and to print to all printers
+configured within CUPS. However &quot;Q&quot; will be enhanced to
+query printer capabilities from CUPS and comply with CUPS
+configuration settings, thus making the proprietary SO/OOo printer
+administration obsolete in favor of the according desktops system
+<P LANG="en-US" CLASS="western">Currently there is no system-wide
+print dialog available. If there'll be shareable UI available in &quot;Q&quot;
+timeframe it should be integrated instead of implementing a
+proprietary UI.</P>
+<H4 LANG="en-US" CLASS="western"> Integration of network
+<P LANG="en-US" CLASS="western">&quot;Q&quot; is required to be able
+to load and store files on SMB shares to allow for interoperability
+in a network of Microsoft Windows computers. The UI has to be
+extended to give convenient access to this functionality. Further on
+it is desired to be able to handle all URLs that are valid in the
+Gnome Desktop file manager (Nautilus)</P>
+<P LANG="en-US" CLASS="western">Gnome provides a virtual file system
+service (GnomeVFS). It makes various file systems transparent to the
+user. Amongst others it is able to cope with protocols like HTTP,
+FTP, NFS, SMB, local files, WebDAV. Further on it provides MIME
+information and maintain an according application registry.</P>
+<P LANG="en-US" CLASS="western">&quot;Q&quot; will be enabled to use
+GnomeVFS. The main benefit is to improve interoperability with
+Windows SMB shares. GnomeVFS will as well improve interoperability
+with the Nautilus file manager since contents will be available in
+both applications through the same URI. Further on SO/OOo will be
+able to handle external data conforming to the system MIME settings. 
+<H4 LANG="en-US" CLASS="western"> Desktop integration</H4>
+<P LANG="en-US" CLASS="western">A user of Microsoft Windows is able
+to create new, empty SO/OOo documents on the desktop. The Gnome
+Desktop shall offer a competitive feature. This will be addressed by
+creating an according Bonobo component for Nautilus.</P>
+<P LANG="en-US" CLASS="western">The most important applications on
+the Gnome desktop will be immediately available from the Gnome start
+menu. An according top level entry for SO/OOo needs be added. 
+<P LANG="en-US" CLASS="western">It is required to inform all
+application on the Gnome desktop about how to handle SO/OOo files.
+Especially the browser and the file manager need to be able handle
+them appropriately and to show an appropriate icon. This will be
+addressed by registering the SO/OOo MIME types in the according
+system registry.</P>
+<H4 LANG="en-US" CLASS="western"> Application interoperability</H4>
+<P LANG="en-US" CLASS="western">Available browser plugins will be
+made available for the SO/OOo &ldquo;Insert -&gt; Object -&gt;
+{Plugin|Sound|Video} mechanism.</P>
+<P LANG="en-US" CLASS="western">The Ximian Evolution address book
+will be imported into SO/OOo.</P>
+<H4 LANG="en-US" CLASS="western"> Installation</H4>
+<P LANG="en-US" CLASS="western">The Gnome Desktop system will be
+delivered as a set of packages in the <A HREF="">
+RPM</A> format. It's necessary to seamlessly deploy and update SO/OOo
+together with other parts of the operating system. 
+<P LANG="en-US" CLASS="western">Currently most Linux distributions
+provide RPMs that correspond to a complete &quot;Geordi&quot; network
+installation. &quot;Q&quot; will be delivered as a more fine grained
+set of packages that enable individual installation, update and
+patching of functional entities. Shareable files for system
+integration will be installed in the system and not in every users
+home directory as in &quot;Geordi&quot;</P>
+<H4 LANG="en-US" CLASS="western"> Configuration</H4>
+<P LANG="en-US" CLASS="western">SO/OOo makes use of a set of helper
+applications. Application that can be used as helper application in
+SO/OOo need to useable without further administration. &quot;Q&quot;
+will make use of the Gnome desktop configuration where possible.
+Examples here are default mailer, default web browser, and proxy
+settings. The SO/OOo Configuration component will provide a
+transparent access to the system settings, which will be resolved via
+a plugable backend architecture.</P>
+<H2 LANG="en-US" CLASS="western"><A NAME="4.2.General%20Improvements|outline"></A>
+4.2 General Improvements</H2>
+<H3 LANG="en-US" CLASS="western"><A NAME="4.2.1.Stability%20and%20Quality|outline"></A>
+4.2.1 Stability and Quality</H3>
+<P LANG="en-US" CLASS="western">(Matthias Huetsch, June 2003)</P>
+<H4 LANG="en-US" CLASS="western"> Document Recovery</H4>
+<P LANG="en-US" CLASS="western">Any potential crash of SO/OOo that
+could result in lost data will be addressed by defaulting to a new
+Auto Recovery mechanism performing a regular backup of documents and
+settings. This Auto Recovery mechanism will restore a users  work
+environment to the state before SO/OOo terminated.</P>
+<P LANG="en-US" CLASS="western">The Document Recovery dialog will be
+enhanced to guide a user through this Auto Recovery process of
+restoring documents and to provide detailed feedback upon the
+recovery progress.</P>
+<H4 LANG="en-US" CLASS="western"> Error Reporter</H4>
+<P LANG="en-US" CLASS="western">Stability improvements for SO/OOo are
+required to be measurable. In order to be able to characterize the
+current stability level, this requirement was pulled-in to the SO/OOo
+&ldquo;Geordi&rdquo; release and has been addressed by an Error
+Reporter application, recording crash data and user feedback about
+document loss or preservation.</P>
+<P LANG="en-US" CLASS="western">This Error Reporter will help to
+identify and eliminate crash causes, as well as  provide a metric to
+show improvements in the stability levels achieved for SO/OOo &ldquo;Q&rdquo;
+and subsequent releases.</P>
+<H3 LANG="en-US" CLASS="western"><A NAME="4.2.2.Administration%20and%20Deployment|outline"></A>
+4.2.2 Administration and Deployment</H3>
+<P LANG="en-US" CLASS="western">(Dirk Grobler, Christof Pintaske, May
+<H4 LANG="en-US" CLASS="western"> Deployment 
+<P LANG="en-US" CLASS="western">The installation paradigm changes
+from being primarily single user oriented to being administrator
+oriented. It is looking for large scale installations and
+administrations. This issue will be addressed by conforming the
+installation process to the respective systems installer services,
+since these services already provide or enable an existing
+installation tooling.</P>
+<P LANG="en-US" CLASS="western">The &quot;Geordi&quot;
+user-installation as a required step of a network-installation will
+cease to exist. The office applications will be fully functional from
+the first start. Gathering user specific data will be postponed to
+the first application start or queried directly from the system.
+Document and setting defaults will be generated on the fly during the
+first start or on demand.</P>
+<P LANG="en-US" CLASS="western">The repair mode of the setup will be
+dropped. Repairing the installed files is already handled by the
+native package mechanism (usually by a reinstall). This does not
+affect user driven changes since user and system files are strictly
+<P LANG="en-US" CLASS="western">Upgrading and patching will be
+performed by means of the respective system installer.</P>
+<P LANG="en-US" CLASS="western">Since Solaris and Linux do not

[... 606 lines stripped ...]

View raw message