DOCSLIB.ORG

Suggestions for Interoperability Undertaking

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Suggestions for Interoperability Undertaking Ms. Neelie Kroes Commissioner DG COMPETITION Bourgetlaan 1 1140 Evere Bruxelles/Brussel SUBJECT: Suggestions for Interoperability Undertaking The Hague, September 28th 2009 Dear Commissioner Kroes, We read with interest the article in several media published last week1 where you were quoted as saying that the Commission is near to closing a deal on a number of issues in the case against Microsoft. We think that this inquiry is of great importance, and that restoring a level playing field in this area is essential for the future ambitions of Europe. On behalf of OpenDoc Society we would like to respond to the "Interoperability Undertaking"-proposal2 from Microsoft that was made to the European Commission, hoping that this will be of help to you in finding effective remedies to the issues that matter most in this case. OpenDoc Society is an international member-based not-for-profit organisation headquartered in Europe, with individual and organisational members around the planet. Our organisational members range from large software vendors and open source communities to small and medium sized enterprises, from (also European) government organisations to academia and research, and from education and cultural institutions up to special needs groups, registered charities and the military. Our goal is to promote best practises for productivity applications, most notably in the area of open standards, document exchange and processing. In this document, we will respond to the Undertaking from our expert knowledge in this domain and make a number of proposals to improve that document in order to make it effective given the purposes it is drafted for. We hope you will forgive us the sometimes deeply technical nature of these comments. From our perspective it seems that good progress has been made in several other areas of the European Commission's investigation, e.g. in the browser part where the use of web standards will soon be the default. Yet, in the field of productivity applications (probably economically and societally the most important area) many serious issues unique to that domain are still likely to remain if the Undertaking were to stay limited to the current proposal. These issues may not be the most eye-catching in this situation where different investigations are on top of each other, yet they are essential if we want real solutions that work for the customer and for the market. Office file format lock-in is probably the single strongest impediment to customer choice in IT. In the area of personal productivity applications we have a long way to go before the market can restore itself to health, because issues are densely interwoven across different levels and across time. With the current proposals it is unlikely that we will see a level playing field: the use of open standards (even those with a large traction in the market, such as ODF) does not stand a fair chance, which hampers choice and makes real competition almost impossible. That in turn will remain to have a huge effect on the IT market in general for many years to come. It is to be commended that Microsoft is thinking about giving people an active choice to choose ODF as their default file format. But in contrast with the browser it is only currently promising this for a very small minority of their users – excluding an estimated 80% of users that use a version other than the last version of their Office for Windows product. While Microsoft has been delivering 'Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats' adding support for its newly developed (non-standardised) Office 2007 for Windows file formats3 for all its legacy versions on all platforms for a number of years, ODF would be supported only on Office 2007 SP2 for Windows and subsequent versions. In fact, in versions before Office 2007 for Windows ODF is currently still not officially supported under warranty, even though the software to do this has been available for years in an outsourced project coordinated and funded by 1 http://www.nytimes.com/2009/09/23/business/global/23kroes.html 2 http://www.microsoft.com/presspass/presskits/eu-msft/docs/Microsoft_Interoperability_Undertaking.doc 3 These 'final' legacy formats were created midway the drafting of ECMA 376, the precursor to IS29500. The differences with both these formats are not publicly known. OpenDoc Society ÷ Wibautstraat 150 ÷ 1091 GR ÷ Amsterdam The Netherlands ÷ [email protected] Microsoft. Also there has not been any sign of supporting ODF for Microsoft Office for Mac, let alone its legacy versions. Its free Office Viewers for the Windows platform don't support ODF as of yet. We consider that 'second class citizenship' of ODF to be extremely harmful to choice and competition. We note also that the actual proposed 'file format ballot screen' has to undergo significant scrutiny, because the actual wording and interface usability can have a huge impact on the outcome. Our organisation is very willing to help the Commission and Microsoft strike the right chord in this respect. There are of course many other issues. To this day there are still no complete specifications of Microsoft's legacy formats (from the various historical binary formats to the Office 2007 for Windows default file formats).4 The amount of documentation compared to the available specifications for ECMA 376 and IS29500 is rather small, and many embedded elements are not even covered in those – posing a risk with regards to patents. Since there is also no authoritative mapping of the Office for Windows file formats on ODF or even on ECMA 376 or IS29500, fully reliable real-world interoperability with current and historical Microsoft products remains impossible. Providing a smooth transition between old and new file formats is a key element in realising a migration scenario where applications supporting a new standard interact with existing applications. Writing an implementation to reliably support the legacy Microsoft file formats is currently like hitting a moving target in the dark, and often involves trial and error in the black art of software reverse engineering. Since there are no official test suites for the legacy file formats, competitors can verify nor prove to customers they handle these formats in the right way. The absence of complete specifications and mappings to standards (and vice versa) and the lack of a test suite puts other implementations at a major disadvantage in any practical scenario which involves interaction with older Microsoft products – which still have a dominant market share by themselves. At an implementation level there is still much to be desired in the current Office 2007 for Windows implementation of the ODF standard. Currently Microsoft Office 2007 for Windows fails to retain all revision history information when saving to an ODF file. There is no practical reason for this, and fixing that unnecessary information loss is crucial to the Microsoft user base that want to make the switch to application-independent and future-proof ODF. In addition, Office 2007 for Windows behaves without much respect towards other ODF applications - destroying many data elements on import which the ODF specifications say should be kept. This effectively disables many of the innovative uses of ODF and foreshadows immediate incompatibility with future versions of ODF. This is a good demonstration of the fact that the promise as made under the 'General Provisions' in the 'Interoperability Commitments' of the Undertaking will not suffice: the publicly available implementer notes for ODF published by Microsoft state that these elements are not supported, and that would be sufficient according to the principles (set out under point 8 of the Undertaking). The fact that the Office 2007 for Windows software is able to handle custom XML as part of its Office 2007 for Windows native file format proves that this behaviour is unnecessary. Clearly, a complete, faithful and trustworthy implementation of ODF by Microsoft matters a great deal – one only needs to make a small step aside in this dossier to look at the browser case where barely noticeable implementation deviations from the standard in Microsoft products had immense effect on the outcome of the browser war. With regards to future versions of the ODF standard we are also concerned about the huge delay in supporting any new ODF version. Please note that the next expected updates of the standard will contain functionality such as OpenFormula spreadsheet formula's which are essential for the professional market and already now offer full interoperability with many products already on the market. Any delay in full support by Microsoft has a huge impact on the market. The Undertaking proposal talks about waiting for nine months after publication by ISO in order to support it. Since Microsoft participates in OASIS within the ODF technical committee, there is no reason why they should wait for final ISO publication before supporting a new ODF feature. Currently, Microsoft already like most vendors has chosen in its current implementations to support a version of ODF published only by OASIS (ODF 1.1) rather than wait for the adoption of ISO of that same standard which is now in the pipeline. Note also that in the case of IS29500, no such caution to await the publication of the standard was taken by Microsoft (even shipping the product before the standard was halfway finished) with as a result the severe differences between Office 2007 for Windows file formats, ECMA 376 and IS29500. Unless Microsoft commits to the same type of caution for all of the file formats it supports, this would put ODF at a definite disadvantage. The fair solution is to require that within a period of nine months after a feature is approved in either OASIS or ISO it is implemented by Microsoft in all relevant products.
Load more

Recommended publications
  • Develop-21 9503 March 1995.Pdf
    develop E D I T O R I A L S T A F F T H I N G S T O K N O W C O N T A C T I N G U S Editor-in-Cheek Caroline Rose develop, The Apple Technical Feedback. Send editorial suggestions Managing Editor Toni Moccia Journal, a quarterly publication of or comments to Caroline Rose at Technical Buckstopper Dave Johnson Apple Computer’s Developer Press AppleLink CROSE, Internet group, is published in March, June, [email protected], or fax Bookmark CD Leader Alex Dosher September, and December. develop (408)974-6395. Send technical Able Assistants Meredith Best, Liz Hujsak articles and code have been reviewed questions about develop to Dave Our Boss Greg Joswiak for robustness by Apple engineers. Johnson at AppleLink JOHNSON.DK, His Boss Dennis Matthews Internet [email protected], CompuServe This issue’s CD. Subscription issues Review Board Pete “Luke” Alexander, Dave 75300,715, or fax (408)974-6395. Or of develop are accompanied by the Radcliffe, Jim Reekes, Bryan K. “Beaker” write to Caroline or Dave at Apple develop Bookmark CD. The Bookmark Ressler, Larry Rosenstein, Andy Shebanow, Computer, Inc., One Infinite Loop, CD contains a subset of the materials Gregg Williams M/S 303-4DP, Cupertino, CA 95014. on the monthly Developer CD Series, Contributing Editors Lorraine Anderson, which is available from APDA. Article submissions. Ask for our Steve Chernicoff, Toni Haskell, Judy Included on the CD are this issue and Author’s Guidelines and a submission Helfand, Cheryl Potter all back issues of develop along with the form at AppleLink DEVELOP, Indexer Marc Savage code that the articles describe.
    [Show full text]
  • XXX Format Assessment
    Digital Preservation Assessment: Date: 20/09/2016 Preservation Open Document Text (ODT) Format Team Preservation Assessment Version: 1.0 Open Document Text (ODT) Format Preservation Assessment Document History Date Version Author(s) Circulation 20/09/2016 1.0 Michael Day, Paul Wheatley External British Library Digital Preservation Team [email protected] This work is licensed under the Creative Commons Attribution 4.0 International License. Page 1 of 12 Digital Preservation Assessment: Date: 20/09/2016 Preservation Open Document Text (ODT) Format Team Preservation Assessment Version: 1.0 1. Introduction This document provides a high-level, non-collection specific assessment of the OpenDocument Text (ODT) file format with regard to preservation risks and the practicalities of preserving data in this format. The OpenDocument Format is based on the Extensible Markup Language (XML), so this assessment should be read in conjunction with the British Library’s generic format assessment of XML [1]. This assessment is one of a series of format reviews carried out by the British Library’s Digital Preservation Team. Some parts of this review have been based on format assessments undertaken by Paul Wheatley for Harvard University Library. An explanation of the criteria used in this assessment is provided in italics below each heading. [Text in italic font is taken (or adapted) from the Harvard University Library assessment] 1.1 Scope This document will primarily focus on the version of OpenDocument Text defined in OpenDocument Format (ODF) version 1.2, which was approved as ISO/IEC 26300-1:2015 by ISO/IEC JTC1/SC34 in June 2015 [2]. Note that this assessment considers format issues only, and does not explore other factors essential to a preservation planning exercise, such as collection specific characteristics, that should always be considered before implementing preservation actions.
    [Show full text]
  • Foxit Mobilepdf SDK Developer Guide
    Foxit MobilePDF SDK Developer Guide TABLE OF CONTENTS 1 Introduction to Foxit MobilePDF SDK ...........................................................................................1 1.1 Why Foxit MobilePDF SDK is your choice .............................................................................. 1 1.2 Foxit MobilePDF SDK .............................................................................................................. 2 1.3 Key features ........................................................................................................................... 3 1.4 Evaluation ............................................................................................................................... 5 1.5 License .................................................................................................................................... 5 1.6 About this Guide .................................................................................................................... 5 2 Getting Started ...........................................................................................................................7 2.1 Requirements ......................................................................................................................... 7 2.2 What is in the Package ........................................................................................................... 7 2.3 How to run a demo ...............................................................................................................
    [Show full text]
  • TP-1996-789.Pdf (141.1Kb)
    Nationaal Lucht- en Ruimtevaartlaboratorium National Aerospace Laboratory NLR NLR TP 96789 Overview and discussion of electronic exchange standards for technical information H. Kuiper and J.C. Donker DOCUMENT CONTROL SHEET ORIGINATOR'S REF. SECURITY CLASS. NLR TP 96789 U Unclassified ORIGINATOR National Aerospace Laboratory NLR, Amsterdam, The Netherlands TITLE Overview and discussion of electronic exchange standards for technical information PRESENTED AT the CALS Europe'96 conference, Paris, May 29-31, under the title "SGML, HTML, the paperless office... what about the forests and the trees", upon invitation of the NL MOD Representative in the conference committee. AUTHORS DATE pp ref H. Kuiper and J.C. Donker 960725 36 8 DESCRIPTORS Computer graphics Multimedia Document storage Software tools Document markup languages Standards Format Texts Hypertext Word processing Information dissemination ABSTRACT Nowadays more and more information is being exchanged electronically. Reasons for this include a higher degree of cooperation between information suppliers and users, an increasing demand for speed (of production and modification, and reduction of time to market), and cost reduction. On the technology side, the advent of the electronic highway enables effective and efficient electronic information exchange. For reasons of timeliness and life cycle costs, standards and specifications are becoming more important. The aim of this paper is to provide an overview of standards and specifications for electronic exchange of (technical document) information and to discuss the most common ones currently available for text, images, and document exchange. Emerging standards and specifications, such as for audio, video and virtual environments are also briefly discussed. Finally, a brief description is given of a standard for enterprise integration and product data exchange.
    [Show full text]
  • International Standard Iso/Iec 26300-2
    This is a previewINTERNATIONAL - click here to buy the full publication ISO/IEC STANDARD 26300-2 First edition 2015-07-01 Information technology — Open Document Format for Office Applications (OpenDocument) v1.2 — Part 2: Recalculated Formula (OpenFormula) Format Technologies de l’information — Format de document ouvert pour applications de bureau (OpenDocument) v1.2 — Partie 2: Titre manque Reference number ISO/IEC 26300-2:2015(E) © ISO/IEC 2015 ISO/IEC 26300-2:2015(E) This is a preview - click here to buy the full publication COPYRIGHT PROTECTED DOCUMENT © ISO/IEC 2015 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form orthe by requester. any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of Case postale 56 • CH-1211 Geneva 20 ISOTel. copyright+ 41 22 749 office 01 11 Fax + 41 22 749 09 47 Web www.iso.org E-mail [email protected] Published in Switzerland ii © ISO/IEC 2015 – All rights reserved This is a preview - click here to buy the full publication ISO/IEC 26300-2:2015(E) Open Document Format for Office Applications (OpenDocument) Version 1.2 Part 2: Recalculated Formula (OpenFormula) Format OASIS Standard 29 September 2011 Specification URIs: This version: http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.odt (Authoritative) http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.pdf
    [Show full text]
  • A Key for Document Interoperability?
    ELAN Electronic Government and Applications Feature Based Document Profiling - A Key for Document Interoperability? Bibliografische Information der Deutschen Nationalbibliothek: Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.deabrufbar. 1.Auflage Juni 2012 Alle Rechte vorbehalten © Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS, Juni 2012 Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS Kaiserin-Augusta-Allee31 10589 Berlin Telefon: +49-30-3436-7115 Telefax: +49-30-3436-8000 [email protected] www.fokus.fraunhofer.de Dieses Werk ist einschließlich aller seiner Teile urheberrechtlich geschützt. Jede Ver- wertung, die über die engen Grenzen des Urheberrechtsgesetzes hinausgeht, ist ohne schriftliche Zustimmung des Instituts unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen sowie die Speicherung in elektronischen Systemen. Die Wiedergabe von Warenbezeichnungen und Handels- namen in diesem Buch berechtigt nicht zu der Annahme, dass solche Bezeichnungen im Sinne der Warenzeichen-und Markenschutz-Gesetzgebung als frei zu betrachten wären und deshalb von jedermann benutzt werden dürften. Soweit in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richt-linien (z.B. DIN, VDI) Bezug genommen oder aus ihnen zitiert worden ist, kann das Institut keine Gewähr für Richtigkeit, Vollständigkeit oder Aktualität übernehmen. ISBN 978-3-00-038675-6
    [Show full text]
  • Nitro PDF Professional 5.X User Guide 2 Nitro PDF Professional User Guide
    Nitro PDF Professional 5.x User Guide 2 Nitro PDF Professional User Guide Table of Contents Part I START 7 Part II Help & Registration 7 1 Getting Started................................................................................................................................... guide 7 2 Online help................................................................................................................................... 7 3 Checking ...................................................................................................................................for software updates 8 4 Registering................................................................................................................................... product 8 Part III Workspace 8 1 Ribbon interface................................................................................................................................... 9 Hiding & showing the.......................................................................................................................................................... ribbon 10 Ribbon shortcuts .......................................................................................................................................................... 11 2 Quick Access................................................................................................................................... Toolbar 11 3 Nitro PDF..................................................................................................................................
    [Show full text]
  • Opendoc Spreadsheet Function File Date
    Opendoc Spreadsheet Function File Date Braless Ignacius fordid homologically. Is Sayre asthenic or unkindled after rock-bottom Olaf bosom so whacking? Solly compromising gymnastically as inward Ira flukes her releasers fraternized tacitly. The simple example will be used for use org requires extra buttons opendoc spreadsheet function file date entries from sql insertion. Depending on our security that describe presentation, an integer values of numbers, and a reference, store opendoc spreadsheet function file date, gives a really funny face when converting html. There are zeros if omitted, gnumeric can have existing session names in a text documents or a draw page. Yank subtree belonging to backup data management and attributes that is currently selected by using resources below opendoc spreadsheet function file date as word lists, as you could have. Each field form a few minutes open the width number of opendoc spreadsheet function file date used a cell cannot find any warranty disclaimers may overlap with a namespace and xforms model. The characters need to jpg image data according to. The currently visible or linked into exceptions must rest api offers different formats would be used for a packaging system along with two. The partition splits into your desktop version. Java works as timezone in jpg or reference returns an example, while they respect you? The first dereferenced, view it is explicitly defined in several instances, such a data pilot table of text is sometimes we will thus free. List for those that you need to grant patent licenses. Both versions might automatically terminate. This application opendoc spreadsheet function file date and quitting fellows and are unique address within a regular expression is stored there is automatic style.
    [Show full text]
  • 16-02-15 Willkie Buono
    CorporateThe Metropolitan Counsel® www.metrocorpcounsel.com Volume 16, No. 2 © 2008 The Metropolitan Corporate Counsel, Inc. February 2008 The Power Of Choice: Massachusetts Wisely Embraces Multiple Document Format Standards To Drive Greater Competition And Innovation Francis M. Buono closely than in Massachusetts. issued a report entitled “Open Standards, From the moment certain Massachusetts Closed Government: ITD’s Deliberate Disre- and McLean Sieverding government IT officials set in motion a plan to gard for Public Process,” in which it sharply mandate the use of the OpenDocument For- criticized the ITD for: (1) releasing the ETRM WILLKIE FARR & GALLAGHER LLP mat (“ODF”) as the default format for gov- despite public testimony that ODF may impair ernment documents, to the exclusion of other A “document format” (also known as a IT accessibility for thousands of workers with formats, the thorough and very public vetting “file format”) is a particular way to encode disabilities; (2) failing to conduct a cost analy- of the goals, potential impact, and resolution information for storage in a computer file.1 sis or develop implementation documents of the plan has caused many to question the Numerous document formats exist for encod- prior to issuing the ETRM; and (3) issuing appropriate role that government should play ing and storing the same type of information provisions in the ETRM relating to public in selecting and/or excluding technology solu- in word processing, spreadsheet, presentation, records management without the requisite tions (standards-based or otherwise), and on and other document types. Such document statutory authority.4 These shortcomings were what basis. Fortunately for Massachusetts and formats can complement each other by offer- its citizens, the goals of technical neutrality, later detailed in a comprehensive report by the ing different functionality, compete with one 5 choice, and inclusiveness prevailed, and other Auditor of the Commonwealth.
    [Show full text]
  • Automatic Digital Document Processing and Management
    Advances in Pattern Recognition For other titles published in this series, go to www.springer.com/series/4205 Stefano Ferilli Automatic Digital Document Processing and Management Problems, Algorithms and Techniques Stefano Ferilli Dipartimento di Informatica Università di Bari Via E. Orabona 4 70126 Bari Italy [email protected] Series Editor Professor Sameer Singh, PhD Research School of Informatics Loughborough University Loughborough UK ISSN 1617-7916 ISBN 978-0-85729-197-4 e-ISBN 978-0-85729-198-1 DOI 10.1007/978-0-85729-198-1 Springer London Dordrecht Heidelberg New York British Library Cataloguing in Publication Data A catalogue record for this book is available from the British Library © Springer-Verlag London Limited 2011 Apart from any fair dealing for the purposes of research or private study, or criticism or review, as per- mitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publish- ers, or in the case of reprographic reproduction in accordance with the terms of licenses issued by the Copyright Licensing Agency. Enquiries concerning reproduction outside those terms should be sent to the publishers. The use of registered names, trademarks, etc., in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant laws and regulations and therefore free for general use. The publisher makes no representation, express or implied, with regard to the accuracy of the information contained in this book and cannot accept any legal responsibility or liability for any errors or omissions that may be made.
    [Show full text]
  • ODF Workshop
    ODF Workshop ODF: The Past, Present and Future Michael Brauer, Sun, ODF TC Chair ODF Accessibility Pete Brunet, IBM, ODF Accessibility Subcommittee ODF Programmability Rob Weir, IBM, ODF TC Michael Brauer, Sun, ODF TC Chair ODF Interoperability Alan Clark, Novell, ODF Adoption TC Rob Weir, IBM, ODF TC ODF Adoption Don Harbison, IBM, ODF Adoption TC Co-Chair OASIS OpenDocument ISO/IEC 26300 The Past, the Present, and the Future Michael Brauer Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems About the Speaker Technical Architect in Sun Microsystem's OpenOffice.org/StarOffice development OpenOffice.org/StarOffice developer since 1995 Main focus: Office application development/file formats and XML technologies OpenOffice.org XML project owner OASIS OpenDocument Technical Committee chair Agenda The Past - History of OASIS OpenDocument format The Present – Sub Committees, Work in Progress The Future – OpenDocument v1.2 The Past 1999 Development of “StarOffice XML” file format starts Primary goal: interoperability 2000 Sun contributes StarOffice to OpenOffice.org “StarOffice XML” becomes “OpenOffice.org XML” open source community project First OpenOffice.org XML working draft publicly available 2001 OpenOffice.org XML is used as default file format for OpenOffice.org 1.0/Sun StarOffice 6.0 software 2002 Foundation of OASIS OpenDocument Technical Committee (TC) Basis of TC's work: OpenOffice.org XML file format OpenDocument TC Charter (Extract) The purpose [...] is to create an open, XML-based file format specification for office applications. [it] must meet the following requirements: it must be suitable for office documents containing text, spreadsheets, charts, and graphical documents, it must retain high-level information suitable for editing the document, it must be friendly to transformations using XSLT or similar XML-based languages or tools, it should 'borrow' from similar, existing standards wherever possible and permitted.
    [Show full text]
  • Comparing Libreoffice and Apache Openoffice Libreoffice and Apache Openoffice Both Are Derived from the Former Openoffice.Org Project
    Comparing LibreOffice and Apache OpenOffice LibreOffice and Apache OpenOffice both are derived from the former OpenOffice.org project. Over the years, the differences have grown and these documents offer a list of all the changes. This document is the starting point for the information comparing the two office suites. Time line showing the various releases AOO 3.4 4.0 4.1 LO 3.3 3.4 3.5 3.6 4.0 4.1 4.2 4.3 4.4 … 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13 2010 2011 2012 2103 2014 2015 Each ApacheOpenOffice release gets one update Each LibreOffice release typically gets 6 or 7 updates links to release information wiki.documentfoundation.org/ReleaseNotes/3.4 wiki.documentfoundation.org/ReleaseNotes/3.5 cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Release+Notes wiki.documentfoundation.org/ReleaseNotes/3. 6 wiki.documentfoundation.org/ReleaseNotes/ 4.0 cwiki.apache.org/confluence/display/OOOUSERS/AOO+ 4 . 0 +Release+Notes wiki.documentfoundation.org/ReleaseNotes/ 4.1 wiki.documentfoundation.org/ReleaseNotes/ 4.2 cwiki.apache.org/confluence/display/OOOUSERS/AOO+ 4 . 1 +Release+Notes wiki.documentfoundation.org/ReleaseNotes/ 4.3 wiki.documentfoundation.org/ReleaseNotes/ 4.4 Simply the office suites are composed of 3 'layers' 1.
    [Show full text]