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]  |