Announcing Apache OpenOffice 4.1.3

12 October 2016 - Apache OpenOffice, the leading Open Source office document productivity suite, announced today Apache OpenOffice 4.1.3, now available in 41 languages on Windows, OS X and Linux.

Apache OpenOffice 4.1.3 is a maintenance release incorporating important bug fixes, security fixes, updated dictionaries, and build fixes. All users of Apache OpenOffice 4.1.2 or earlier are advised to upgrade.

Main improvements include:

• Key security vulnerability fixes
• Support for new language dictionaries 
• Numerous bug fixes, including installer and database support on OS X 
• Enhancements to the build tools (for developers)

A complete list of the issues fixed in this release can be found at https://s.apache.org/t0wh

For a complete list of available languages and language packs see: http://www.openoffice.org/download/

Details of new features and enhancements in this release are described in th Release Notes.

Those interested in the source code can download it at http://s.apache.org/Bsr.

You are encouraged to subscribe to the Apache OpenOffice announcement mailing list to receive important notifications such as product updates and security patches.  To subscribe you can send an email to:  announce-subscribe-AT-openoffice.apache-DOT-org.

You can also follow the project on Twitter, Facebook and Google+.

Posted at 09:46PM Oct 12, 2016 by marcus in General  |   | 

Apache OpenOffice in 2013: a year in review

 2013 has been an exciting year for the OpenOffice project and community.

 Click on the picture below to start a slideshow with highlights from 2013. A text-only version is under the picture.

• January: Apache OpenOffice 3.4.1 is released in 8 additional languages (Danish, Norwegian, Swedish, Korean, Polish, Basque, Asturian and Scottish Gaelic) thanks to the work of new translation volunteers.
  OpenOffice supports 120+ languages, but only those that are 100% translated and maintained are officially released.
• February: OpenOffice comes back to FOSDEM, one of the most popular Free and Open Source Conferences in Europe, with a dedicated devroom and a stand.
• March: Apache OpenOffice starts integrating improvements from IBM Lotus Symphony, a previous fork that is now closed and donated to the Apache Software Foundation.
  The integrated improvements bring better compatibility with Microsoft Office documents.
• April: It's time for a radical improvement of the OpenOffice user interface.
  The first major change in years, the Sidebar, is done by the Apache OpenOffice "dream team" in Hamburg in close cooperation with hundreds of other community members.
  The code, distributed under the Apache License 2.0, is promptly reused by other projects.
• May: After a long selection process that saw over 5000 votes cast, a new logo is selected for OpenOffice 4. The winning proposal is submitted by community member Chris Rottensteiner, from South Tyrol.
• June: The social media presence of Apache OpenOffice grows.
  The Facebook fan page at https://facebook.com/ApacheOO has about 40 new fans per day and reached the 10,000 fans milestone in 2013.
  The official Twitter account at https://twitter.com/apacheoo has more than 2,000 followers.
• July: Apache OpenOffice 4.0 is released.
  OpenOffice 4.0 features an innovative new Sidebar user interface, additional language support for 22 languages (including 3 new languages), 500 bug fixes, improvements in Microsoft Office interoperability, enhancements to drawing/graphics, performance improvements, etc.
  The full list of improvements is available on the project's community wiki.
  Apache OpenOffice 4.0 is downloaded at an impressive rate, about 1 million downloads per week.
• August: The official repositories for Apache OpenOffice Extensions and Templates are refreshed.
  The updates bring to the two community sites get a nicer search functionality, social media sharing features, better spam control and many other improvements.
  The sites offer more than 750 extensions at http://extensions.openoffice.org and more than 2,800 templates at http://templates.openoffice.org
• September: The Apache OpenOffice Forum reaches 60,000 registered users.
  The official forum at https://forum.openoffice.org is the most used channel for user support, averaging over 100 posts per day and accumulating over 270,000 posts about Apache OpenOffice and all derivatives.
  The Forum and Wiki benefited from a number of infrastructure improvements in 2013, thanks to the Apache Infra team.
• October: Apache OpenOffice 4.0.1 is released. It is a maintenance release which fixes critical issues and improves the overall quality of the application.
  General areas of improvement include: additional native language translations, bug fixes, performance improvements and Windows 8 compatibility enhancements.
  The full release notes are available on the project's community wiki.
• November: Apache OpenOffice successfully integrates support for the Microsoft Active Accessibility (MSAA) and IAccessible2 interfaces.
  Support for these interfaces enables screen readers and other assistive technologies to work with Apache OpenOffice, which in turn enables greater productivity by OpenOffice users who are blind or who have low-vision.
  With the new accessibility support OpenOffice becomes even more attractive for use by governments and public institutions, like the administrative region of Emilia-Romagna, in Italy, that recently announced a migration to OpenOffice.
• December: Apache OpenOffice reaches 85,000,000 downloads.
  According to the statistics provided by SourceForge, that hosts the official downloads, the English version is the most downloaded one, followed by French, German, Italian, Spanish, Japanese and Russian.
  The Apache OpenOffice porting page at http://openoffice.org/porting lists other versions, such as a portable version for Windows, the PrOOo-box software collection in German, and AndrOpen Office, an Android port of Apache OpenOffice available since June 2013.

Have a nice 2014!

Posted at 01:48PM Dec 31, 2013 by pescetti in General  |  Comments [2]  | 

Call For Designers: Apache OpenOffice 4.0 Brand Refresh Project

Apache OpenOffice is looking for a refreshed logo and branding for its upcoming 4.0 release.

This is a tremendous opportunity for designers to get involved in one of the most popular free and open source projects, and to get their work displayed to dozens of million of users: Apache OpenOffice just celebrated 40 million downloads in less than ten months.

Brand Refresh Project Scope

Required:

• An AOO Logo

Considerations:

• Can be altered for use in splash screens, about screens, publications, website, elements in application icons, etc.
• Brand proposals that show more than just a logo, considering placement in the areas of focus such as splash screen and websites.

Primary Requirements

• Logo submissions must include the source.
• Logos can be as large as the designer wishes, but must be able to scale down and not loose detail. eg.. for website, splash screen, etc.
• Although text in the logo is optional, any font used must be a free and open font. eg. SIL Open Source Fonts.  Any font used in the logo must be disclosed upon submission.
• Incorporation of gulls literally or symbolically, but not necessarily the existing shape used in current branding.

If you are interested, please read the full Brand Refresh Project page (including the "child pages" at the bottom) to get more background, see what other volunteers are proposing and learn how you can contribute!

Posted at 05:12PM Mar 06, 2013 by pescetti in General  |  Comments [5]  | 

OpenOffice downloaded once - used and installed as often you want

One major advantage of OpenOffice is that it is open source and that the license allows you to use and install it as often you want. Once you have downloaded OpenOffice you can share it with as many other people as you like or install it on as many computers as you need. No limits!

The project likes to count downloads because high download numbers are our motivation and if you want they are the indirect payment for all the volunteers. But we are also happy if you share your download with many other people or inside your company. If you do so please share your success stories of bigger deployments with us and we are happy to share your experience via our blog here. Keep in mind that sharing your experience, your success with other users in the community is also one kind of contribution to help the eco-system around OpenOffice growing.

Posted at 04:45PM Feb 19, 2013 by jsc in General  |   | 

Random Numbers in Calc: Small Enhancements That Can Make a Difference

RAND() is one of those barely noticeable functions that seem to be trivial and a given in modern spreadsheets. The truth behind RAND() and other functions that try to simulate the real world in some way is that they are extremely difficult, and maybe even impossible, to do correctly.
Historically OpenOffice Calc used a very naïve random number generation function based on the system's libc. The system libc version is usually very outdated and is only meant to produce very limited results, but perhaps more dangerously such a random number generator is system dependent so moving your work from one system to another will cause problems or at least changing behaviours.

As soon as I noticed that OpenOffice used such an obsolete function I thought it would be easy to replace this with some modern algorithm that could guarantee good results: I was right.  Incredibly, despite being a closed commercial product, Microsoft described the algorithm they chose as the basis for their implementation in Office[1]. Microsoft has indeed taken note of the requirements of their users and updated the functions to generate random numbers in Excel 2003 with the well documented implementation from Wichmann and Hill (1982).

Since 1982 there have been several well documented algorithms, but there was a natural enchantment in using the same algorithm used by Microsoft; after all they are the leading Office Suite and users tend to know better the behaviour of their suite. After an initial implementation I found that Wichmann and Hill developed an update to their original algorithm in 2006 that completely overcomes some serious limitations in 1982: the original implementation had in mind 16-bit systems while 32 and even 64 bit platforms are ubiquitous nowadays.

The code is not complex; the implementation of the new code was done during two days (part time) following three steps:

1. A basic implementation in C to generate some initial numbers for testing. The seeding was done with the traditional libc rand() function.
2. Adaptation of the code to work inside OpenOffice: this involved selecting carefully the variable types and finding a method to keep the seeds under control. I was careful to avoid an embarrassing condition of generating negative values. I was also lucky to find in OpenOffice an alternative to generate the seeding values without using rand().
3. Testing, testing, and more testing … first locally and now at a wider scale.

I have not discarded yet implementing the popular Mersenne Twister algorithm, which is known to be faster, has a longer period and is available in other spreadsheets (and even as an OO extension), however there is a value in variety: the current algorithm fits perfectly the requirements of a spreadsheet like Calc and uses native features to support good random seeding. Alternatives like Mersenne Twister are already available.

The really nice thing, of course, is that thanks to the Apache License the code is available to be enhanced and improved or even scrapped and redone better in the future by OpenOffice derivatives, non-technical coders like me, and even commercial producers like Microsoft.

Can you help us testing the new pseudorandom number generator? Even though our aim wasn't to obtain crypto-grade quality in the generated numbers, we take our numeric algorithms very seriously, and we're looking for the best. We encourage anyone who wants to help to put our code through rigorous tests and help us find any problems to write to our developers mailing list.

Pedro Giffuni.

[1] http://support.microsoft.com/kb/828795
[2] Wichman, B.A. and I.D. Hill, Algorithm AS 183: An Efficient and Portable Pseudo-Random Number Generator, Applied Statistics, 31, 188-190, 1982.
[3] B. A. Wichmann and Hill, Generating good pseudorandom numbers, Computational Statistics & Data Analysis, Volume 51 Issue 3,  December, 2006, Pages 1614-1622.
[4] M. Matsumoto and T. Nishimura, "Mersenne Twister: A 623-dimensionally equidistributed uniform pseudorandom number generator", ACM Trans. on Modeling and Computer Simulation Vol. 8, No. 1, January pp.3-30 (1998)

Posted at 06:06PM Dec 20, 2012 by pescetti in General  |   | 

Native SVG support for Apache OpenOffice 3.4 (Incubating)

Apache OpenOffice 3.4 supports embedding SVG graphics using a newly created native SVG interpreter implementation. I want to talk about the advantages and some internals of this solution and the necessary changes done.

One reason to do this was IP clearance. It allowed removal of six GPL/LGPL libraries, namely librsvg, libcroco, libgsf, gdk-pixbuf, glib, and pango gettext. These were used as an external pixel-based renderer. The new SVG uses an own internal interpreter in a new library and some new UNO API services. IP clearance was no interesting task to do, but it leaded to effects like here with SVG; the install sets get smaller (less libraries to deliver), the app needs less libraries (startup, memory, runtime) and the internal handling of SVG vector data is completely vector-graphic oriented.

There were also ODF-compatible File Format adaptions needed, more concrete the in ODF already contained and described multi-image support. In ODF, the original SVG is now embedded to the 'Pictures' folder inside the ODF file as one would expect from such a feature and can be easily extracted (unzip the ODF file and there you are). There is also a Png file written as replacement image. The draw:frame is now multi-image capable (as the spec allows). In the case of a SVG it writes a good quality Png and the original SVG as draw:image elements. Since older (and other) office versions are only capable of loading a single (and thus the first) image, the Png is written first. This allows file exchange with other and older offices without breaking backward compatibility and/or ODF file exchange. At load time, multi-image support will choose the best quality graphic available for further work, e.g. preferring vector format over pixel format, pixel format with alpha over non-alpha and lossless formats over those with losing info (you get the idea). Other ODF implementations (e.g. a viewer) may just use the pixel graphic available. Multi-image support is independent from SVG in principle and will work with all image file formats. This is implemented for the Drawinglayer graphic object (used in Draw/Impress/Calc) and the Writer graphic object (used in Writer).

SVG is no longer interpreted each time it needs to be rendered (unavoidable by an external renderer), but only once transformed to a sequence of primitives (UNO API graphic atoms). That sequence is then used for all outputs, transformed to the graphic object's form and viewport. The sequence itself is completely view-independent. Internally, it is reused and thus it makes no difference if you have your SVG graphic added once or multiple times to your document. This is also true for saving, so always only one copy of your added SVG will be written (the same is true for the replacement Png image). Both, the sequence of primitives and the replacement image, are created using new UNO API services. One is capable of converting an io::XInputStream with SVG content to a sequence of primitives, the other is able to convert every sequence of primitives to a rendering::XBitmap with given DPI and discrete sizes (pixels, with automatic resolution reduction to a given maximum square pixel count to be on the safe side). This will be useful for other purposes, too, since it creates a fully alpha-capable representation of anything in primitive format to use as e.g. sprite.

For all graphic processing the created vector graphic in form of a sequence of primitives is used. This means that you will get best quality in all zoom situations and all resolutions. This is also true for all exports, e.g. printing or PDF export which also uses the vector format. With an external renderer, it is unavoidable to use bitmaps with discrete solution in those cases, looking bad when zooming and needing more space in most cases as vector data. There is one caveat since not all program paths already use primitives; some will use the internal MetaFile format in-between (One more reason for more reworks to primitive usages in the future).

I implemented most SVG features from SVG 1.1, but not yet using animations or interactions (but possible in the future due to an own interpreter, impossible with an external SVG renderer). It supports all geometric SVG forms. It supports SVG gradients (using a new primitive for this which will be reused when we add SVG gradients to SdrObjects one day), these have a resolution-dependent low-level format to not waste runtime on low resolutions. It supports masks, clipPath, markers, linked content, embedded graphics or SVG (intern, extern, base64), SVG use nodes, text, text on curve and patterns. It does not yet support filters, color profiles, embedded scripts, interactions and linking. These can be added when needed, most of them will need to implement new primitive types (e.g. filtering) which would be useful for the future anyways. Especially interesting is the possibility to later add SVG animation import to GraphicObjects for Impress.

Some side effects: I had to fix cropping (unified with new primitive) which works now also for mirrored graphics (never worked) and quite some other stuff. We are prepared for SVG gradients as possible future feature (we can already render them now). You can work with an added SVG as with a normal GraphicObject; crop it, break it (to SdrObjects, currently limited to the transfer over the old MetaFile format, though). You can convert an inserted Tux to 3D, you can bend the SVG in vector quality in Draw. It is possible to directly export the original SVG again by selecting the object and using 'Save as Picture...' from the context menu. You can add text, line style, fill style, pretty much the same as most other graphic objects. You can add shadow which casts shadow for the SVG graphic itself as expected (also not possible with an external renderer).

This is a bigger change, but most stuff is isolated in the two mentioned services. There will be errors (I'm too long a programmer to deny that :-)), but I tried to be as careful as possible. I already got some help from other community members and fixed some reported bugs (kudos to all testers and bug writers), but to find the rest, your help is appreciated. Please feel free to play around with any SVG you can find in current AOO 3.4 builds and report problems early in the Apache bugtracker!

Here is another blog entry about an early version of this feature.
And here are some developer snapshots of AOO 3.4 when you want to check it out. Be aware that these are AOO 3.4 Unofficial Developer Snapshots; these are intended to be used for early testing by other community volunteers. They have no release quality and should not be installed in a production environment. Developer snapshots can be unstable and are expected to have bugs.

Regards,
        Armin

Posted at 11:02AM Jan 19, 2012 by alg in General  |  Comments [1]  | 

OpenOffice Grandfather's Private Thoughts

I sent out a similar email to our mailing list before Christmas and before I took a short break to relax with my family and friends. But it's maybe worth sharing with a broader audience here on the blog.

Let me first tell you something about me (Juergen Schmidt=jsc) and to explain the title of this blog. I have been involved in the OpenOffice project since the beginning and have worked on the source code before when I started to work for StarDivision in 1997. So I can for sure argue that I am one of many grandfathers of the OpenOffice project and that the last year or better the last 16 month were not the most brilliant in the long and successful history of the OpenOffice project.

A lot of misunderstanding and miscommunication led to confusion by our users and before we start in a challenging new year I would like to share some thoughts with you about the last months, my private expectations, and my wishes for the next year.

Oracle's announcement to stop their investment in OpenOffice.org was a shock for me. Well the reason is obvious, I was paid by Oracle and worked on this project. The people who know me from the past know that I am a 100% OpenOffice.org guy and I always appreciated to work on this project and together with our community. I always felt as part of the overall community. I know the reasons that were responsible for the LibreOffice fork and the split of the community and I have to confess that I can understand it. But I didn't like how it was done. If Oracle would have done this step 6 month earlier I am sure we wouldn't have this fork and we wouldn't have this split of the community. We would potentially still have the go-oo fork which was the foundation for LibreOffice but that is something different. Anyway it is as it is at the moment and we will see how it moves forward in the future.

The grant to Apache was at least the appropriate signal that OpenOffice.org as a project will never die. The brand is too big and too important, the opportunities around the product and the overall eco-system are great and I am very sure that the project will continue and will be hopefully shining brighter than before.

But a lot of work was and still is in front of us. We had to deal with a lot of things in parallel where other derivative projects didn't had to deal with at least not in public. We had to migrate the whole OpenOffice.org infra-structure to Apache and had to ensure that it worked. I think we were very successful here and have migrated nearly everything we need from a technical perspective.

Our mission was to migrate as much as possible of the available stuff on www.openoffice.org and at least save it for later use. I think we did it! Thanks to all who made this possible. And we can concentrate in the future on some structural and conceptual redesign of the main portal page www.openoffice.org to provide the information to our users that they need to find the product, to find more information like help, discussion forums, and to find the way in the community if they want to do more etc.

We couldn't simply use the code as it was and could continue with the development as in the past because of the different license. A huge challenge that is still ongoing and where I had many problems at the beginning. It is not easy to explain why you remove something and replace it with something new that provide the same functionality but is under a more appropriate license. It's simply boring work and no developer really likes it. But is a prerequisite for Apache and in the end it is better for our eco system because the Apache license is much friendlier for business usage as any other open source license. As an individual developer I don't care too much about all the different open source licenses, as long as the work I do is good for the project and in the end for our users. But I learned that the Apache license can be a door opener for more contributors and more engagement of companies. I think that is important and I am confident that it will help to drive our project forward.

And not everything is bad. With the IP cleanup we really cleaned up many things and Armin's replacement for the svg import/export is the best solution we ever had for OpenOffice and with the biggest potential for further improvements. All this is really motivating for the future!

Well we had a lot of noise and communication problems on our mailing lists and I think we missed transmitting the message that OpenOffice.org has found a new home under the Apache foundation and we have missed communicating the progress we have made in the pubic. We can do much better in the future! And I am looking forward to working with all of you on this communication part in the future. We don't have to be shy, we work on a great project with a great product and we should have enough to communicate and to share in the public (not only on our mailing list but on all the modern and very useful media like Facebook, Google+, twitter, ...)

For the next year I expect that we find our way to guide and control our project a little bit better. I expect our first release early next year and hopefully a second one later in the year where we can show that we are able to drive the project forward and that we are able to create and establish a vibrant and living community.

I wish that we can gain trust in the project and in the Apache way and that it is a good move forward. Our users simply want the best free, open source office productivity suite and they don't care about the different licenses. Enterprise users would like to see a huge and working community with the participation of a lot of different companies or at least their employees working on the project. We all know that such a huge and successful project can only work if we have individual community members as well as full-time community members. Important is the WE and the TOGETHER that makes open source projects successful.

I heart voices and read emails where people said that Apache is not able to manage such a huge end user oriented project with all the necessary things. A strong statement, isn't it. At the beginning I have to confess that I also had doubts and wasn't sure. But as I have mentioned in an earlier post on our mailing list, I have seen and got the necessary signals over time that Apache is willing to listen and is open for changes as well if they make sense for the overall success of our project and if these changes are aligned with the overall Apache principles. And I think that is fair enough for all.

The move to Apache is a big challenge for all of us. Apache had many very successful projects but none of these projects has such a huge end-user focus like OpenOffice. And of course OpenOffice is no small or new project. No it is one of biggest and most successful open source projects ever. And the migration was and is not easy. But we the community can do it, we as individuals, everybody can help and we together will do it!

And the Apache way and the Apache license have proven in the past and with many successful projects that it is a good way and a good license to achieve this.

For our users I wish that press people will do a better job in the future to research facts and stories better or if they prefer to write articles based on first-hand information that they contact the Apache OpenOffice project directly. We are here and can help with information! That will definitely help to avoid further confusion about the future of OpenOffice.

Enough from me for now and I hope that I haven't bothered you with my private thoughts. I wish you all a happy new year, enjoy these days, take your own break too, load your batteries for our next challenge in 2012.

Regards

Juergen

Posted at 05:55PM Dec 27, 2011 by jsc in General  |  Comments [2]  | 

Incubation, podling, IP Clearance, oh my!

---

The Apache OpenOffice.org project is currently in the incubation phase. We're a 'podling'. It's where all new Apache projects begin, regardless of how mature your source code base is. In this post I'll attempt to explain a bit about incubation, and a bit about the 'Apache Way', and our current effort to meet the requirements for 3rd party code review and clearance. In future posts, I'll attempt to tackle other aspects of the project. If we all have a better understanding of how the work is becoming organized, those of you interested to volunteer will have a better idea of where to start, and those who are interested to follow our progress will have an easier way to check up on things. 

First off, a podling is not from 'Invasion of the Body Snatchers' – a human being wrapped up to look like a large vegetable, or furry cute puppets from the Dark Crystal Cave of Jim Henson's imagination. It's the term we use here at Apache to describe the first phase of a prospective project; a podling is a project that is 'incubating'. Egg, podling, new thing with promise needing special care and attention. I think you get the idea.

It's that special care and attention part that is consuming the efforts of the PPMC or "Podling Project Management Committee" at the moment. If we are going to hatch, 'graduate' to a TLP or "Top Level Project" in Apache-speak, we are required to meet certain criteria evolved out of deep experience accumulated through Apache's 12 year history and its involvement with many other successful projects.

Apache defines a podling as “A codebase and its community while in the process of being incubated.” You can find the details on the complete Apache Incubation Policy here.

OK, so we have the code base, thanks to Oracle's decision, and we have a community signed in to the project already, 75 committers and growing. So where are we with the process?

When do podlings hatch, and become Apache TLP or Top Level Projects?

The abbreviated answer requires the podling to:

• Deliver an official Apache release
• Demonstrate you have successfully created an open and diverse community
• Follow the 'Apache Way' through the process, documenting status, conducting ballots, maintaining a fully open and transparent process, etc.

OpenOffice is a very large chunk of code, many millions of lines of code. The PPMC has now successfully migrated all the source files into the Apache infrastructure nestled into its new nest within the Apache Subversion repository environment. We've run a build test on Linux and we know we've got the code we need to begin to build a release.

But wait, before we can meet the requirement of producing an official release, Apache requires that we conduct a thorough IP or Intellectual Property review and clearance process. This means that the resulting Apache release may be licensed under the Apache License 2. It requires that all...

“incoming code is fully signed off before any release. This simply reinforces the Apache requirements: all code must have appropriate licenses....The process of preparing an Apache release should include an audit of the code to ensure that all files have appropriate headers and that all dependencies complies with Apache policy.

This means that the resulting Apache OpenOffice release(s) will provide the maximum opportunity for the development of a broader spectrum of OpenOffice derivatives than we see today. The OpenOffice of the past, will look very different in the future as more developers become familiar with the code, and see new opportunities not previously available. 

Right now, our immediate task is to resolve the licensing incompatibilities for 3^rd party code modules used by OpenOffice. Since Oracle did not possess the copyright for these modules, they were not included in the original Oracle Software Grant Agreement, and therefore we are working to either deprecate, or find a replacement that may be used either as a binary file or an alternative source file that fills the function needed. We're confident that the process will be concluded in the next weeks, but it is detail-oriented work, and must be done thoroughly and correctly in order to clear the path for an official podling release of Apache OpenOffice.

Before we can produce an Apache release, we must complete the code clearance step, ensuring that the license headers include License and Notification files for all artifacts in the build be done to the satisfaction of the PPMC and the Incubator PMC which governs the Apache OpenOffice podling. This will clear the way forward to develop a realistic target date for issuing our first 'Apache OpenOffice.org' release 

In future posts, I'll sketch out how the project is being organized, mapping out the areas that offer interesting and exciting opportunities needing new volunteers to step up and take on.  

- Don Harbison, PPMC Member, Apache OpenOffice.org

Posted at 08:10PM Oct 18, 2011 by dpharbison in General  |  Comments [9]  |