Native SVG support for Apache OpenOffice 3.4

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

The Community Forum: New Year Status

After 4 years of existence, the Community Forum has moved on the Apache Software Foundation (ASF) servers at the end of October 2011 (see details). Here are some figures about how we are doing on the English forum. We will try to make this kind of report on a monthly basis in the forum and perhaps quarterly on the blog.

Please remember that the forum is managed by a group of users helping other users for free and on their spare time.

Some basics:

Posted at 12:00AM Jan 12, 2012 by robweir in Status  |  Comments[1]  | 

Features for GraphicObjects and OLEObjects

I just wanted to send some notes about added features which are part of AOO3.4 version. This one is actually the result of fixing tasks #118558#, #118485#, #108221# and #67705# which are all about GraphicObjects, OLEObjects (OLE means Object Linking and Embedding) and their geometrical attributes and properties. You may take a look at the tasks if you are interested in details, here I want to describe the benefits.

GraphicObjects are used when you insert a picture (pixel and vector data) or convert something to it. They already supported the full attribute set, so line style, fill style, text and shadow are possible. Geometrically, they could be transformed widely, but could not be sheared. Because now the content of GraphicObjects is displayed using primitives (and these are fully transformable) it is possible to also use shear and thus now completely support all geometrical transformations used in the office.

More interesting is that this is also true for OLEObjects, thus I added all these possibilities to OLEObjects of any kind, not only to our own internal OLEObjects (e.g. Chart, mathematical formula), but all possible external OLEObjects. These can now have line styles, fill styles, text and shadow and can be fully transformed. It is also possible to convert them to GraphicObjects which is the base for converting them to something else. Thus, you may now slant or distort OLEObjects, convert them to GraphicObjects, make geometrical modifications like merge/subtract/intersect with other objects or even convert them to 3D objects.

Some of the possible changes may lead too far for daily use, but some are pretty useful. It is now e.g. possible to add a mathematical formula and position it somewhere vertically by rotating it 90 degrees. It is possible to rotate chart OLEObjects themselves to get chart displays which the chart itself does not directly support. It is also useful to add a frame to a chart. With using the text offset it is also possible e.g. to add text to the OLEObject and move the text outside the object to get a caption. I leave more possibilities to your imagination...

Some examples:

(a) Math OLEObject rotated 90 degrees, blue filled and with border
(b) Chart OLEObject with gradient fill, border and object text as caption
(c) Same chart without fill, 90 degree rotation and shadow
(d) Chart bend in 2D, converted to GraphicObject (no longer an OLEObject)
(e) Chart OLEObject converted to 3D (only for demonstration, not too nice to view...)
(f) The math OLEObject, converted and bent, fill removed

I hope you got an impression; I'm not the designer guy, so excuse the examples.

Regards,
      Armin

Posted at 03:42PM Jan 11, 2012 by alg in General  |   | 

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

OpenOffice.org Migration -- The Community Forums

The OpenOffice.org Community Forums have been successfully migrated to operation under the Apache OpenOffice.org podling.  Forum operation, location, and resources are intact.  For users and the community that has grown the Forums into a valuable resource, it seems nothing changed.  It wasn’t so simple.  Here’s what it took and what was gained.

Community Forums on the move

Cut-over of the Community Forums completed on Friday morning, October 28.  There were few disruptions during Internet propagation of the new hosting-site location.  The migrated site is now accessed by the original web addresses.  A staging server holding the necessary software was tested using backups of the data from the Oracle-hosted Forum services.  Staging preparations started in July.  It was the first-ever introduction of a Forum system at Apache. The last backup of the “live Forums” happened on October 27.  The Forums backup was restored to the Apache staging system.  The new “live Forums” stepped in, just like the old Forums.  The transplant succeeded.

Adjustments will continue.  There will be alignment with remaining migrations of OpenOffice.org web properties.  There will be further  integration into the Apache OpenOffice.org podling operation.  Throughout remodeling, the Forums will be alive and well.

Community Forums legacy

The OpenOffice.org Community Forums originally went live on November 28, 2007.  By September 20, 2011, the English-language Forums have accumulated 200,000 posts, contributed by 45,000 Forum registrants, on 40,000 topics (threads).   At any point in time there appear to be 10-20 times as many unregistered users browsing the Forum as registered users.  The thrust is having a setting where users with questions find users with answers.  Experienced users also provide guidance to where the questions are already asked and either answered or under discussion.  The Forums are a customization of the phpBB software that is a prevalent implementation of Internet forums.

The Spanish and French forums are next in size and activity, with most other forums of intermediate size. The entire Forum base is preserved on-line.  Forum content is indexed by the major web search services. 

Always open, browsing welcome

Visiting any of the Forum entry pages and exploring any topic of interest reveals characteristic Forum features:

• It is easy to see what the variety of topics and degree of activity has been in each subject area. 
  
• Threads are organized and presented with recent, active topics located quickly; other viewing options, including of one's own posts, are selected with a single click.
  
• There is integrated search for any topic and content.
  
• Images and code samples can be included in posts and all can be quoted, cross-referenced, and reached via web locations.
  
• The Forums provide links to extended topics on the Community Wiki, another migrated service.
  
• There are tutorials on all components of the OpenOffice.org suite. 
  
• Special topics include the programmability features of OpenOffice.org, including writing macros and using/creating extensions. 
  
• The Forums embrace all of the descendants of the original StarOffice/OpenOffice.org that have become siblings in the OpenOffice.org galaxy.  Tips and solutions in the use of one release are often useful to users of a peer product having the same feature. 

Supporting global community

The forums were originated by a group of independent volunteers.  The entire content of the Forums is created and curated by individual users and volunteers.   With migration, the volunteer structure is supplemented by arrangements for oversight as required by policies concerning properties in ASF custodianship.  Day-to-day operations and volunteer activities are unchanged..

User peer-support grows by inviting frequent contributors to serve as volunteers.  Volunteers review Forum activity, point out where moderation is required, and participate in privacy-sensitive discussions about Forum operation.  More-experienced volunteer Moderators intervene where appropriate to provide special assistance or curate threads and subscriptions.

The OpenOffice.org Community Forums are one way that the Web connects users of OpenOffice.org-related products.  There are additional communities across the Internet with similar concerns as well as different specialties.  These can employ mailing lists, Internet news groups, and other web-based forums.  The Web and search engines bring the different resources of these communities into the reach of each other and users everywhere.   The OpenOffice.org Community Forums are now continuing as a substantial resource of that extended community.

Moving complex web properties

The OpenOffice.org web site is a complex structure of services, web pages, and downloadable content. The openoffice.org Internet domain lease is moving as part of the grant from Oracle Corporation to the Apache Software Foundation (ASF). Migrating the various properties that constitute the web site is complicated. Considerable effort is required to have migration appear effortless and smooth.

Some services housed under the OpenOffice.org web locations are rather independent. Apparent integration as an OpenOffice.org web location is accomplished by splicing the service into an openoffice.org sub-domain. That is the case with http://user.services.openoffice.org/ and its ten native-language Community Forums. The English-language Forum location, http://user.services.openoffice.org/en/forum/, illustrates the pattern for individual languages. There is also consistent appearance and other features that blend the forums into the overall OpenOffice.org site.  Maintaining this structure is important so that users can find materials where they recall them, including in bookmarks and links from other materials (including other forum posts).  Search services that have already indexed the forum pages will continue to refer seekers to those same still-correct locations.

---

developed in Forum Discussion collaboration among acknack, FJCC, floris v, Hagar Delest, kingfisher, mriisv, MrProgrammer, orcmid, RGB, RoryOF, and vasa1 on behalf of the Community Forum Volunteers, additional ooo-dev suggestions by Donald Whytock and Dave Fisher.

Posted at 01:05AM Nov 18, 2011 by orcmid in General  |  Comments[7]  | 

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

「日本語メーリングリスト」 means "Japanese Mailing List"

I am testing if Japanese language can be shown up beautifully on Title and Content of this Apache Weblog.

I am a moderator for the ooo-general-ja mailing list.  The day before yesterday I found that a moderator can remotely edit the text files that make up the responses the list sends out.  Then I started translating and editing them.  I have translated "top" and "bottom" messages.

You know the "top" message.  It goes like:

"Hi! This is the ezmlm program.
I'm managing the ooo-o-ooo-AT-i.a-DOT-o mailing list.
I'm working for my owner, who can be reached
at ooo-o-ooo-owner-AT-i.a-DOT-o."

In Japanese it goes:

「こんにちは。私は ezmlm というプログラムです。
私は ooo-o-ooo-AT-i.a-DOT-o を管理しています。
私はこのメーリングリストのオーナーのために
働いています。オーナーの連絡先は次のとおりです。
 ooo-o-ooo-owner-AT-i.a-DOT-o.」

I like the following part of the "bottom" message:

"If despite following these instructions, you do not get the desired results, please contact my owner at ooo-general-ja-owner-AT-incubator.apache-DOT-org. Please be patient, my owner is a lot slower than I am ;-)

In Japanese:
「ここに書かれた指示に従ったのにもかかわらず、望む結果が得られなかった場合は、ooo-general-ja-owner-AT-incubator.apache-DOT-org にメールを送り、このメーリングリストのオーナーと連絡を取ってください。このメーリングリストのオーナーは人間なので私より反応に時間がかかると思いますが辛抱強くお待ちください ;-)

We know ;-)  We have to be patient with human beings ;-)

Posted at 12:07AM Oct 14, 2011 by khirano in General  |  Comments[2]  | 

The second Japanese language mailing list on Apache

I am a moderator for ooo-general-ja/AT/incubator.apache.org.

I have checked the mail archives on mail-archives.apache.org and found that there are 3 non-English language mailing list on mail-archives.apache.org such as dev-br/AT/spamassassin.apache.org, dev-de/AT/spamassassin.apache.org and axis-user-ja/AT/ws.apache.org.

Maybe axis-user-ja/AT/ws.apache.org is the first Japanese language mailing list on Apache.  See one of posts from this archive.  It's in Japanese encoded ISO-2022-JP but parts of it is garbled. It was posted on Wed. 01 Dec 2004 06:18:12 GMT.

2 Japanese moderators and 2 Japanese volunteer testers are now testing ooo-general-ja/AT/incubator.apache.org.

I hope Japanese be no garbled :)

Posted at 02:30PM Oct 05, 2011 by khirano in General  |  Comments[3]  | 

Apache OpenOffice.org Developer Education: Building on Linux

 Developer Education

It is September.  In the northern hemisphere it is time for cooler weather and time to go back to school.  The Apache OpenOffice.org podling is ready for the season with events to help developers learn more about OpenOffice.org. 

Do you want to learn how to build Apache OpenOffice.org on Linux?  Do you want to take the first steps towards becoming an OpenOffice hacker?  Do you want to help test, review and improve our build instructions, on any one of a variety of Linux distros?  If so, you will not want to miss this event.

Next week, from Wed September 7th through Saturday September 10th we will be making a concerted effort to enable everyone who wants to be able to build OpenOffice. This will be the first of a series of Developer Education topics we hope to deliver.  Others may include how to build on Windows and Mac, and how to work on particular OpenOffice features.

This will be a virtual event, with collaboration on the ooo-dev mailing list and on IRC.  Members of the OpenOffice.org podling will be on hand to help anyone who wishes to get started with OpenOffice development on Linux.

 How to Get Involved

There are a few things you should do to prepare for this event:

1. Find a Linux machine, at least 1GB RAM and 75 GB free disk space
2. Run any updates needed to make your distro current
3. Download the latest source code for OpenOffice.org via Subversion.
4. Before Wednesday, sign up for the ooo-dev@incubator.apache.org  mailing list.
5. Bookmark the OpenOffice.org Building Guide.  This is the documentation we'll be following, and correcting.
6. Starting on Wednesday, follow the discussions on the ooo-dev mailing list.  We'll use a subject tag of [LINUX-BUILD] for threads related to this event.
7. Also starting on Wednesday, join us on IRC: irc.freenode.net  on channel #dev.openoffice.org

Posted at 10:41PM Sep 01, 2011 by robweir in General  |  Comments[1]  | 

OOo! There’s a New Podling in the Nursery Incubator

The Apache OpenOffice.org (incubator) project was born on Monday, June 13, 2011.  Delivery was complicated.  The baby’s doing fine.

Following the June 1, 2011 announcement of the license grant from Oracle to the Apache Software foundation, there was extensive discussion over the proposal for acceptance of OpenOffice.org as an Apache incubator project.  Before the June 10 voting began, 207 edits had been made to the proposal.  Discussion leading up to the vote swamped the public mailing list used for consideration and oversight of incubator projects.

We’re now taking the baby steps that will lead us to a healthy, thriving project:

• The open, public developers list, ooo-dev, is operating and active.  Anyone can subscribe and post.  Anyone can access the archive.
• There is a fledgling Community Wiki.  Anyone can subscribe and post.  Anyone can access the wiki.
• There is also a Developer Wiki.  Contributions here are treated as deliverables of the project.  Anyone can access the wiki, but contributions to this wiki require submission of an Apache Contributor License Agreement.  Perhaps this wiki could have a better name?
• There is a project web site.  The content is rather thin at the moment.  It is growing.
• There’s also a place in the Apache Subversion repository for all of the source code.  At the moment that consists of tools and the project web site pages (created in Markdown).

The gathering of contributors for the project is continuing.  In the status of many of the incubating podlings, you’ll find the OpenOffice.org podling’s first check-up.  (Scroll down through the alphabetical list.) 

There is more to do, especially around migration of the sites and their artifacts from their OpenOffice.org homes to their Apache counterparts.  There are more tasks to accomplish than the number already completed.

Everyone wants to know how soon there will be another OpenOffice.org release and how rapidly everything can be up and running.  So do we.  Apache OpenOffice.org will be different.  The differences may be unrecognizable, but they will be there.  Establishing what it takes to reach a sustainable, supported release process as an Apache project is where we first begin by crawling, next to walk, and then to run

This blog is a place for listening to the heartbeat and taking the pulse of the effort as it unfolds.

Posted at 10:17PM Jul 09, 2011 by orcmid in General  |  Comments[5]  |