User: jpmcc Date: 2009-02-17 18:01:00+0000 Modified: marketing/www/planet/atom.xml marketing/www/planet/index.html marketing/www/planet/opml.xml marketing/www/planet/rss10.xml marketing/www/planet/rss20.xml
Log: Planet run at Tue Feb 17 18:00:14 GMT 2009 File Changes: Directory: /marketing/www/planet/ ================================= File [changed]: atom.xml Url: http://marketing.openoffice.org/source/browse/marketing/www/planet/atom.xml?r1=1.1524&r2=1.1525 Delta lines: +33 -50 --------------------- --- atom.xml 2009-02-17 12:00:54+0000 1.1524 +++ atom.xml 2009-02-17 18:00:56+0000 1.1525 @@ -5,10 +5,34 @@ <link rel="self" href="http://marketing.openoffice.org/planet/atom.xml"/> <link href="http://marketing.openoffice.org/planet/"/> <id>http://marketing.openoffice.org/planet/atom.xml</id> - <updated>2009-02-17T12:00:23+00:00</updated> + <updated>2009-02-17T18:00:26+00:00</updated> <generator uri="http://www.planetplanet.org/";>Planet/2.0 +http://www.planetplanet.org</generator> <entry xml:lang="en"> + <title type="html">OpenOffice Downloads Outnumber PC Sales in Italy</title> + <link href="http://www.solidoffice.com/archives/1012"/> + <id>http://www.solidoffice.com/?p=1012</id> + <updated>2009-02-17T14:34:10+00:00</updated> + <content type="html"><p>OpenOffice.org community member and public relations professional Italo Vignoli posts &#8220;<a href="http://www.italovignoli.org/2009/02/the-price-of-success/">The Price of Success</a>&#8221; on his blog, in which he reveals that OpenOffice.org is being downloaded at a faster rate than new computers are being sold in Italy.</p> +<p>He suspects the same is true in Germany and France, and if Vignoli is correct, than three out of the four biggest national economies in the EU (UK is the fourth) are in the midst of a massive shift toward OpenOffice.org over competing office software suites:</p> +<blockquote><p>OpenOffice.org 3.0 has been a huge success, and this has raised the awareness of the open source office suite to an unprecedented level. In Europe, where OOo was already quite popular, especially in France, Germany and Italy, download numbers have reached new records. In Italy, they are now higher than the number of new PCs sold in the country, as they probably are in France and Germany (although I donât have PC figures for these two countries).</p></blockquote> +<p>Because of the slippery nature of download statistics as a measure of a software program&#8217;s usage share, Vignoli and his team in Italy have developed statistical methods to eliminate false data and better estimate the true impact OOo is having there.</p> +<blockquote><p>Downloads are a key measurement of OpenOffice.org success, although they represent a trend and canât be compared with licenses. This means that I am extremely careful in picking numbers when they donât follow a logical trend (i.e., an increase - not a jump - after the announcement of each new version, and then a slow decrease)&#8230; Most of the time, we ignore the numbers that we donât trust, even if this means that we ignore several &#8220;real&#8221; downloads.</p></blockquote> +<p>Even so, generally accepted knowledge indicates the number of OOo users exceeds the number of measured downloads, due to distribution through other methods like peer-to-peer networks, CDs, flash media (thumb or key drives), and others.</p></content> + <author> + <name>Benjamin Horst</name> + <uri>http://www.solidoffice.com</uri> + </author> + <source> + <title type="html">SolidOffice » OpenOffice.org</title> + <subtitle type="html">Home of The Tiny Guide to OpenOffice.org</subtitle> + <link rel="self" href="http://www.solidoffice.com/archives/category/openofficeorg/feed"/> + <id>http://www.solidoffice.com/archives/category/openofficeorg/feed</id> + <updated>2009-02-17T18:00:16+00:00</updated> + </source> + </entry> + + <entry xml:lang="en"> <title type="html">OpenOffice.org Conference 2009 Location</title> <link href="http://www.solidoffice.com/archives/1010"/> <id>http://www.solidoffice.com/?p=1010</id> @@ -34,7 +58,7 @@ <subtitle type="html">Home of The Tiny Guide to OpenOffice.org</subtitle> <link rel="self" href="http://www.solidoffice.com/archives/category/openofficeorg/feed"/> <id>http://www.solidoffice.com/archives/category/openofficeorg/feed</id> - <updated>2009-02-17T06:00:17+00:00</updated> + <updated>2009-02-17T18:00:16+00:00</updated> </source> </entry> @@ -171,7 +195,7 @@ <title type="html">jpmcc's shared items in Google Reader</title> <link rel="self" href="http://www.google.co.uk/reader/public/atom/user/06203502505240591501/state/com.google/broadcast"/> <id>tag:google.com,2005:reader/user/06203502505240591501/state/com.google/broadcast</id> - <updated>2009-02-17T12:00:17+00:00</updated> + <updated>2009-02-17T18:00:18+00:00</updated> </source> </entry> @@ -259,7 +283,7 @@ <title type="html">jpmcc's shared items in Google Reader</title> <link rel="self" href="http://www.google.co.uk/reader/public/atom/user/06203502505240591501/state/com.google/broadcast"/> <id>tag:google.com,2005:reader/user/06203502505240591501/state/com.google/broadcast</id> - <updated>2009-02-17T12:00:17+00:00</updated> + <updated>2009-02-17T18:00:18+00:00</updated> </source> </entry> @@ -338,7 +362,7 @@ <subtitle type="html">Home of The Tiny Guide to OpenOffice.org</subtitle> <link rel="self" href="http://www.solidoffice.com/archives/category/openofficeorg/feed"/> <id>http://www.solidoffice.com/archives/category/openofficeorg/feed</id> - <updated>2009-02-17T06:00:17+00:00</updated> + <updated>2009-02-17T18:00:16+00:00</updated> </source> </entry> @@ -460,7 +484,7 @@ <subtitle type="html">Home of The Tiny Guide to OpenOffice.org</subtitle> <link rel="self" href="http://www.solidoffice.com/archives/category/openofficeorg/feed"/> <id>http://www.solidoffice.com/archives/category/openofficeorg/feed</id> - <updated>2009-02-17T06:00:17+00:00</updated> + <updated>2009-02-17T18:00:16+00:00</updated> </source> </entry> @@ -533,7 +557,7 @@ <title type="html">jpmcc's shared items in Google Reader</title> <link rel="self" href="http://www.google.co.uk/reader/public/atom/user/06203502505240591501/state/com.google/broadcast"/> <id>tag:google.com,2005:reader/user/06203502505240591501/state/com.google/broadcast</id> - <updated>2009-02-17T12:00:17+00:00</updated> + <updated>2009-02-17T18:00:18+00:00</updated> </source> </entry> @@ -589,7 +613,7 @@ <subtitle type="html">Home of The Tiny Guide to OpenOffice.org</subtitle> <link rel="self" href="http://www.solidoffice.com/archives/category/openofficeorg/feed"/> <id>http://www.solidoffice.com/archives/category/openofficeorg/feed</id> - <updated>2009-02-17T06:00:17+00:00</updated> + <updated>2009-02-17T18:00:16+00:00</updated> </source> </entry> @@ -614,48 +638,7 @@ <subtitle type="html">Home of The Tiny Guide to OpenOffice.org</subtitle> <link rel="self" href="http://www.solidoffice.com/archives/category/openofficeorg/feed"/> <id>http://www.solidoffice.com/archives/category/openofficeorg/feed</id> - <updated>2009-02-17T06:00:17+00:00</updated> - </source> - </entry> - - <entry> - <title type="html">Proofreading in OpenOffice.org</title> - <link href="http://blogs.sun.com/GullFOSS/entry/proofreading_in_openoffice_org"/> - <id>tag:google.com,2005:reader/item/6054567a198767b8</id> - <updated>2009-02-06T16:32:22+00:00</updated> - <content type="html"><div> - <p lang="en-US">Grammar checking is a feature that was missed in OpenOffice.org for quite some time. Grammar checking software for several languages is available, either as standalone tools or integrated into other programs. I prefer the name âproofreadingâ for this kind of software, as usually these programs go beyond checking grammar. Some offer style checking, others may check text against abstract rules. In general the task for this kind of software is to check and improve text regarding anything else than simple spell checking (though it makes sense to include spell checking into the process as this helps to analyze the text).</p> - <p lang="en-US">How could we add proofreading to OpenOffice.org? Of course we didn't want to implement something by ourselves but use something that already exists, like we did with the Hunspell component that integrates spell checking into OOo using a simple API. But this API couldn't be used for proofreading as additional requirements had to be considered. On the other hand integrating proofreaders into OOo using existing core APIs was very tedious and an API for marking found errors was missing completely, so we had to come up with something new. Here's a simplified outline of the design we chose:</p> - <ul> - <li> - <p lang="en-US">While spell checking can be done based on single words for the majority of languages, this is not true for grammar checking and other proofreading jobs. So at least complete sentences have to be dealt with.</p> - </li> - <li> - <p lang="en-US">Determining sentence boundaries is not trivial; OOo's break iterator does a fair job, but a proofreader that is optimized for a particular language should be able to do it even better. So we decided to use paragraphs as the smallest unit passed along between OOo and a proofreader, together with indices pointing to sentence boundaries inside the paragraphs that are suggested by OOo's break iterator and can be overruled by the proofreader. As the proofreader is not interested in the particular formatting inside a paragraph, we won't bother it with the text portions and attributes inside the paragraph. There's no need to use com.sun.star.text.XText, no cursors etc. Instead of this we just hand over the paragraph content as a string, together with the mentioned sentence break indices. We call these objects âflat paragraphsâ.</p> - </li> - <li> - <p lang="en-US">The API to access text paragraphs in OOo documents may vary depending on where the text is located. Adding new features to OOo can result in new text elements with new access paths. If a proofreader was expected to know how to retrieve text from the various locations inside OOo, this alone would be a big burden we had put on the developers. But adding new locations could require code changes in the proofreader later on and it would be better to avoid that. So it was clear that accessing text and returning proofreading results (including the information which text should get wavy lines to mark errors) should abstract from the internal structure of the text and instead of that should represent the whole text of a document as a sequence of paragraphs that can simply be retrieved one by one. If the text changes suggested by the proofreader make it hard to merge them into the original text (e.g. because changes go across attribute boundaries), this should be handled inside the office code because that's where it can be done best and also once for all, not each time again in every proofreader.</p> - </li> - <li> - <p lang="en-US">Proofreading can be quite time consuming, so one must be careful to design the background checking process. We decided to run proof readers in a separate thread that needs synchronization with the Office main thread only in the time where the results for a paragraph are evaluated or the next paragraph is retrieved. The thread will be started by OOo, the proofreader does not need to take care for this, but it must be aware that it can be called in two different threads. Performance bottlenecks blocking the main thread that might show up are expected to happen in the office code handling flat paragraphs and fixing them will help all proofreaders. The multi threaded design will be nice especially for multi core CPUs where OOo will still have the same amount of CPU power for everything else than proofreading, now we just also make use of a second core.</p> - </li> - </ul> - <p> <span lang="en-US">In short words: our priorities for the API have been performance, simplicity and stability. Simplicity was important because we wanted to allow proofreader developers to concentrate on their problem domain and to bother them with our API peculiarities as little as possible. So did we succeed? The other day I came across a blog of</span> <a href="http://michel.weimerskirch.net/2009/01/31/implementation-of-the-eifeler-regel-for-openofficeorg/">Michel Weimerskirch</a> <span lang="en-US">who implemented some proofreading for Luxembourgian and he stated:</span></p> - <p>â <span lang="en-US"><i>Using the OpenOffice.org API plug-in for</i></span> <a href="http://www.netbeans.org/"><i>NetBeans</i></a> <span lang="en-US"><i>, I was able to quickly create a component that implements the</i></span> <i><span lang="en-US"><i>com.sun.star.linguistic2.XProofreader</i></span></i> <span lang="en-US"><i>interface, thus providing a basic proofreading service. Within less than three days I had a running implementation (as I said before, only the OOo API integration is new, the rest of the code comes from a previous implementation</i></span> <span lang="en-US">).â</span> <br /></p> - <div align="center"> <img border="0" src="http://blogs.sun.com/GullFOSS/resource/sbres_1233937159_0__.png" name="graphics1" /> <br /></div> - <p align="center"> <b><font size="4">Language Tool in action</font></b><br /> </p> - <p lang="en-US">So it seems that we are on the right track. Several other proofreaders are already done (see e.g. the <a href="http://extensions.services.openoffice.org/project/languagetool">Language Tool</a> that is already available or the <a href="http://www.duden.de/produkte/detail.php?isbn=3-411-06712-8&suchwort=OpenOffice&bereich=&reihe=&log=0">Duden Korrektor</a> that is going to be released soon) or are worked on, like e.g. <a href="http://sourceforge.net/projects/cogroo/">CoGrOO</a>. We have planned to provide an implementation skeleton in C++, perhaps someone else can provide one in Java. Hopefully this will speed up the implementation of proofreading extensions for OOo even more.</p> - <p lang="en-US">The new API also can enable us to integrate spell checkers for languages that don't work on single words, like Chinese. If anyone wants to try our new API to implement a proofreader or a CJK spell checker, please get in touch with us on dev(at)lingucomponent.openoffice.org.</p><br /> - </div></content> - <author> - <name>mathiasbauer</name> - <uri></uri> - </author> - <source> - <title type="html">jpmcc's shared items in Google Reader</title> - <link rel="self" href="http://www.google.co.uk/reader/public/atom/user/06203502505240591501/state/com.google/broadcast"/> - <id>tag:google.com,2005:reader/user/06203502505240591501/state/com.google/broadcast</id> - <updated>2009-02-17T12:00:17+00:00</updated> + <updated>2009-02-17T18:00:16+00:00</updated> </source> </entry> File [changed]: index.html Url: http://marketing.openoffice.org/source/browse/marketing/www/planet/index.html?r1=1.1531&r2=1.1532 Delta lines: +20 -38 --------------------- --- index.html 2009-02-17 12:00:55+0000 1.1531 +++ index.html 2009-02-17 18:00:57+0000 1.1532 @@ -37,12 +37,31 @@ <a href="rss20.xml"><img src="rss2.gif" alt="Link to RSS 2 feed" /></a> </div> -<p><em>Bloggings on marketing topics by project members - see <a href="#disclaimer">disclaimer</a>.<br />Last updated: February 17, 2009 12:00 PM GMT</em></p> +<p><em>Bloggings on marketing topics by project members - see <a href="#disclaimer">disclaimer</a>.<br />Last updated: February 17, 2009 06:00 PM GMT</em></p> <h2>February 17, 2009</h2> <h3> <a href="http://www.solidoffice.com"; title="SolidOffice » OpenOffice.org"> Benjamin Horst</a> : +<a href="http://www.solidoffice.com/archives/1012";> +OpenOffice Downloads Outnumber PC Sales in Italy</a> +</h3> +<p> +<p>OpenOffice.org community member and public relations professional Italo Vignoli posts “<a href="http://www.italovignoli.org/2009/02/the-price-of-success/";>The Price of Success</a>” on his blog, in which he reveals that OpenOffice.org is being downloaded at a faster rate than new computers are being sold in Italy.</p> +<p>He suspects the same is true in Germany and France, and if Vignoli is correct, than three out of the four biggest national economies in the EU (UK is the fourth) are in the midst of a massive shift toward OpenOffice.org over competing office software suites:</p> +<blockquote><p>OpenOffice.org 3.0 has been a huge success, and this has raised the awareness of the open source office suite to an unprecedented level. In Europe, where OOo was already quite popular, especially in France, Germany and Italy, download numbers have reached new records. In Italy, they are now higher than the number of new PCs sold in the country, as they probably are in France and Germany (although I donât have PC figures for these two countries).</p></blockquote> +<p>Because of the slippery nature of download statistics as a measure of a software program’s usage share, Vignoli and his team in Italy have developed statistical methods to eliminate false data and better estimate the true impact OOo is having there.</p> +<blockquote><p>Downloads are a key measurement of OpenOffice.org success, although they represent a trend and canât be compared with licenses. This means that I am extremely careful in picking numbers when they donât follow a logical trend (i.e., an increase - not a jump - after the announcement of each new version, and then a slow decrease)… Most of the time, we ignore the numbers that we donât trust, even if this means that we ignore several “real” downloads.</p></blockquote> +<p>Even so, generally accepted knowledge indicates the number of OOo users exceeds the number of measured downloads, due to distribution through other methods like peer-to-peer networks, CDs, flash media (thumb or key drives), and others.</p></p> +<p> +<em><a href="http://www.solidoffice.com/archives/1012";>by Benjamin Horst at February 17, 2009 02:34 PM GMT</a></em> +</p> +<br /> +<hr /> +<br /> +<h3> +<a href="http://www.solidoffice.com"; title="SolidOffice » OpenOffice.org"> +Benjamin Horst</a> : <a href="http://www.solidoffice.com/archives/1010";> OpenOffice.org Conference 2009 Location</a> </h3> @@ -565,43 +584,6 @@ <br /> <hr /> <br /> -<h3> -<a href="" title="jpmcc's shared items in Google Reader"> -GullFOSS</a> : -<a href="http://blogs.sun.com/GullFOSS/entry/proofreading_in_openoffice_org";> -Proofreading in OpenOffice.org</a> -</h3> -<p> -<div> - <p lang="en-US">Grammar checking is a feature that was missed in OpenOffice.org for quite some time. Grammar checking software for several languages is available, either as standalone tools or integrated into other programs. I prefer the name âproofreadingâ for this kind of software, as usually these programs go beyond checking grammar. Some offer style checking, others may check text against abstract rules. In general the task for this kind of software is to check and improve text regarding anything else than simple spell checking (though it makes sense to include spell checking into the process as this helps to analyze the text).</p> - <p lang="en-US">How could we add proofreading to OpenOffice.org? Of course we didn't want to implement something by ourselves but use something that already exists, like we did with the Hunspell component that integrates spell checking into OOo using a simple API. But this API couldn't be used for proofreading as additional requirements had to be considered. On the other hand integrating proofreaders into OOo using existing core APIs was very tedious and an API for marking found errors was missing completely, so we had to come up with something new. Here's a simplified outline of the design we chose:</p> - <ul> - <li> - <p lang="en-US">While spell checking can be done based on single words for the majority of languages, this is not true for grammar checking and other proofreading jobs. So at least complete sentences have to be dealt with.</p> - </li> - <li> - <p lang="en-US">Determining sentence boundaries is not trivial; OOo's break iterator does a fair job, but a proofreader that is optimized for a particular language should be able to do it even better. So we decided to use paragraphs as the smallest unit passed along between OOo and a proofreader, together with indices pointing to sentence boundaries inside the paragraphs that are suggested by OOo's break iterator and can be overruled by the proofreader. As the proofreader is not interested in the particular formatting inside a paragraph, we won't bother it with the text portions and attributes inside the paragraph. There's no need to use com.sun.star.text.XText, no cursors etc. Instead of this we just hand over the paragraph content as a string, together with the mentioned sentence break indices. We call these objects âflat paragraphsâ.</p> - </li> - <li> - <p lang="en-US">The API to access text paragraphs in OOo documents may vary depending on where the text is located. Adding new features to OOo can result in new text elements with new access paths. If a proofreader was expected to know how to retrieve text from the various locations inside OOo, this alone would be a big burden we had put on the developers. But adding new locations could require code changes in the proofreader later on and it would be better to avoid that. So it was clear that accessing text and returning proofreading results (including the information which text should get wavy lines to mark errors) should abstract from the internal structure of the text and instead of that should represent the whole text of a document as a sequence of paragraphs that can simply be retrieved one by one. If the text changes suggested by the proofreader make it hard to merge them into the original text (e.g. because changes go across attribute boundaries), this should be handled inside the office code because that's where it can be done best and also once for all, not each time again in every proofreader.</p> - </li> - <li> - <p lang="en-US">Proofreading can be quite time consuming, so one must be careful to design the background checking process. We decided to run proof readers in a separate thread that needs synchronization with the Office main thread only in the time where the results for a paragraph are evaluated or the next paragraph is retrieved. The thread will be started by OOo, the proofreader does not need to take care for this, but it must be aware that it can be called in two different threads. Performance bottlenecks blocking the main thread that might show up are expected to happen in the office code handling flat paragraphs and fixing them will help all proofreaders. The multi threaded design will be nice especially for multi core CPUs where OOo will still have the same amount of CPU power for everything else than proofreading, now we just also make use of a second core.</p> - </li> - </ul> - <p> <span lang="en-US">In short words: our priorities for the API have been performance, simplicity and stability. Simplicity was important because we wanted to allow proofreader developers to concentrate on their problem domain and to bother them with our API peculiarities as little as possible. So did we succeed? The other day I came across a blog of</span> <a href="http://michel.weimerskirch.net/2009/01/31/implementation-of-the-eifeler-regel-for-openofficeorg/";>Michel Weimerskirch</a> <span lang="en-US">who implemented some proofreading for Luxembourgian and he stated:</span></p> - <p>â <span lang="en-US"><i>Using the OpenOffice.org API plug-in for</i></span> <a href="http://www.netbeans.org/";><i>NetBeans</i></a> <span lang="en-US"><i>, I was able to quickly create a component that implements the</i></span> <i><span lang="en-US"><i>com.sun.star.linguistic2.XProofreader</i></span></i> <span lang="en-US"><i>interface, thus providing a basic proofreading service. Within less than three days I had a running implementation (as I said before, only the OOo API integration is new, the rest of the code comes from a previous implementation</i></span> <span lang="en-US">).â</span> <br /></p> - <div align="center"> <img border="0" src="http://blogs.sun.com/GullFOSS/resource/sbres_1233937159_0__.png"; name="graphics1" /> <br /></div> - <p align="center"> <b><font size="4">Language Tool in action</font></b><br /> </p> - <p lang="en-US">So it seems that we are on the right track. Several other proofreaders are already done (see e.g. the <a href="http://extensions.services.openoffice.org/project/languagetool";>Language Tool</a> that is already available or the <a href="http://www.duden.de/produkte/detail.php?isbn=3-411-06712-8&suchwort=OpenOffice&bereich=&reihe=&log=0";>Duden Korrektor</a> that is going to be released soon) or are worked on, like e.g. <a href="http://sourceforge.net/projects/cogroo/";>CoGrOO</a>. We have planned to provide an implementation skeleton in C++, perhaps someone else can provide one in Java. Hopefully this will speed up the implementation of proofreading extensions for OOo even more.</p> - <p lang="en-US">The new API also can enable us to integrate spell checkers for languages that don't work on single words, like Chinese. If anyone wants to try our new API to implement a proofreader or a CJK spell checker, please get in touch with us on dev(at)lingucomponent.openoffice.org.</p><br /> - </div></p> -<p> -<em><a href="http://blogs.sun.com/GullFOSS/entry/proofreading_in_openoffice_org";>by mathiasbauer at February 06, 2009 04:32 PM GMT</a></em> -</p> -<br /> -<hr /> -<br /> <a id="disclaimer" name="disclaimer"></a> <p><em>Disclaimer: all views expressed on this page are those of the individual contributors, and may not reflect the views of the File [changed]: opml.xml Url: http://marketing.openoffice.org/source/browse/marketing/www/planet/opml.xml?r1=1.1524&r2=1.1525 Delta lines: +1 -1 ------------------- --- opml.xml 2009-02-17 12:00:56+0000 1.1524 +++ opml.xml 2009-02-17 18:00:57+0000 1.1525 @@ -2,7 +2,7 @@ <opml version="1.1"> <head> <title>Marketing Planet</title> - <dateModified>Tue, 17 Feb 2009 12:00:24 +0000</dateModified> + <dateModified>Tue, 17 Feb 2009 18:00:26 +0000</dateModified> <ownerName>Marketing Project</ownerName> <ownerEmail>[email protected]</ownerEmail> </head> File [changed]: rss10.xml Url: http://marketing.openoffice.org/source/browse/marketing/www/planet/rss10.xml?r1=1.644&r2=1.645 Delta lines: +12 -31 --------------------- --- rss10.xml 2009-02-17 06:01:01+0000 1.644 +++ rss10.xml 2009-02-17 18:00:57+0000 1.645 @@ -13,6 +13,7 @@ <items> <rdf:Seq> + <rdf:li rdf:resource="http://www.solidoffice.com/?p=1012"; /> <rdf:li rdf:resource="http://www.solidoffice.com/?p=1010"; /> <rdf:li rdf:resource="http://www.italovignoli.org/2009/02/economic-models-of-free-software/"; /> <rdf:li rdf:resource="http://www.italovignoli.org/2009/02/anti-aliasing-is-done-for-ooo-31/"; /> @@ -32,11 +33,21 @@ <rdf:li rdf:resource="http://www.italovignoli.org/2009/02/mobile-posting/"; /> <rdf:li rdf:resource="http://www.solidoffice.com/?p=1000"; /> <rdf:li rdf:resource="http://www.solidoffice.com/?p=998"; /> - <rdf:li rdf:resource="tag:google.com,2005:reader/item/6054567a198767b8" /> </rdf:Seq> </items> </channel> +<item rdf:about="http://www.solidoffice.com/?p=1012";> + <title>Benjamin Horst: OpenOffice Downloads Outnumber PC Sales in Italy</title> + <link>http://www.solidoffice.com/archives/1012</link> + <content:encoded><p>OpenOffice.org community member and public relations professional Italo Vignoli posts &#8220;<a href="http://www.italovignoli.org/2009/02/the-price-of-success/">The Price of Success</a>&#8221; on his blog, in which he reveals that OpenOffice.org is being downloaded at a faster rate than new computers are being sold in Italy.</p> +<p>He suspects the same is true in Germany and France, and if Vignoli is correct, than three out of the four biggest national economies in the EU (UK is the fourth) are in the midst of a massive shift toward OpenOffice.org over competing office software suites:</p> +<blockquote><p>OpenOffice.org 3.0 has been a huge success, and this has raised the awareness of the open source office suite to an unprecedented level. In Europe, where OOo was already quite popular, especially in France, Germany and Italy, download numbers have reached new records. In Italy, they are now higher than the number of new PCs sold in the country, as they probably are in France and Germany (although I donât have PC figures for these two countries).</p></blockquote> +<p>Because of the slippery nature of download statistics as a measure of a software program&#8217;s usage share, Vignoli and his team in Italy have developed statistical methods to eliminate false data and better estimate the true impact OOo is having there.</p> +<blockquote><p>Downloads are a key measurement of OpenOffice.org success, although they represent a trend and canât be compared with licenses. This means that I am extremely careful in picking numbers when they donât follow a logical trend (i.e., an increase - not a jump - after the announcement of each new version, and then a slow decrease)&#8230; Most of the time, we ignore the numbers that we donât trust, even if this means that we ignore several &#8220;real&#8221; downloads.</p></blockquote> +<p>Even so, generally accepted knowledge indicates the number of OOo users exceeds the number of measured downloads, due to distribution through other methods like peer-to-peer networks, CDs, flash media (thumb or key drives), and others.</p></content:encoded> + <dc:date>2009-02-17T14:34:10+00:00</dc:date> +</item> <item rdf:about="http://www.solidoffice.com/?p=1010";> <title>Benjamin Horst: OpenOffice.org Conference 2009 Location</title> <link>http://www.solidoffice.com/archives/1010</link> @@ -406,35 +417,5 @@ <p>Each one of the presentations was recorded and can be viewed on Learn 4 Life&#8217;s blog linked above.</p></content:encoded> <dc:date>2009-02-06T21:07:32+00:00</dc:date> </item> -<item rdf:about="tag:google.com,2005:reader/item/6054567a198767b8"> - <title>GullFOSS: Proofreading in OpenOffice.org</title> - <link>http://blogs.sun.com/GullFOSS/entry/proofreading_in_openoffice_org</link> - <content:encoded><div> - <p lang="en-US">Grammar checking is a feature that was missed in OpenOffice.org for quite some time. Grammar checking software for several languages is available, either as standalone tools or integrated into other programs. I prefer the name âproofreadingâ for this kind of software, as usually these programs go beyond checking grammar. Some offer style checking, others may check text against abstract rules. In general the task for this kind of software is to check and improve text regarding anything else than simple spell checking (though it makes sense to include spell checking into the process as this helps to analyze the text).</p> - <p lang="en-US">How could we add proofreading to OpenOffice.org? Of course we didn't want to implement something by ourselves but use something that already exists, like we did with the Hunspell component that integrates spell checking into OOo using a simple API. But this API couldn't be used for proofreading as additional requirements had to be considered. On the other hand integrating proofreaders into OOo using existing core APIs was very tedious and an API for marking found errors was missing completely, so we had to come up with something new. Here's a simplified outline of the design we chose:</p> - <ul> - <li> - <p lang="en-US">While spell checking can be done based on single words for the majority of languages, this is not true for grammar checking and other proofreading jobs. So at least complete sentences have to be dealt with.</p> - </li> - <li> - <p lang="en-US">Determining sentence boundaries is not trivial; OOo's break iterator does a fair job, but a proofreader that is optimized for a particular language should be able to do it even better. So we decided to use paragraphs as the smallest unit passed along between OOo and a proofreader, together with indices pointing to sentence boundaries inside the paragraphs that are suggested by OOo's break iterator and can be overruled by the proofreader. As the proofreader is not interested in the particular formatting inside a paragraph, we won't bother it with the text portions and attributes inside the paragraph. There's no need to use com.sun.star.text.XText, no cursors etc. Instead of this we just hand over the paragraph content as a string, together with the mentioned sentence break indices. We call these objects âflat paragraphsâ.</p> - </li> - <li> - <p lang="en-US">The API to access text paragraphs in OOo documents may vary depending on where the text is located. Adding new features to OOo can result in new text elements with new access paths. If a proofreader was expected to know how to retrieve text from the various locations inside OOo, this alone would be a big burden we had put on the developers. But adding new locations could require code changes in the proofreader later on and it would be better to avoid that. So it was clear that accessing text and returning proofreading results (including the information which text should get wavy lines to mark errors) should abstract from the internal structure of the text and instead of that should represent the whole text of a document as a sequence of paragraphs that can simply be retrieved one by one. If the text changes suggested by the proofreader make it hard to merge them into the original text (e.g. because changes go across attribute boundaries), this should be handled inside the office code because that's where it can be done best and also once for all, not each time again in every proofreader.</p> - </li> - <li> - <p lang="en-US">Proofreading can be quite time consuming, so one must be careful to design the background checking process. We decided to run proof readers in a separate thread that needs synchronization with the Office main thread only in the time where the results for a paragraph are evaluated or the next paragraph is retrieved. The thread will be started by OOo, the proofreader does not need to take care for this, but it must be aware that it can be called in two different threads. Performance bottlenecks blocking the main thread that might show up are expected to happen in the office code handling flat paragraphs and fixing them will help all proofreaders. The multi threaded design will be nice especially for multi core CPUs where OOo will still have the same amount of CPU power for everything else than proofreading, now we just also make use of a second core.</p> - </li> - </ul> - <p> <span lang="en-US">In short words: our priorities for the API have been performance, simplicity and stability. Simplicity was important because we wanted to allow proofreader developers to concentrate on their problem domain and to bother them with our API peculiarities as little as possible. So did we succeed? The other day I came across a blog of</span> <a href="http://michel.weimerskirch.net/2009/01/31/implementation-of-the-eifeler-regel-for-openofficeorg/">Michel Weimerskirch</a> <span lang="en-US">who implemented some proofreading for Luxembourgian and he stated:</span></p> - <p>â <span lang="en-US"><i>Using the OpenOffice.org API plug-in for</i></span> <a href="http://www.netbeans.org/"><i>NetBeans</i></a> <span lang="en-US"><i>, I was able to quickly create a component that implements the</i></span> <i><span lang="en-US"><i>com.sun.star.linguistic2.XProofreader</i></span></i> <span lang="en-US"><i>interface, thus providing a basic proofreading service. Within less than three days I had a running implementation (as I said before, only the OOo API integration is new, the rest of the code comes from a previous implementation</i></span> <span lang="en-US">).â</span> <br /></p> - <div align="center"> <img border="0" src="http://blogs.sun.com/GullFOSS/resource/sbres_1233937159_0__.png" name="graphics1" /> <br /></div> - <p align="center"> <b><font size="4">Language Tool in action</font></b><br /> </p> - <p lang="en-US">So it seems that we are on the right track. Several other proofreaders are already done (see e.g. the <a href="http://extensions.services.openoffice.org/project/languagetool">Language Tool</a> that is already available or the <a href="http://www.duden.de/produkte/detail.php?isbn=3-411-06712-8&suchwort=OpenOffice&bereich=&reihe=&log=0">Duden Korrektor</a> that is going to be released soon) or are worked on, like e.g. <a href="http://sourceforge.net/projects/cogroo/">CoGrOO</a>. We have planned to provide an implementation skeleton in C++, perhaps someone else can provide one in Java. Hopefully this will speed up the implementation of proofreading extensions for OOo even more.</p> - <p lang="en-US">The new API also can enable us to integrate spell checkers for languages that don't work on single words, like Chinese. If anyone wants to try our new API to implement a proofreader or a CJK spell checker, please get in touch with us on dev(at)lingucomponent.openoffice.org.</p><br /> - </div></content:encoded> - <dc:date>2009-02-06T16:32:22+00:00</dc:date> - <dc:creator>mathiasbauer</dc:creator> -</item> </rdf:RDF> File [changed]: rss20.xml Url: http://marketing.openoffice.org/source/browse/marketing/www/planet/rss20.xml?r1=1.644&r2=1.645 Delta lines: +12 -30 --------------------- --- rss20.xml 2009-02-17 06:01:01+0000 1.644 +++ rss20.xml 2009-02-17 18:00:57+0000 1.645 @@ -8,6 +8,18 @@ <description>Marketing Planet - http://marketing.openoffice.org/planet/</description> <item> + <title>Benjamin Horst: OpenOffice Downloads Outnumber PC Sales in Italy</title> + <guid>http://www.solidoffice.com/?p=1012</guid> + <link>http://www.solidoffice.com/archives/1012</link> + <description><p>OpenOffice.org community member and public relations professional Italo Vignoli posts &#8220;<a href="http://www.italovignoli.org/2009/02/the-price-of-success/">The Price of Success</a>&#8221; on his blog, in which he reveals that OpenOffice.org is being downloaded at a faster rate than new computers are being sold in Italy.</p> +<p>He suspects the same is true in Germany and France, and if Vignoli is correct, than three out of the four biggest national economies in the EU (UK is the fourth) are in the midst of a massive shift toward OpenOffice.org over competing office software suites:</p> +<blockquote><p>OpenOffice.org 3.0 has been a huge success, and this has raised the awareness of the open source office suite to an unprecedented level. In Europe, where OOo was already quite popular, especially in France, Germany and Italy, download numbers have reached new records. In Italy, they are now higher than the number of new PCs sold in the country, as they probably are in France and Germany (although I donât have PC figures for these two countries).</p></blockquote> +<p>Because of the slippery nature of download statistics as a measure of a software program&#8217;s usage share, Vignoli and his team in Italy have developed statistical methods to eliminate false data and better estimate the true impact OOo is having there.</p> +<blockquote><p>Downloads are a key measurement of OpenOffice.org success, although they represent a trend and canât be compared with licenses. This means that I am extremely careful in picking numbers when they donât follow a logical trend (i.e., an increase - not a jump - after the announcement of each new version, and then a slow decrease)&#8230; Most of the time, we ignore the numbers that we donât trust, even if this means that we ignore several &#8220;real&#8221; downloads.</p></blockquote> +<p>Even so, generally accepted knowledge indicates the number of OOo users exceeds the number of measured downloads, due to distribution through other methods like peer-to-peer networks, CDs, flash media (thumb or key drives), and others.</p></description> + <pubDate>Tue, 17 Feb 2009 14:34:10 +0000</pubDate> +</item> +<item> <title>Benjamin Horst: OpenOffice.org Conference 2009 Location</title> <guid>http://www.solidoffice.com/?p=1010</guid> <link>http://www.solidoffice.com/archives/1010</link> @@ -392,36 +404,6 @@ <p>Each one of the presentations was recorded and can be viewed on Learn 4 Life&#8217;s blog linked above.</p></description> <pubDate>Fri, 06 Feb 2009 21:07:32 +0000</pubDate> </item> -<item> - <title>GullFOSS: Proofreading in OpenOffice.org</title> - <guid>tag:google.com,2005:reader/item/6054567a198767b8</guid> - <link>http://blogs.sun.com/GullFOSS/entry/proofreading_in_openoffice_org</link> - <description><div> - <p lang="en-US">Grammar checking is a feature that was missed in OpenOffice.org for quite some time. Grammar checking software for several languages is available, either as standalone tools or integrated into other programs. I prefer the name âproofreadingâ for this kind of software, as usually these programs go beyond checking grammar. Some offer style checking, others may check text against abstract rules. In general the task for this kind of software is to check and improve text regarding anything else than simple spell checking (though it makes sense to include spell checking into the process as this helps to analyze the text).</p> - <p lang="en-US">How could we add proofreading to OpenOffice.org? Of course we didn't want to implement something by ourselves but use something that already exists, like we did with the Hunspell component that integrates spell checking into OOo using a simple API. But this API couldn't be used for proofreading as additional requirements had to be considered. On the other hand integrating proofreaders into OOo using existing core APIs was very tedious and an API for marking found errors was missing completely, so we had to come up with something new. Here's a simplified outline of the design we chose:</p> - <ul> - <li> - <p lang="en-US">While spell checking can be done based on single words for the majority of languages, this is not true for grammar checking and other proofreading jobs. So at least complete sentences have to be dealt with.</p> - </li> - <li> - <p lang="en-US">Determining sentence boundaries is not trivial; OOo's break iterator does a fair job, but a proofreader that is optimized for a particular language should be able to do it even better. So we decided to use paragraphs as the smallest unit passed along between OOo and a proofreader, together with indices pointing to sentence boundaries inside the paragraphs that are suggested by OOo's break iterator and can be overruled by the proofreader. As the proofreader is not interested in the particular formatting inside a paragraph, we won't bother it with the text portions and attributes inside the paragraph. There's no need to use com.sun.star.text.XText, no cursors etc. Instead of this we just hand over the paragraph content as a string, together with the mentioned sentence break indices. We call these objects âflat paragraphsâ.</p> - </li> - <li> - <p lang="en-US">The API to access text paragraphs in OOo documents may vary depending on where the text is located. Adding new features to OOo can result in new text elements with new access paths. If a proofreader was expected to know how to retrieve text from the various locations inside OOo, this alone would be a big burden we had put on the developers. But adding new locations could require code changes in the proofreader later on and it would be better to avoid that. So it was clear that accessing text and returning proofreading results (including the information which text should get wavy lines to mark errors) should abstract from the internal structure of the text and instead of that should represent the whole text of a document as a sequence of paragraphs that can simply be retrieved one by one. If the text changes suggested by the proofreader make it hard to merge them into the original text (e.g. because changes go across attribute boundaries), this should be handled inside the office code because that's where it can be done best and also once for all, not each time again in every proofreader.</p> - </li> - <li> - <p lang="en-US">Proofreading can be quite time consuming, so one must be careful to design the background checking process. We decided to run proof readers in a separate thread that needs synchronization with the Office main thread only in the time where the results for a paragraph are evaluated or the next paragraph is retrieved. The thread will be started by OOo, the proofreader does not need to take care for this, but it must be aware that it can be called in two different threads. Performance bottlenecks blocking the main thread that might show up are expected to happen in the office code handling flat paragraphs and fixing them will help all proofreaders. The multi threaded design will be nice especially for multi core CPUs where OOo will still have the same amount of CPU power for everything else than proofreading, now we just also make use of a second core.</p> - </li> - </ul> - <p> <span lang="en-US">In short words: our priorities for the API have been performance, simplicity and stability. Simplicity was important because we wanted to allow proofreader developers to concentrate on their problem domain and to bother them with our API peculiarities as little as possible. So did we succeed? The other day I came across a blog of</span> <a href="http://michel.weimerskirch.net/2009/01/31/implementation-of-the-eifeler-regel-for-openofficeorg/">Michel Weimerskirch</a> <span lang="en-US">who implemented some proofreading for Luxembourgian and he stated:</span></p> - <p>â <span lang="en-US"><i>Using the OpenOffice.org API plug-in for</i></span> <a href="http://www.netbeans.org/"><i>NetBeans</i></a> <span lang="en-US"><i>, I was able to quickly create a component that implements the</i></span> <i><span lang="en-US"><i>com.sun.star.linguistic2.XProofreader</i></span></i> <span lang="en-US"><i>interface, thus providing a basic proofreading service. Within less than three days I had a running implementation (as I said before, only the OOo API integration is new, the rest of the code comes from a previous implementation</i></span> <span lang="en-US">).â</span> <br /></p> - <div align="center"> <img border="0" src="http://blogs.sun.com/GullFOSS/resource/sbres_1233937159_0__.png" name="graphics1" /> <br /></div> - <p align="center"> <b><font size="4">Language Tool in action</font></b><br /> </p> - <p lang="en-US">So it seems that we are on the right track. Several other proofreaders are already done (see e.g. the <a href="http://extensions.services.openoffice.org/project/languagetool">Language Tool</a> that is already available or the <a href="http://www.duden.de/produkte/detail.php?isbn=3-411-06712-8&suchwort=OpenOffice&bereich=&reihe=&log=0">Duden Korrektor</a> that is going to be released soon) or are worked on, like e.g. <a href="http://sourceforge.net/projects/cogroo/">CoGrOO</a>. We have planned to provide an implementation skeleton in C++, perhaps someone else can provide one in Java. Hopefully this will speed up the implementation of proofreading extensions for OOo even more.</p> - <p lang="en-US">The new API also can enable us to integrate spell checkers for languages that don't work on single words, like Chinese. If anyone wants to try our new API to implement a proofreader or a CJK spell checker, please get in touch with us on dev(at)lingucomponent.openoffice.org.</p><br /> - </div></description> - <pubDate>Fri, 06 Feb 2009 16:32:22 +0000</pubDate> -</item> </channel> </rss> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
![http://blogs.sun.com/GullFOSS/resource/sbres_1233937159_0__.png"](http://blogs.sun.com/GullFOSS/resource/sbres_1233937159_0__.png"){kind=link}
![http://blogs.sun.com/GullFOSS/resource/sbres_1233937159_0__.png"](http://blogs.sun.com/GullFOSS/resource/sbres_1233937159_0__.png"){kind=link}