Entries tagged [openoffice]
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!
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:
- A basic implementation in C to generate some initial numbers for testing. The seeding was done with the traditional libc rand() function.
- 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().
- 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 3rd 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]
|